Le stockage sécurisé des mots de passe est une préoccupation récurrente. Mais quelles sont les principales méthodes, comment fonctionnent-elles et quelle est leur valeur par rapport aux techniques actuelles de craquage de mots de passe ? Dans cet article, nous expliquons les principaux principes du stockage sécurisé (hachage, sel, poivre, itération) et soulignons leur importance pour résister aux méthodes de récupération de mot de passe. Enfin, nous parlerons d'une fonction de hachage fiable pour un stockage sécurisé.

Lire également : Les avantages de la maîtrise de WordPress

Mots de passe en texte brut

Supposons qu'un attaquant parvient à récupérer une base de données d'une application Web et en extrait le couple.

Dans Dans ce cas, l'attaquant possède directement les mots de passe de tous les utilisateurs en texte brut. Même Billy qui a un mot de passe fort n'est pas protégé.

A lire également : Quelle solution d’hébergement choisir pour le système de votre entreprise ?

Le stockage des mots de passe en texte brut n'est PAS une solution sécurisée. Personne, y compris les administrateurs de site Web ou de base de données, ne devrait avoir accès au mot de passe en texte brut de l'utilisateur.

Mots de passe cryptés

Dans certains cas, les mots de passe sont stockés dans une base de données après avoir été chiffrés par un algorithme réversible (rot13, cryptage de masque...). L'algorithme étant réversible, il n'est pas conforme aux règles de la CNIL (Commission nationale de l'informatique et de la liberté).

En effet, il recommande que tout mot de passe soit transformé par une fonction cryptographique non réversible. (source en français)

Puisque l'attaquant connaît son mot de passe en clair ou crypté, il peut deviner la logique du cryptage et essayer de l'inverser. S'il réussit, tous les mots de passe seront récupérés aussi rapidement qu'en texte brut, quelle que soit la complexité de l'algorithme.

Fonction de hachage obsolète

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 stockait une partie de ses mots de passe avec sha1, et après les fuites de hachage en 2012, il n'a fallu que trois jours pour récupérer 90 % des mots de passe. (source en français)

Prenons la base de données suivante (les mots de passe sont les mêmes que précédemment).

A noter :

• • Dans notre cas, tous les mots de passe (sauf celui de Billy) sont des mots de passe très fréquemment utilisés et font partie des mots de passe les plus utilisés (par exemple dans le fichier 10-million-password-list-top-1000.txt).
  • Il est également intéressant de noter que puisque les hachages n'ont pas de notion d'aléatoire, toto et tata partagent le même hachage, comme ils ont le même mot de passe.

Une simple recherche du hackage de l'administrateur sur Internet permet de récupérer directement ses mots de passe.

À l'exception de l'utilisateur Billy qui possède un mot de passe complexe, il est possible de récupérer tous les hachages directement par des requêtes dans un moteur de recherche.

Si les hachages ne se trouvent pas directement dans un moteur de recherche, l'attaquant a d'autres méthodes :

Force brute

La force brute consiste à essayer toutes les possibilités de manière itérative en suivant une règle de génération. C'est comme lorsque nous essayons d'ouvrir un cadenas en listant toutes les possibilités de 0000 à 9999 jusqu'à l'ouverture du cadenas.

Dictionnaire

Une attaque par dictionnaire est une attaque qui consiste à essayer tous les termes d'une liste de mots. Plusieurs types de dictionnaires peuvent être imaginés :

• Un dictionnaire de langues ;
• Un 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 comme celle-ci :

Nous savons que le cadenas appartient à « Tutu », qu'il adore le numéro 42 et qu'il est né le 26 novembre 2001. Par conséquent, nous peut supposer que le cadenas peut éventuellement contenir les numéros 42, 26, 11 et 01 et ainsi générer une liste en fonction de ces critères.

Remarque : En cas d'abus de langage, il est courant d'appeler une attaque par dictionnaire une attaque par force brute.

Table arc-en-ciel

Les tables Rainbow sont un sujet qui mérite un article en soi. Rapidement, il s'agit d'une structure de données qui permet de récupérer des mots de passe avec un bon compromis de stockage et de temps. Cette structure contient une liste de hachages précalculés et permet de récupérer un hachage dans un délai acceptable. De nombreuses tables arc-en-ciel sont disponibles en ligne.

Benchmark pour récupérer les mots de passe Md5

Un benchmark a été réalisé sur la base de données avec la liste rockyou qui contient 14 341 564 mots de passe uniques. Le benchmark a été réalisé sur une machine virtuelle, ce qui n'est pas optimal pour casser mots de passe.

En regardant les résultats, nous constatons 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 que seulement 11 secondes ont été nécessaires au logiciel pour calculer tous les hachages présents dans rockyou.

Fonction de hachage inappropriée

Après avoir vu les mauvais exemples précédents, il est tentant d'utiliser des fonctions sécurisées et irréversibles telles que sha256, sha512 ou sha3. Toutefois, le but de ces fonctions est d'être utilisé pour calculer un résumé cryptographique afin de vérifier l'intégrité d'un fichier, de créer une signature électronique ou d'optimiser la recherche et l'indexation. Ils ne sont pas adaptés au stockage des mots de passe, car ils sont rapides à calculer, comme le prouve le benchmark suivant :

(sha512)11a25e88658143a853d280bf77f81ff391347aaba2db54a3aab0149b265276de419880762a473fc496388bcf70566d7cfd 0346c34 add40652f8f7b669caf9ec0

Ici encore, à l'exception de l'utilisateur Billy, tous les mots de passe ont été récupérés et seulement 16 secondes ont été nécessaires pour que hashcat termine son opérations.

Amélioration de SHA512

Même s'il a déjà été dit 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 l'intérêt des fonctions de hachage approprié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 est composé d'une séquence aléatoire. Il augmente les chances qu'un mot de passe soit unique et donc les chances qu'un hachage n'ait jamais été utilisé. Par exemple, avec salt, toto et tata n'auront pas le même hachage dans la base de données.

Les avantages du sel sont multiples :

1. Il est presque impossible de trouver du hachage directement sur Internet s'il est salé. Cependant, le sel doit être long assez et aléatoire.
2. Les tables Rainbow ne fonctionnent pas avec du hasch salé.
3. Comme indiqué précédemment, deux utilisateurs ayant le même mot de passe n'auront pas le même hachage si Salt est utilisé. Un logiciel de craquage de mot de passe (hashcat, Johntheripper...), après avoir cassé un hachage, cherche à voir s'il n'est pas présent pour un autre utilisateur. Par conséquent, sans sel, après avoir découvert le mot de passe de toto, le mot de passe de tata est découvert directement. Cependant, avec un sel, le logiciel doit recommencer à zéro pour chaque utilisateur.

Benchmark avec du sel

sel165bc06b69fa2bfcd893bfde86358394406c87c7f7abba891cd10ed9fac887c54d52ed14310ad 675078033e9bca80084d345fb2836933e55c60f734982430e2b

EMGW9M6GW* & V6rg%MZ #

f8eded6c815c7522ab6197aa319d3ff4cddc2c7eeffa0f91c1291603f807a47f320324ddc2c7eeffa0f91c1291603f807a47f320324dd32ce2fed1fb3cbfe19524fc5d9c105093f755d76a949efb212fb942c8542

Avec ça , il a fallu 33 secondes au logiciel Hashcat pour récupérer les mots de passe. Aucun des hachages de la base de données n'est indexé par un moteur de recherche.

Utilisation de Pepper

Le poivre est également un polluant, mais commun à tous les utilisateurs. Il n'est pas stocké dans une base de données, mais dans les sources d'une application, dans un fichier de configuration ou dans une variable d'environnement. Un attaquant ayant « juste » compris une base de données doit deviner le poivre ou le récupérer d'une autre manière pour pouvoir casser efficacement les hachages.

Augmentation du nombre d'itérations

Une autre façon d'augmenter la sécurité consiste à répéter le nombre d'itérations de hachage. L'augmentation du nombre d'itérations signifie que nous allons hacher le mot de passe plusieurs fois. Par exemple, avec sha512, nous avons la boucle suivante :

Tant que l'itération est supérieure à 0 hachage = sha512 (hachage) itération de décrémentation

Pour un utilisateur qui se connecte, le calcul du hachage sera plus long (il faudra encore une milliseconde). Mais lorsqu'un utilisateur perd quelques millisecondes pour se connecter, un attaquant perdra beaucoup plus de temps, car il perdra plusieurs millisecondes par tentative, et comme l'attaquant effectue des millions de tentatives, cela entraînera des heures ou des 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 de manière plus sécurisée qu'un simple hachage.

Fonction calculation_hash (mot de passe, sel, poivre, itération) Entrées password est le mot de passe de l'utilisateur en texte brut (salt) est le sel unique par utilisateur et est généré aléatoirement. pepper est le poivre commun à tous les utilisateurs et est généré aléatoirement. L'itération est le nombre d'itérations Sortie : Le hachage du mot de passe Hachage = sha512 (sel mot de passe poivre) Tant que l'itération est supérieure à 0 hash = sha512 (hachage) itération de décrémentation hash de retour

Ensuite, pour vérifier les mots de passe lors de la connexion, il suffit d'appeler la même fonction avec le mot de passe saisi par l'utilisateur et de le comparer au hachage de la base de données. Si les deux sont identiques, la connexion est réussie.

Utilisation de fonctions spécifiques

Auparavant, nous avons réussi à créer un algorithme générant des hachages plus résistants aux logiciels de craquage de mots 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 et de risquer de provoquer des erreurs. Parmi ces différentes fonctions, on retrouve : Argon2, scrypt, PBKDF2, bcrypt...

Ces fonctions présentent de nombreux atouts :

• • Lent à calculer ;
  • Plus gourmands en RAM (ce qui est le point faible des GPU) ;
  • Définition du nombre d'itérations du fonction cryptographique utilisée. Comme on l'a vu précédemment, plus il y a d'itérations, plus le calcul sera coûteux.

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, on trouve des implémentations dans de nombreux langages. De plus, depuis que cet algorithme remonte à 1999, il a montré sa robustesse au fil du temps, certains algorithmes comme Argon2 (i) n'existent que depuis 2015.

Le hachage calculé par bcrypt a une forme prédéfinie :

$2 Y $11 $ Sxaxz Yioy60 HBNYMEOJ 9.ULSCXWUFMHBVLATX au 729 TGUSW.5 AG4C

1. Algorithme : Celui-ci peut prendre plusieurs versions en fonction de la version de bcrypt ($2$, $2a$, $2x$, $2y$ et $2b$).
2. Le coût : Le nombre de itérations en puissance de 2. Par exemple, ici, l'itération est de 11, l'algorithme effectuera 211 itérations (2048 itérations).
3. Sel : Au lieu de stocker le sel dans une colonne dédiée, il est directement stocké dans le hachage final.
4. Le mot de passe haché.

Comme bcrypt stocke le nombre d'itérations, cela en fait une fonction adaptative, car le nombre d'itérations peut être augmenté et donc il est de plus en plus long. Cela lui permet, malgré son âge et l'évolution de la puissance de calcul, de rester robuste face aux attaques par force brute. Le benchmark suivant montre qu'il faut 23 jours à Hashcat pour calculer la totalité des hachages rockyou.

Il est intéressant de noter que les mots de passe azerty et matrix, étant des mots de passe très faibles et présents en haut de la liste, ont été trouvés pendant le court laps de temps (2 heures) que le logiciel a travaillé dans l'exemple.

Conclusion

Nous avons vu dans cet article l'utilité d'une fonction de hachage robuste et l'avantage d'utiliser une fonction déjà existante. De plus, 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 matrix ont été trouvés rapidement, alors que le mot de passe yep59f$4txwrr n'a jamais été trouvé. En effet, comme celui-ci n'est présent 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 longue (en raison du grand nombre de possibilités de mots de passe). Cela montre également à quel point il est important pour une application Web de forcer une stratégie de mot de passe forte.