Hashage vs. Cryptage : Comment votre mot de passe est stocké sur le serveur

Disons que vous créez un compte sur VerySecureWebsite.com. Vous saisissez votre adresse e-mail et votre mot de passe et configurez votre compte. Un peu plus tard, vous recevez un e-mail vous informant que, ironiquement, le site a été piraté, et les noms d’utilisateur et mots de passe de chaque utilisateur, qui étaient stockés en clair, sont maintenant en vente sur le dark web. Pendant que vous commencez à changer le mot de passe de tous vos comptes (vous n’en utilisez qu’un, vraiment), vous vous demandez : “N’est-ce pas une mauvaise idée ? Mon mot de passe ne devrait-il pas être sous une forme de code secret afin que les pirates ne puissent pas le lire ?“
Vous avez raison. Toute application web ou service qui utilise un système de connexion par nom d’utilisateur/mot de passe devrait stocker les mots de passe de ses utilisateurs en utilisant un hachage salé, voire même un hachage salé lent, peut-être avec une épice. Si cela commence à ressembler plus à un petit-déjeuner qu’à de la cryptographie, ne vous inquiétez pas : contrairement à votre mot de passe (espérons-le), le stockage sécurisé des mots de passe n’est pas un sujet trop difficile à comprendre.
A lire aussi : Pourquoi les restrictions de mots de passe sur les sites Web ne vous protègent pas
Texte brut et cryptage basique

| Nom d’utilisateur | Mot de passe saisi | Forme stockée |
|---|---|---|
| UtilisateurIgnorant | MotDePasseFaible | MotDePasseFaible |
Stocker des mots de passe en texte brut dans une base de données connectée à Internet est une très mauvaise idée : si la base de données est piratée, quiconque a réutilisé l’un de ces mots de passe est maintenant en danger. Et pourtant, un nombre préoccupant de sites Web le fait encore, probablement parce que les mises à jour de sécurité sont plus pour le client que pour l’entreprise. Si vous voulez tester si un site fait cela, essayez de sélectionner l’option “mot de passe oublié”. S’ils vous envoient simplement votre mot de passe au lieu d’un lien de réinitialisation, il est stocké en texte brut.
| Nom d’utilisateur | Mot de passe saisi | Crypté avec AES-128 clé : ClefFaible |
|---|---|---|
| UtilisateurIgnorant | MotDePasseFaible | 38MkoXVXoKe01uAOROBLpQ== |
Le cryptage peut sembler être une méthode forte pour stocker des mots de passe, mais c’est en réalité juste une étape au-dessus du texte brut. Un mot de passe crypté peut généralement être décodé avec une clé, et si les pirates peuvent la trouver ou la deviner, le cryptage devient inutile.
Hachage > cryptage

| Nom d’utilisateur | Mot de passe saisi | Chaîne à hacher | Haché avec SHA-256 |
|---|
| UtilisateurIgnorant | MotDePasseFaible | MotDePasseFaible | 252E2406732308F9A7
B378ED94E78467D14
077D19C8282443FCD
3D6190FCABFA |
Une fonction de hachage est essentiellement un cryptage à sens unique : vous convertissez le mot de passe en texte brut en un code secret, mais il n’y a pas de clé pour le reconvertir, ce qui signifie que vous ne pourrez jamais dériver le mot de passe réel à partir de la version hachée.
C’est ainsi que la plupart des sites Web sécurisés gèrent leurs mots de passe :
- L’utilisateur crée un compte
- Le mot de passe de l’utilisateur est passé par la fonction de hachage et stocké dans la base de données
- Chaque fois que l’utilisateur se connecte, la base de données hache le mot de passe qu’il a saisi et vérifie si le hachage saisi correspond au hachage qu’ils ont dans leurs dossiers.
- Si oui, l’utilisateur peut se connecter
Avec un hachage, l’application/le site ne stocke jamais votre mot de passe réel nulle part, et un pirate qui s’introduit obtiendra uniquement une liste de lettres et de chiffres qui ne peuvent pas être décodés. Selon la solidité de l’algorithme, ces hachages peuvent être assez difficiles à casser.
Cependant, les hachages ne sont pas inviolables. Tout ce qu’un attaquant a à faire est de passer un dictionnaire de mots de passe potentiels par la fonction de hachage, puis de comparer ces hachages aux hachages de la base de données. Lorsque deux hachages correspondent, le pirate peut simplement voir quel mot de passe a généré ce hachage.
Pour gagner du temps et de la puissance de calcul, de nombreux attaquants utilisent simplement une table de correspondance (ou un “rainbow table”, une version économe en espace de tables de correspondance), une table pré-générée pleine de mots de passe potentiels et de leurs hachages. Vous pouvez en fait essayer de hacher un mot de passe en texte brut et ensuite utiliser une table de correspondance sur le hachage vous-même ; ce n’est pas trop difficile. Essentiellement, si votre mot de passe est commun, le hachage de ce mot de passe est probablement déjà dans une table de correspondance. C’est une excellente raison de ne pas utiliser de mots de passe courants.
A lire aussi : Créez un mot de passe fort en utilisant ces conseils et outils
Hachages salés > hachages

