Le mot de passe est la méthode d'authentification utilisateur la plus courante, car elle est simple à comprendre et à utiliser pour les utilisateurs. Cependant, les mots de passe ont mauvaise réputation en raison de leurs faiblesses. Avec la cryptographie, il est possible de pallier ces faiblesses.
Identifiez les faiblesses des mots de passe
Je vous propose de voir en détail les différentes faiblesses reprochées aux mots de passe.
Ils sont courts
Un mot de passe est choisi par une personne qui doit le mémoriser, à la différence d'une clé secrète cryptographique aléatoire qui est stockée et manipulée par des machines. Un mot de passe est souvent court, il y a donc peu de combinaisons possibles. Cela le rend vulnérable à une attaque par force brute.
À titre de comparaison, pour calculer l'ensemble des combinaisons possibles d'une clé de 128 bits, il faudrait 10exp38 / = 10exp29 secondes soit 10exp21 années, un nombre bien plus élevé que l'âge de l'univers depuis le Big Bang !
Ils ont une faible entropie
Un mot de passe est généralement composé de mots du dictionnaire, de noms propres et de dates, plus faciles à mémoriser que des nombres aléatoires. Il est donc possible de constituer un dictionnaire de tous les mots de passe probables, qui ne contiendrait qu'une petite partie des combinaisons de caractères possibles.
Ils sont souvent réutilisés
Les utilisateurs ont tendance à réutiliser le même mot de passe sur plusieurs sites Internet différents. Le problème, c'est que si un attaquant vole la base de données utilisateurs d'un site Internet peu sécurisé, il pourra ensuite réutiliser les emails et mots de passe pour se connecter à d'autres comptes de l'utilisateur plus sensibles comme le compte email, le compte bancaire en ligne ou un compte professionnel. C'est pourquoi il est essentiel de stocker les mots de passe d'une manière sécurisée, c'est-à-dire qu'il soit difficile à un attaquant qui a accès à la base de données des mots de passe de retrouver la valeur des mots de passe. C'est ce que nous allons voir tout de suite.
Stockez les mots de passe de manière sécurisée
Lors d'une authentification par mot de passe, le serveur ne s'intéresse pas vraiment à la valeur du mot de passe. Le serveur vérifie simplement que le mot de passe fourni est identique au mot de passe défini lors de la création du compte. Il n'a donc pas besoin de stocker le mot de passe en clair, il peut simplement stocker son empreinte calculée avec une fonction de hachage cryptographique.
Une authentification par mot de passe comprend 2 étapes :
Lors de la création d'un compte, on calcule le haché du mot de passe et on stocke ce haché en base de données.
Lors des authentifications ultérieures, on calcule le haché du mot de passe fourni, et on vérifie qu'il est identique au haché stocké en base de données.
Cependant, les mots de passe ont une faible entropie et sont vulnérables à une attaque par force brute ou par dictionnaire. Utiliser une fonction de hachage cryptographique standard ne permet pas de pallier ces faiblesses. En effet, lors d'une attaque par dictionnaire sur une base de données volée, il suffit de calculer le haché de chaque entrée du dictionnaire et de le comparer avec les hachés de mots de passe de la base de données. Si deux hachés sont identiques, l'attaquant sait que le mot de passe correspond à l'entrée du dictionnaire correspondant.
Pour éviter cela, il faut utiliser des fonctions de hachage spécifiques au hachage de mots de passe.
Découvrez les fonctions de hachage de mot de passe
Une fonction de hachage de mot de passe est une fonction de hachage cryptographique spécialement conçue pour le stockage de mots de passe. Le nom plus technique de ces fonctions est fonction de dérivation de clé pour mot de passe (en anglais Password Based Key Derivation Function, ou PBKDF).
Les fonctions de hachage de mot de passe sont conçues pour être lentes, afin d'empêcher les attaques par force brute ou par dictionnaire. On appelle cette technique l'étirement de clé (key stretching).
Une fonction de hachage de mot de passe va par exemple mettre environ 10 ms pour calculer le haché d'un mot de passe. Un attaquant ne peut donc calculer que 100 hachés par seconde.
Ce facteur de temps pour calculer un haché peut être paramétré dans une fonction de hachage de mot de passe, pour l'augmenter ou le diminuer. Le principe est de l'augmenter au maximum sans impacter la vitesse du système (un utilisateur peut attendre jusqu'à 1 ou 2 secondes lorsqu'il s'authentifie) ou son fonctionnement (si beaucoup d'utilisateurs se connectent en même temps, le système doit être capable de calculer tous les hachés).
Voici les fonctions de hachage de mot de passe sécurisées actuelles :
Argon2. Gagnante de la compétition "Secure Password Hashing" en 2015, cette fonction permet de régler 3 niveaux de difficulté : le temps d'exécution, la quantité de mémoire nécessaire et la possibilité ou non de paralléliser les calculs ;
Scrypt. Alternative récente à Argon2 ;
bcrypt. Assez ancienne (1999), et éprouvée ;
PBKDF2 (Password Based Key Derivation Function 2). Assez ancienne (2000), certifiée par le NIST (organisme de standardisation américain).
Utilisez un salt pour contrer les rainbow tables
Avec une fonction de hachage lente, on rend les attaques par force brute plus difficiles, mais pas impossibles. Vous avez vu qu'avec une fonction de hachage de mots de passe, on peut calculer l'ensemble des hachés de mots de passe de 8 caractères en 1 mois avec 300 ordinateurs. Il s'agit juste d'un ordre de grandeur, mais on est loin de quelque chose de matériellement impossible.
Un attaquant peut calculer et stocker à l'avance les hachés des mots de passe les plus courants. À chaque base de données que l'attaquant vole, il lui suffit de comparer chaque haché avec ceux présents dans son dictionnaire des hachés. On appelle ce type de table une rainbow table.
Le problème vient du fait que le même mot de passe donne toujours le même haché.
Pour éviter cela, on utilise un nombre aléatoire, appelé salt, qu'on ajoute au mot de passe pour calculer le haché. On stocke ensuite le salt en clair avec le haché. Lors de la vérification de mot de passe, on récupère le salt correspondant à l'utilisateur, on calcule le haché à partir du mot de passe fourni par l'utilisateur et du salt, et on le compare avec le haché stocké à la création du mot de passe. Si les hachés sont identiques, le mot de passe est valide.
Si un attaquant vole la base de données, il aura accès non seulement aux hachés des mots de passe mais aussi au salt correspondant à chaque haché. Ainsi, l'attaquant est obligé de créer une rainbow table complète pour chaque mot de passe (en ajoutant le salt correspondant) de chaque base de données de hachés qu'il a récupéré. Dans la pratique, cela signifie qu'un attaquant sera capable de retrouver un petit nombre de mots de passe en clair, mais pas de casser les mots de passe à grande échelle.
Vous verrez dans le prochain chapitre un exemple d'algorithme de stockage de mots de passe en base de données, utilisant une fonction de hachage de mot de passe et un salt aléatoire.
Allez plus loin avec un pepper ou un HSM
Le vol de base de données est un problème courant, notamment à cause des failles de type injection SQL. L'utilisation d'une fonction de hachage de mots de passe avec salt permet de rendre un décryptage des hachés de mots de passe plus difficile, mais pas impossible.
Certaines entreprises ajoutent donc une dernière couche à la sécurité du stockage de mots de passe.
Comment cela se passe-t-il ?
En général, le serveur de base de données et le serveur d'application sont deux serveurs différents. Le serveur d'application récupère le haché et le salt du serveur de base de données, et traite les calculs de haché. Il est possible de rajouter en plus du salt un autre nombre aléatoire, souvent appelé le pepper, qui n'est pas stocké dans la base de données mais directement sur le serveur d'application.
Ainsi, si un attaquant vole la base de données mais n'a pas accès au serveur d'application, il ne connaîtra pas la valeur du pepper utilisé en plus du mot de passe et du salt, et ne pourra donc pas faire une attaque par force brute ou par dictionnaire. Si l'attaquant a accès au serveur d'application en revanche, le pepper n'apporte plus aucune sécurité. On utilise un pepper unique pour tous les mots de passe.
En résumé
Les mots de passe sont vulnérables aux attaques de force brute et dictionnaire en raison de leur faible entropie ;
pour stocker des mots de passe, il faut utiliser une fonction de hachage de mots de passe sécurisée avec un salt ;
les fonctions de hachage de mots de passe sont lentes pour éviter les attaques de force brute ;
on utilise un salt aléatoire différent pour chaque mot de passe, afin que 2 mots de passe identiques aient un haché différent pour éviter les attaques par rainbow table ;
on peut utiliser en plus un pepper dans le serveur d'application pour se protéger d'une attaque qui donne accès à la base de données, mais pas au serveur d'application.
