La réponse est évidente, me direz-vous : il ne faut pas stocker en base de données le mot de passe, mais un hash de ce mot de passe, qui ne puisse pas être décrypté.

Pourtant, je vais vous proposer de stocker le mot de passe en base de données, et vous expliquer pourquoi…

Pour mémoire, un hash est le résultat d’une fonction (ou formule mathématique) qui reçoit en entrée une chaine de caractères, et produit en sortie une autre chaine de caractères. Le principe de ces formules, c’est qu’à chaque fois que l’on applique la même formule à une même chaine, c’est le même résultat qui est produit. Les algorithmes de « hashage » les plus courants sont MD5, SHA1, …

On parle également de « signature » : le hash d’un fichier permet par exemple de vérifier qu’il n’a pas été altéré durant le transfert, en comparant le hash avant envoi et après réception. La formule de hashage est conçue pour que la probabilité que deux fichiers aient la même signature soit particulièrement faible.

La formule de hashage est suffisamment complexe pour que, en théorie, il soit impossible de retrouver la chaine d’origine, d’autant que la longueur de signature hash est fixe, quelle que soit la longueur de la chaine traitée.

Lorsque les formules de hashage ont été mises au point, elles paraissaient inviolables, du moins avec les moyens technologiques à disposition. Depuis, plusieurs approches ont été utilisées pour en venir à bout. L’enjeu étant, pour une personne malveillante, de retrouver le mot de passe d’utilisateurs à partir d’une base de données de hash d’utilisateurs,  pour se connecter à leur place. De tels fichiers (nom d’utilisateurs, mots de passe hashés) sont régulièrement piratés et mis à disposition sur internet, par exemple ce fut le cas il y a deux ans pour linkedin.

Des formules de hashage faillibles

Si les formules de hashage paraissaient inviolables, c’est que le temps nécessaire pour tester toutes les combinaisons possibles se comptait en centaines voir milliers d’années… avec les puissances de calcul de l’époque. Sauf que le même calcul met quelques dizaines d’heures de nos jours. La « parade » étant d’étendre la formule, afin d’augmenter le temps nécessaire. C’est une course-poursuite sans fin, perdue d’avance…

Par ailleurs, les algorithmes de hashage finissent tôt ou tard par montrer des faiblesses. Par exemple, MD5 présente un taux relativement élevé de « collisions », permettant de trouver « un autre mot de passe » correspondant à une signature (hash) donnée, comme expliqué dans cet article.

J’en prends pour preuve ce que font systématiquement les sites qui se font voler leur base de données avec les mots de passe hashés : ils commencent par demander (ou forcer) la modification du mot de passe de chaque membre. Et ça n’arrive pas qu’aux autres : Linkedin (premier réseau social professionnel) comme indiqué précédemment, et OVH (premier hébergeur web en Europe) figurent sur la liste.

Pourquoi stocker les mots de passe en base de données ?

Maintenant que l’on a vu que stocker les versions hashées (non récupérables) des mots de passe n’apportait pas une garantie de sécurité, mais était plus un moyen pour l’administrateur serveur de se rassurer (voir se donner bonne conscience), voyons ce qu’apporte le fait de conserver le mot de passe en base de données.

Evidemment, je ne parle pas de stocker le mot de passe « en clair », mais convenablement chiffré, avec une « clé privée » (ou équivalent) et un ‘sel’ dynamique. A ce sujet, on pourra lire l’erreur commise par Adobe…

Pour identifier les bénéfices d’un mot de passe disponible sur demande, il suffit de se mettre à la place de l’utilisateur : lorsqu’il a perdu son mot de passe, préfère-t-il récupérer par email son mot de passe, ou bien recevoir un lien qui lui permettra de le re-initialiser ?

Je vais même plus loin : j’ai vu un chef d’entreprise issu d’un secteur d’activité traditionnel, qui venait de racheter un site de e-commerce, s’étonner (voir s’insurger) sur le fait que le service client (désormais son service client) pouvait visualiser et modifier les mots de passe des clients. Au vu du contexte, cela avait du sens : les chargés de clientèle avaient déjà accès à toutes les informations du client, et pouvaient redonner son mot de passe a un client qui appelait (après avoir vérifié son identité), et ainsi lui permettre de finaliser sa commande…

Lorsque j’ai interrogé le chef d’entreprise sur la raison de son opposition farouche à ce que les chargés de clientèle voient le mot de passe, sa réponse a été édifiante : « parce qu’ils voient mon mot de passe, et que je mets le même partout ». Bref, ne nous trompons pas de combat… Un système informatique ne se substituera jamais à l’utilisateur : si l’utilisateur n’applique pas des règles élémentaires de sécurité (à plus forte raison lorsqu’il est chef d’entreprise), c’est avant tout à ce problème qu’il faut s’attaquer !

La taux d’insatisfaction de l’internaute peut être poussé à l’extrême, comme j’ai pu le constater dans le cadre d’une autre mission client. Celui-ci organise des activités (sportives) très prisées qui ont un nombre de places restreint : il n’y en a pas pour tout le monde, et le premier arrivé est le premier servi. Les internautes sont donc dans les starting-blocks au moment de l’ouverture des inscriptions. Sauf que certains ont oublié leur mot de passe, et demandent donc à le re-initialiser par email.  Mais comme l’email n’arrive pas assez vite à leur goût, ils utilisent plusieurs fois le formulaire… et lorsqu’ils reçoivent le premier email et cliquent sur le lien d’activation, celui-ci n’est plus opérationnel, remplacé par le suivant. Tout aurait été bien plus simple pour les utilisateurs finaux si ils avaient pu recevoir leur mot de passe par email.

Ce qui nous amène à une question fondamentale dans la définition des mesures de sécurité : utiliser le niveau de sécurité adapté, ni plus, ni moins. Surtout dans une activité de e-commerce : dans mes deux cas concrets, trop de sécurité représente directement des pertes de chiffre d’affaire et de l’insatisfaction client, sans valeur objective à mettre en face.

Quel niveau de sécurité adopter ?

Parce qu’au fond, le débat n’est pas « faut-il stocker le mot de passe du client en base de données ? », mais dans quel cas on peut raisonnablement le faire.

Il n’y a pas de réponse universelle, un peu d’audit (ou du moins questionnement) est nécessaire : si le compte est compromis, que pourra faire une personne mal intentionnée avec un accès au compte ?

Accéder à un historique de commande ? la belle affaire… Evidemment par contre si des données de paiement sont stockées, c’est autre chose. Mais dans ce cas de toutes manières il y a des exigences de sécurité d’EMV (Eurocard-Mastercard-Visa) ou la norme PCI-DSS (venant des USA) qui s’appliquent.

En fait, dans tous les cas sur lesquels j’ai été amené à travailler, rien ne justifiait l’utilisation d’un hash de mot de passe (plutôt qu’un mot de passe chiffré) en base de données…

Par contre, dans 1 cas sur 2, cette mesure de sécurité a directement pénalisé l’activité du site. A méditer !

Werner KLINGER
Ingénieur Conseil Web & NTIC

Tags: e-commerce, mot de passe, web