| Nom d’utilisateur | Mot de passe saisi | Chaîne à hacher | Haché avec SHA-256,
sel = XcyKn42, préfixé | | — | — | — | — | | UtilisateurIgnorant | MotDePasseFaible | XcyKn42MotDePasseFaible | 13EB660FF7FBD29A728FC5
92297D78DF19AFF8797363
15FBF1F1C4B7123BD10C |
Contrairement aux limaces, le sel rend les hachages plus forts. Puisque l’intégralité du hachage change même si une seule lettre du mot en texte brut est modifiée, tout ce qu’un site a à faire pour contrecarrer les tables de correspondance est d’ajouter un peu de texte brut au mot de passe avant qu’il ne soit haché. L’attaquant pourra lire le sel en texte brut puisque cela est stocké dans la base de données, mais cela les oblige à recalculer chaque combinaison possible de mots de passe potentiels et de sels.
Bien sûr, les hachages salés peuvent toujours être cassés. Les pirates peuvent simplement ajouter le sel au mot de passe qu’ils devinent, hacher la combinaison et attendre que des correspondances apparaissent – une attaque par dictionnaire standard. Étant donné que les GPU modernes peuvent faire des milliards de suppositions par seconde, ce n’est pas du tout irréaliste, mais cela rend le processus beaucoup plus ennuyeux. À défaut, les attaques par force brute sont lentes mais très efficaces.
Rendre les hachages encore plus forts : autres tactiques

| Nom d’utilisateur | Mot de passe saisi | Chaîne à hacher | Haché avec Bcrypt,
sel = XcyKn42, préfixé,
12 rondes | | — | — | — | — | | UtilisateurIgnorant | MotDePasseFaible | XcyKn42MotDePasseFaible | $2y$12$6OleutQBO2iPoNvg
pyDndOU26Lqt9Y34f6PLEOx
mCELP5GoswrJT. |
Les algorithmes de hachage lents, comme PBKDF2 ou bcrypt, utilisent une technique connue sous le nom de “key stretching” pour ralentir les attaques par dictionnaire et par force brute. Cela implique essentiellement de définir la fonction de hachage pour itérer un certain nombre de fois (bien que ce soit un peu plus complexe que de simplement exécuter la même chose encore et encore), afin qu’il faille beaucoup de puissance de calcul pour atteindre le hachage correct. Si un site fait tout cela, leur sécurité est plutôt bonne.
| Nom d’utilisateur | Mot de passe saisi | Chaîne à hacher | Haché avec Bcrypt,
sel = XcyKn42, préfixé,
12 rondes,
épice = |4|\/|@p3pp3r, suffixé | | — | — | — | — | | UtilisateurIgnorant | MotDePasseFaible | XcyKn42MotDePasseFaible|4|\/|@p3pp3r | $2y$12$njmWr5UMydCzdCE44ElW/
OIfYp2PH9sgonCATyVY.OVKSpmoSaZlu |
Pour plus de sécurité, vous pouvez également “épicer” vos hachages – qui, espérons-le, sont déjà salés. Un épice, comme un sel, est un ensemble de valeurs attachées au mot de passe avant qu’il ne soit haché. Contrairement à un sel, cependant, il n’y a qu’une seule valeur d’épice, et elle est gardée secrète, séparément des sels et des hachages. Cela ajoute une autre couche de sécurité au hachage salé, mais si l’attaquant parvient à le trouver, il n’est plus très utile puisque l’attaquant peut l’utiliser pour calculer de nouvelles tables de correspondance.
Ne faites pas un hash de votre hash
La sécurité des mots de passe a fait de grands progrès – tout comme l’art de casser cette sécurité. Malheureusement, les humains sont toujours mauvais en gestion des mots de passe, et les bases de données ne mettent pas à niveau leur sécurité aussi souvent qu’elles le devraient. En général, supposez que chaque fois que vous créez un compte, le mot de passe est stocké avec une sécurité relativement faible. Si votre mot de passe est commun ou un mot du dictionnaire, alors il est à un risque assez élevé d’être cassé. Faites vos mots de passe longs, en mélangeant lettres, chiffres et symboles, et vous aiderez les fonctions de hachage à faire leur meilleur travail.