Dans quelle mesure une fuite de hachage partielle serait-elle réaliste?
Même si la recommandation actuelle pour le stockage des mots de passe est l'utilisation d'une fonction de dérivation de clé lente comme Argon2, scrypt, PBKDF2 ou bcrypt1, de nombreux sites Web utilisent toujours la méthode traditionnelle hash(password + salt), MD5, SHA-1 et SHA-256 étant les fonctions de hachage les plus utilisées.
Le hachage SHA-1 de mySuperSecretPassword123 avec le sel !8(L-_20hs est E5D0BEE0300BF17508CABA842084753685781907.
Supposons qu'un attaquant vole le sel et la première moitié du hachage, donc E5D0BEE0300BF17508CA. Nous supposons également que l'attaquant sait que SHA-1 est utilisé et comment le sel et le mot de passe sont concaténés.
Serait-il difficile pour un attaquant de récupérer le mot de passe d'origine?
1 bcrypt techniquement n'est pas une fonction de dérivation de clé, mais pour les besoins de cette question, elle fonctionne de manière identique.
En fait, c'est aussi mauvais qu'une fuite de hachage complète.
Le hachage est effectué par:
- Génération de candidats de mot de passe
- Les hacher
- Comparaison des hachages résultants avec le hachage que vous souhaitez casser
Aucune de ces étapes ne sera plus lente en cas de fuite partielle de hachage, c'est donc très similaire à une fuite de hachage complète en termes de vitesse.
Veuillez noter que si la sortie de hachage partielle n'est pas assez longue, de nombreux candidats de mot de passe correspondront. Dans ce scénario, vous ne pouvez pas savoir quel candidat était le vrai mot de passe.
Cela dépend de la qualité du mot de passe et de la taille du préfixe de hachage.
Grand préfixe/mauvais mot de passe
Si nous supposons qu'il s'agit d'un hachage du mot de passe moyen de Joe qui contient disons 30 bits d'entropie ("mySuperSecretPassword123" contient presque certainement moins d'entropie que cela), et pour être conservateur, nous suivons principe de Kerckhoffs et supposons que l'attaquant sait comment le mot de passe a été généré, il n'y en a que 230 mots de passe possibles. Si le préfixe divulgué est à 80 bits d'un hachage SHA-1, il est extrêmement probable qu'il n'y aura qu'un seul candidat de mot de passe correspondant au préfixe de hachage.
Fondamentalement, si log2(password space) est plus petit que le préfixe divulgué, vous pourriez aussi bien considérer que le hachage entier a été divulgué.
Petit préfixe/bon mot de passe
Que faire si le préfixe est petit ou si le mot de passe est bon (ish)? Disons par exemple que vous avez un espace de mot de passe de 250et vous avez divulgué un préfixe de 40 bits. Un attaquant ne peut pas simplement casser le mot de passe, car il y en aura environ 2dix des mots de passe qui correspondent au hachage, mais c'est toujours un problème. 250 est beaucoup trop volumineux pour lancer une attaque en ligne, même sans limitation de débit. Mais si un attaquant peut pré-filtrer ses suppositions sur celles qui correspondent au préfixe dans une attaque hors ligne, il lui suffira d'essayer 2dix dans l'attaque en ligne, ce qui peut être faisable.
Si log2(password space) - prefix size > 0, l'attaquant ne sera probablement pas en mesure de déchiffrer le mot de passe exact, mais s'il est suffisamment petit, il peut générer un pool de mots de passe candidats à utiliser dans une attaque en ligne.
Très bon mot de passe
Bien sûr, si vous choisissez au hasard dans un espace de mot de passe supérieur à 2100 (pour être conservateur) avec une probabilité uniforme, puis la fuite d'un hachage partiel ou complet n'est pas pertinente, car elle ne sera jamais fissurée de toute façon.
Si vous ne disposez que d'un demi-hachage de 160 bits, cela signifie que vous avez 80 bits inconnus. Il en résulte 2 ^ 80 $ = 1,2089258196146292e + 24 $ de hachages possibles restants.
Cela signifie que votre mot de passe peut être haché à l'un de ceux-ci, et cela réduit de manière exponentielle le nombre de mots de passe possibles (2 ^ 80 fois moins), mais un attaquant NE PEUT PAS trouver votre mot de passe uniquement sur cette base, si nous supposons que votre mot de passe est totalement Aléatoire.
Évidemment, c'est rarement le cas, donc si quelqu'un devait utiliser une attaque de dictionnaire moderne qui génère le mot de passe, il se retrouverait probablement avec une liste relativement petite de mot de passe probable. Cette petite liste de mots de passe pourrait ensuite être testée par rapport au véritable service d'authentification pour obtenir le mot de passe précis.
TLDR:
- si le mot de passe est aléatoire: devrait être ok
- si le mot de passe peut être généré avec une attaque de dictionnaire moderne (par exemple: smolbanana73): Je recommanderais de le changer.
Remarque: Have I Been Pwned vous demande les premiers bits de votre mot de passe pour vérifier s'il figure dans leurs listes, mais il est suffisamment petit pour être insignifiant.