Le stockage des mots de passe en toute sécurité est un problème récurrent. Mais quelles sont les principales méthodes, comment fonctionnent-elles, et ce qu’elles valent face aux techniques actuelles de rupture de mot de passe ? Nous expliquons dans cet article les principes essentiels du stockage sûr (hachage, sel, poivre, itération) et soulignons leur importance dans la résistance aux méthodes de récupération de mot de passe. Enfin, nous vous parlerons d’une fonctionnalité de hachage fiable pour un stockage sécurisé.
A voir aussi : Les avantages de Shopify pour un e-commerçant
Plan de l'article
Mots de passe en clair
Disons qu’un attaquant peut récupérer une base de données à partir d’une application Web et extraire le couple de la base de données .
| Connexion | Mot d’évents |
| admin | azérty |
| toto | matrice |
| Billy | yep59f4txwrr |
| tata | matrice |
| titi | freepass |
| attaquant | TesPwndMot de passe |
Dans ce cas, l’attaquant possède directement les mots de passe en texte brut de tous les utilisateurs. Même Billy qui a un mot de passe robuste n’est pas protégé.
A découvrir également : Pourquoi optimiser son site internet ?
Le stockage des mots de passe en texte brut est ÉTAPES une solution sécurisée. Personne, y compris les administrateurs du site/base de données, ne devrait avoir accès au mot de passe en texte brut de l’utilisateur.
Mots de passe chiffrés
Dans certains cas, les mots de passe sont stockés dans la base de données après avoir été chiffrés par un algorithme réversible (rot13, cryptage de masque…). Comme l’algorithme est réversible, ne respecte pas les règles de la CNIL.
En effet, il recommande que tout mot de passe soit transformé au moyen d’une fonction cryptographique non réversible. (source)
En outre, puisque l’attaquant connaît son mot de passe effacé/crypté, il peut deviner la logique du cryptage et essayer d’inverser ça. Si cela arrive, tous les mots de passe seront récupérés presque aussi rapidement que s’ils étaient en clair, quelle que soit la complexité de l’algorithme.
Fonctions de hachage obsolètes
Dans de nombreux cas, les mots de passe sont stockés avec des fonctions cryptographiques irréversibles obsolètes (md5, sha1…). Par exemple, le site LinkedIn a stocké certains de ses mots de passe avec sha1, et après avoir fui ces hachages en 2012, il n’a fallu que trois jours pour récupérer 90 % des mots de passe.
Imaginons la table de données suivante (les mots de passe sont les mêmes qu’avant)
| Connexion | Mot de passe (md5) |
| admin | ab4f63f9ac65152575886860dde480a1 |
| toto | 21b72c0b7adc5c7b4a50ffcb90d92dd6 |
| Billy | 47ad898a379c3dad10b4812eba843601 |
| tata | 21b72c0b7adc5c7b4a50ffcb90d92dd6 |
| titi | 5b9a8069d33fe9812dc8310ebff0a315 |
Note :
- Dans notre cas, tous les mots de passe (à l’exception de Billy) sont des mots de passe très fréquemment utilisés et se trouvent dans les mots de passe les plus couramment utilisés. (par exemple dans la liste 10-million-password-list-top-1000.txt)
- Il est également intéressant de noter que les hashs sans notion de hasard, toto et tante partagent le même hachage, car ils ont le même mot de passe.
Une simple recherche pour le hachage de l’administrateur sur Internet vous permet de trouver votre mot de passe directement.
À l’exception de l’utilisateur Billy qui a un mot de passe complexe, il est possible de trouver tous les hashs directement par des requêtes dans un moteur de recherche.
Si les hashs ne sont pas trouvés directement sur un moteur de recherche, l’attaquant a d’autres méthodes :
Force brute
La force brute est l’action d’essayer toutes les possibilités itérativement en suivant une règle de génération. C’est comme lorsque nous essayons d’ouvrir un verrou de code en listant toutes les possibilités de 0000 à 9999 jusqu’à ce qu’il s’ouvre.
Dictionnaire
Une attaque de dictionnaire est une attaque où vous essayez tous les termes présents dans une liste de mots. Plusieurs types de dictionnaires peuvent être imaginés :
- Un dictionnaire de langue
- Classement des mots de passe les plus utilisés
- Une liste adaptée à un contexte donné
Si nous prenons l’image du cadenas, nous pouvons imaginer une liste contextualisée de cette façon :
On sait que le cadenas appartient à « Tutu », qu’il aime le numéro 42, et qu’il est né le 26 novembre 2001. Nous pouvons donc supposer que le cadenas peut éventuellement contenir le nombre 42, 26, 11 et 01 et générer ainsi une liste basée sur ces critères.
Note : Par abus de langue, il est courant d’appeler une attaque de dictionnaire une attaque par force brute.
Table arc-en-ciel
Table arc-en-ciel est un sujet qui mérite un article seul. Rapidement, il s’agit d’une structure de données qui vous permet de trouver des mots de passe avec un bon stockage/compromis temporel. Cette structure a une liste de hachages précalculés et vous permet de trouver un hachage dans un temps acceptable. Beaucoup de tables arc-en-ciel sont disponibles en ligne.
Benchmark pour récupérer les mots de passe md5
Un benchmark a été effectué sur les hachages de mot de passe de notre article avec la liste rockyou, qui contient 14 341 564 mots de passe uniques. Le benchmark a été effectué sur une machine virtuelle, ce qui n’est pas optimal pour briser les mots de passe.
En regardant les résultats, nous voyons qu’à l’exception du mot de passe de Billy, qui ne figure pas dans la liste rockyou, les trois mots de passe ont été trouvés et il a fallu 11 secondes pour que le logiciel calcule tous les hachages présents dans rockyou.
Fonctions de hachage inadaptées
Après avoir vu les mauvais exemples précédents, il est tentant d’utiliser des fonctions sécurisées irréversibles comme sha256, sha512 ou sha3. Toutefois, le but de ces fonctions est de calculer un résumé cryptographique afin de vérifier l’intégrité d’un fichier, de faire une signature électronique ou d’optimiser la recherche et l’indexation. Ils ne conviennent pas au stockage des mots de passe, car ils sont rapides à calculer comme en témoigne le point de vue suivant :
| Connexion | Mot de passe (sha512) |
| admin | df6b9fb15cfdbb7527be5a8a8a6e39e572c8ddb943fbc79a943438e9d3d85ebfc2ccf9e0eccd9346026c0b6876e0e01556fe56f135582c05fbdbb505d46755a |
| toto | 11a25e88658143a853d280bf77f81ff391347aaba2db54a3a3aab0149b265276de419880762a473fc496388bcf70566d7cfd0346c34add40652f8f7b669caf9ec0 |
| Billy | fe9cb9b07725fd1cc3906232405119fedf9a020436630d3c1e0f632f73909e6ed9e731c149ac22743bbe9541881f35ceebf1d2782d469eb3b42968469d55a7a4 |
| tata | 11a25e88658143a853d280bf77f81ff391347aaba2db54a3a3aab0149b265276de419880762a473fc496388bcf70566d7cfd0346c34add40652f8f7b669caf9ec0 |
| titi | f767036acd951f5ddaf4eed5291c677db060055806dbcae69ca35d95847559dc8abce5011fd2b50833e760eca2d84d6d6daf1f078200f42b4fc10b58bad3761c88 |
Encore une fois, à l’exception de l’utilisateur Billy, tous les mots de passe ont été trouvés et il n’a fallu que 16 secondes pour que hashcat termine les calculs.
Améliorer SHA512
Bien qu’il ait été dit précédemment que la fonction SHA512 n’était pas optimisée pour le stockage des mots de passe, il peut être intéressant de montrer comment l’optimiser pour comprendre la valeur des fonctions de hachage adaptées pour les mots de passe.
Utilisation d’un sel
Le sel est un polluant pour les données brutes (ici le mot de passe) permettant de produire deux hachages différents à partir des mêmes données. Le sel est unique pour chaque utilisateur et il se compose d’une suite aléatoire. Il augmente les chances d’unicité d’un mot de passe et donc la chance qu’un hachage n’ait jamais été utilisé. Par exemple, avec sel, toto et tata n’auront pas le même hachage dans la base de données.
Les avantages du sel sont multiples :
- Il est presque impossible de trouver le hachage directement sur Internet s’il est salé. Cependant, le sel devrait être assez long et aléatoire.
- Les tables arc-en-ciel ne fonctionnent pas avec le hachage salé
- Comme indiqué précédemment, deux utilisateurs avec le même mot de passe n’auront pas le même hachage si sel est utilisé. Logiciel de rupture de mot de passe (hashcat, Johntheripper…), après avoir cassé un hachage, regardez s’il n’est pas présent pour un autre utilisateur. Ainsi, sans sel, après avoir découvert le mot de passe toto, celui de tante est directement découvert. De l’autre main, avec un sel, le logiciel doit commencer à partir de zéro pour chaque utilisateur.
Benchmark avec le sel
| Utilisateur | Sel | Hash sha512 avec sel |
| admin | BGDD6D6^zgvkmhkf @W3RqT | 7509d123bce1aa92331861cf8fd738a58205045123f0e25f0862477cb19d3ee0757cd99865c30b123ad1e7f1e31a6058090458cb9941031f5c36683c8446f |
| toto | HZBD^ @gL *WVOEXO6YJ7HVB | 6b28830776de6ad7ef1dd8c221e0d53fec4532c623075d0216d937ab82ab284a56a461ce5d4ec77d1783665a262a6a1eb98627b1f6260da55dbb782d7cb75bc4 |
| Billy | WvvnDjwczJy ! dwt4fbd @U ^ | 2847b2605f6a1cd88399e6c9784c0e583799be9485cb128fe5f541f436559067ec32de33e9b3fa2c15b15eec294cf262fd7aab2395dd6dbd9640b4fe6fd |
| papa | QenWM9nxQJ8m @m2 ^F7Kh9* | 165bc06b69fa2bfcd893bfde86358394406c87c7f7abba891cd10ed9fac887c54d52ed14310ad675078033e9bca80084d345fb2836933e55c60f734982430e2b |
| titi | IQUEMGW9M6GW*&V6RG%MZ# | f8eded6c815c7522ab6197aa319d3ff4cddc2c7eeffa0f91c1291603f807a47f320324d2fed1fb3cbfe19524fc5d9c105093f755d76a949efb212fb85c942 |
Avec Cette configuration a pris 33 secondes pour que le logiciel hashcat récupère les mots de passe. Aucun des hachages de la base de données n’est indexé par un moteur de recherche.
Utilisation d’un poivre
Le poivre est également un polluant, mais commun à tous les utilisateurs. Il est stocké non pas dans une base de données, mais dans les sources d’une application, dans un fichier de configuration ou en tant que variable d’environnement. Un attaquant qui a « juste » compromis une base de données doit deviner le poivre ou le récupérer d’une autre manière pour casser efficacement les hachages.
Augmentez le nombre de itérations
Une autre façon de renforcer la sécurité consiste à répéter le nombre d’itérations du hachage. Augmenter le nombre d’itérations signifie que nous allons hacher plusieurs fois le mot de passe. Par exemple, avec sha512, nous avons la boucle suivante :
Tant que l’itération est supérieure à 0 hachage = sha512 (hachage) Réduction de l’itération
Pour un utilisateur qui s’identifie, le calcul du hachage sera plus long (nous restons toujours dans l’ordre de la milliseconde). Mais lorsqu’un utilisateur perd quelques millisecondes pour se connecter, un attaquant perdra beaucoup plus de temps, parce que l’attaquant perdra plusieurs millisecondes dans les tentatives et que celui-ci effectue des millions, cela entraînera des heures/jours supplémentaires pour récupérer les mots de passe.
Fusionner les 3 méthodes
Nous pouvons fusionner les trois méthodes (sel, poivre et nombre d’itérations) pour avoir une méthode pour stocker les mots de passe plus en toute sécurité qu’un simple hachage.
Fonction calcul_hash (mot de passe, sel, poivre, itération) Inputspassword est le mot passe utilisateur dans clairsalt est le sel unique par utilisateur et est généré au hasard poivre est le poivre commun à tous les utilisateurs et est généré aléatoirement entiteration est le nombre d’itérationSoutput : Hash de mot de passe Hash = sha512 (sel mot de passe poivre) Tant que l’itération est supérieure à 0 hachage = sha512 (hachage) Réduction de l’itération hachage de retour
Ensuite, pour vérifier lors de la connexion des mots de passe, il suffit d’appeler la même fonction avec le mot de passe entré par l’utilisateur et de le comparer avec le hachage dans la base de données. Si les deux sont identiques, la connexion réussit.
Utilisation de fonctions spécifiques
Auparavant, nous avons réussi à créer un algorithme pour générer des hachages plus résistants aux logiciels de rupture de mot de passe. Cependant, des fonctions existent déjà et ont prouvé leur efficacité au fil du temps. Il est donc inutile de réinventer la roue au risque de causer des erreurs. Parmi ces différences, nous pouvons trouver : Argon2, scrypt, PBKDF2, bcrypt…
Ces fonctions ont de nombreux points forts :
- Plus lent à calculer
- Plus d’accès RAM intensif (ce qui est la faiblesse des GPU)
- Définition du nombre d’itérations de la fonction cryptographique utilisée. Comme on l’a vu précédemment, plus le calcul sera cher.
Bcrypt
bcrypt est une fonction de hachage créée par Niels Provos et David Mazières. Il est basé sur l’algorithme de cryptage Blowfish et a été présenté à USENIX en 1999.
Parmi ces points positifs en plus de ceux mentionnés ci-dessus, nous trouvons des implémentations dans de nombreuses langues. En outre, cet algorithme remontant à 1999, il a montré sa force dans le temps, où certains algorithmes comme Argon2 (i) n’existent que depuis 2015.
Le hachage calculé par bcrypt a un formulaire prédéfini :
$2y$11$sxaxzyioy60hbnymeoj9.ulscxwufmhbvlatxat729tgusw.5ag4c
- algorithme : Celui-ci peut prendre plusieurs versions selon la version de bcrypt ($2$, $2a$, $2x$, $2y$ et $2b$)
- Le coût : nombre d’itérations en puissance de 2. Par exemple ici l’itération est à 11, l’algorithme fera 211 itérations (2048 itérations)
- Sel : Au lieu de stocker le sel dans une colonne dédiée, il est stocké directement dans le hachage final
- Mot de passe haché
Puisque bcrypt stocke le nombre d’itérations, cela en fait une fonction adaptative, car nous pouvons augmenter le nombre d’itérations et donc celle-ci est plus longue et plus longue. Cela lui permet, malgré son âge et l’évolution de la puissance de calcul, d’être toujours robuste face aux attaques de force brute. Le brenchmark suivant montre qu’il faut 23 jours pour hashcat pour calculer tous les hachages rockyou.
Il est intéressant de noter que les mots de passe azerty et matriciels, étant des mots de passe très faibles et présents au début de la liste, ont été trouvés pendant la courte période (2 heures) où le logiciel fonctionnait dans l’exemple.
Constatation
Nous avons pu voir dans cet article l’utilité d’une fonction de hachage robuste et l’avantage d’utiliser une fonction déjà existante. En outre, le problème du stockage des mots de passe présente des problèmes juridiques en plus des problèmes de sécurité.
Enfin, il est intéressant de noter que dans tous les cas les mots de passe azerty et matriciels ont été trouvés rapidement, alors que le mot de passe yep59f$4txwrr n’a jamais été trouvé. En effet, puisque celle-ci n’est présente sur aucune liste, la seule façon de le trouver est d’effectuer une force brute exhaustive sur 13 caractères, ce qui est une opération très coûteuse dans le temps (en raison du grand nombre de possibilités de mots de passe). Cela aussi montre l’importance pour une application Web de forcer une stratégie de mot de passe forte.