Quelle est la raison spécifique de préférer bcrypt ou PBKDF2 à SHA256-crypt dans les hachages de mot de passe?
Nous savons que pour ralentir la fissuration des mots de passe en cas de fuite de la base de données de mots de passe, les mots de passe doivent être enregistrés uniquement dans un format haché. Et non seulement cela, mais haché avec une fonction forte et lente avec une possibilité de faire varier le nombre de tours.
Souvent, des algorithmes tels que PBKDF2 , bcrypt et scrypt sont recommandés pour cela, bcrypt semblant obtenir les votes les plus forts, par ex. ici , ici et ici .
Mais qu'en est-il des hachages basés sur SHA256 et SHA512 implémentés dans au moins glibc ( description , spécification ) et utilisés par défaut au moins sur certaines distributions Linux pour les comptes de connexion réguliers? Y a-t-il une raison de ne pas les utiliser ou de préférer autrement bcrypt aux hachages basés sur SHA-2?
Bien sûr, bcrypt est beaucoup plus ancien (1999) et donc plus établi, mais les hachages SHA-2 ont déjà neuf ans (2007), et scrypt est encore plus jeune un peu (2009), mais semble encore être mentionné plus souvent. Est-ce simplement une pratique acceptée ou y a-t-il une autre raison? Y a-t-il des faiblesses connues dans les hachages basés sur SHA-2, ou quelqu'un a-t-il regardé?
Remarque: Je veux dire spécifiquement les hachages de mot de passe multi-tours décrits par le documents liés et marqués des codes $5$ et $6$ dans crypt hachages, pas un seul tour des fonctions de hachage SHA256 ou SHA512 .
J'ai vu la question qui est marquée comme un double possible de. Les réponses ne mentionnent pas les hachages SHA256-crypt/SHA512-crypt, ce que je recherche.
La principale raison d'utiliser une fonction de hachage de mot de passe spécifique est de rendre la vie plus difficile aux attaquants ou, plus précisément, de les empêcher de se faciliter la vie (par rapport à celle du défenseur). En particulier, l'attaquant peut vouloir calculer plus de hachages par seconde (c'est-à-dire essayer plus de mots de passe par seconde) avec un budget donné en utilisant un GPU.
SHA-256, en particulier, profite beaucoup de sa mise en œuvre sur un GPU. Ainsi, si vous utilisez SHA-256-crypt, les attaquants seront plus avantagés que si vous utilisez bcrypt, qui est difficile à implémenter efficacement dans un GPU.
Voir cette réponse pour une discussion sur bcrypt vs PBKDF2. Bien que SHA-256-crypt ne soit pas PBKDF2, il est assez similaire dans son comportement de performance sur GPU, donc les mêmes conclusions s'appliquent.
Le cas du SHA-512 est un peu moins clair car le GPU existant utilise beaucoup mieux les entiers 32 bits que le 64 bits, et le SHA-512 utilise principalement des opérations 64 bits. On s'attend toujours à ce que le GPU moderne permette plus de hachages par seconde que le CPU (pour un budget donné) avec SHA-512-crypt, ce qui pointe à nouveau vers bcrypt comme le meilleur choix.
La famille de hachages SHA-2 a été conçue pour être rapide. BCrypt a été conçu pour être lent. Les deux sont considérés comme robustes. Avec suffisamment de tours ou de facteur de travail, l'un ou l'autre peut prendre plus de temps que l'autre, mais je pencherais pour celui qui était conçu pour être lent. (si la charge du serveur est un problème, le facteur de travail est réglable)
De plus, je pencherais pour BCrypt car il s'agit généralement d'une implémentation compilée (C ou C++).
Le multi-round SHA peut facilement être implémenté dans un langage de haut niveau, au moins pour l'itération, sinon aussi pour le hachage lui-même. Les langages de haut niveau sont moins efficaces pour les opérations mathématiques de base réduisant la nombre de tours que votre matériel de production peut effectuer par milliseconde.
Alors que les deux algorithmes peuvent être implémentés dans des langages de haut ou bas niveau, ou hybrides; dans BCrypt les options disponibles dictent que vous êtes plus susceptible d'atterrir sur une implémentation efficace . (vous met sur un pied d'égalité avec l'attaquant)
En ce qui concerne votre exemple spécifique du /etc/shadow, vous n'utilisez probablement que des algorithmes de bas niveau (efficaces). (SHA ou BCrypt) Dans cet exemple, je vous suggère de consulter la documentation du système d'exploitation pour optimiser les tours (facteur de travail) en fonction de la vitesse du matériel - vs- à quel point vous aimeriez que le hachage soit.
scrypt (avec un facteur de travail suffisamment grand) a l'avantage supplémentaire d'avoir des exigences supplémentaires en RAM/mémoire (pas seulement CPU), ce qui en fait plus Résistant au GPU que SHA, BCrypt ou PBKDF2.
Edit: Merci à Thomas pour avoir souligné que BCrypt est plus résistant au GPU que SHA-2, et que SHA-2 et PBKDF2 sont pratiquement équivalents à cet égard .
Remarque: Je regarde cette question après que cette modification a été effectuée, et en tenant compte:
Remarque: Je veux dire spécifiquement les hachages de mot de passe multi-tours décrits par les documents liés et marqués avec les codes $ 5 $ et $ 6 $ dans les hachages de cryptage, pas un seul tour des fonctions de hachage SHA256 ou SHA512.
En regardant l'algorithme long en 22 étapes dans ce lien que vous avez fourni , je préfère retourner une question: pourquoi préféreriez-vous utiliser cela au lieu de PBKDF2 avec HMAC -SHA2? Parce qu'au moins tel que présenté:
- La définition de PBKDF2 semble beaucoup plus simple. C'est parce qu'il est plus modulaire - il reporte la plupart de son travail à une fonction pseudo-aléatoire fournie de l'extérieur. Ceci est normalement instancié avec HMAC , qui à son tour reporte la plupart de son travail à une fonction de hachage externe comme SHA-1 ou SHA-2.
- Cela signifie que la sécurité de PBKDF2 devrait être plus facile à analyser.
En revanche, l'algorithme du document que vous fournissez répertorie une tonne d'étapes dont la motivation est plus difficile à comprendre. Par exemple:
11. For each bit of the binary representation of the length of the
password string up to and including the highest 1-digit, starting
from to lowest bit position (numeric value 1):
a) for a 1-digit add digest B to digest A
b) for a 0-digit add the password string
NB: this step differs significantly from the MD5 algorithm. It
adds more randomness.
Cela ajoute plus de hasard? Comment fait-il cela? Pourquoi cette étape existe-t-elle du tout - SHA-2 n'ajoute-t-il pas un caractère aléatoire suffisant? Si SHA-2 n'est pas assez aléatoire, pourquoi l'utiliser en premier lieu? Et cette étape n'introduit-elle pas branchement dépendant du secret dans l'algorithme, ce qui soulève la question du possible timing des attaques contre lui?
Je ne dis nullement que les algorithmes que vous liez ne sont pas sûrs. C'est juste ça:
- Le facteur de travail qu'ils introduisent revient à la même chose que PBDKF2 - HMAC-SHA2 (un grand nombre d'itérations SHA2);
- Ils ressemblent très largement à ce que vous auriez si vous dérouliez une implémentation PBKDF2-HMAC-SHA2, mais avec une complexité supplémentaire dont je ne comprends pas le but;
- Donc au moins tel que présenté dans ces documents, je trouve qu'il est plus difficile de gagner en confiance sur leur conception que pour PBKDF2.
EDIT: Après avoir écrit tout cela, je suis allé et j'ai fait un peu de recherche sur cet algorithme pour essayer de mieux le comprendre. Tout d'abord, à partir des liens "description" et "spécification" de la question, nous apprenons que l'algorithme a été dérivé d'un ancien basé sur MD5 en faisant des modifications relativement mineures.
Cet ancien algorithme basé sur MD5 apparaît celui que Poul-Henning Kamp a écrit pour FreeBSD-2.0 en 1994 , qui il ne considère plus sûr . Dans le premier lien (où il raconte l'histoire de la fonction), il mentionne que la glibc a également adopté sa fonction. Il établit également un lien avec article de Provos et Mazières de 1999 sur bcrypt et mentionne qu'il a exprimé une certaine désapprobation, et assez drôle ils ont souligné la même étape qui a attiré mon attention ci-dessus :
MD5 crypt hache le mot de passe et le sel dans un certain nombre de combinaisons différentes pour ralentir la vitesse d'évaluation. Certaines étapes de l'algorithme font douter que le schéma ait été conçu d'un point de vue cryptographique - par exemple, la représentation binaire de la longueur du mot de passe à un moment donné détermine quelles données sont hachées, pour chaque bit zéro le premier octet du mot de passe et pour chaque bit défini, le premier octet d'un calcul de hachage précédent.
Mais je pense que cela explique la motivation des nouvelles fonctions que vous demandez: elles sont une modification très minime d'une fonction plus ancienne qui est antérieure à la plupart des fonctions de hachage de mot de passe modernes, dont la conception a été remise en question mais n'est probablement pas fondamentalement cassée, juste inutilement complexe.
La famille SHA-2 elle-même n'est pas nécessairement mauvaise. De par leur conception, il n'y a pas vraiment de failles de sécurité qui rendent bcrypt ou scrypt préférable. Cependant, le problème que de nombreux experts en sécurité ont avec SHA est qu'il est trop rapide et qu'il ne nécessite pas beaucoup de mémoire. En comparaison, une fonction de hachage comme scrypt est beaucoup plus lente et coûteuse, donc pour parler.
Scrypt nécessite une quantité de mémoire décente pour calculer. En plus de toute cette mémoire, et en grande partie en raison de la nécessité de tant de mémoire, scrypt nécessite beaucoup de temps de calcul par rapport à SHA. Cette réponse du site BitCoin Stack Exchange résume assez bien les avantages de scrypt: Quelles caractéristiques de scrypt () rendent Tenebrix GPU-résistant? En substance, scrypt est conçu pour être lent et gourmand en mémoire. Les GPU n'aiment pas ça. Les GPU n'ont généralement pas la capacité de mémoire pour stocker toute la mémoire nécessaire pour le calcul du scrypt sans avoir à recourir à des méthodes de blocage d'exécution ( où le GPU bloque tous les threads car il ne peut récupérer que les valeurs de la mémoire partagée une par une ), et donc les GPU ne peuvent pas fournir de gros avantages par rapport aux CPU en termes de temps de traitement. Bcrypt est similaire.
Bcrypt a fait ses preuves pour le hachage de mot de passe. Il existe depuis 17 ans et il fait toujours le travail. Cependant, un jour, la technologie GPU progressera au point où elle sera capable de calculer bcrypt plus rapidement et plus efficacement qu'un CPU. La technologie évolue et se développe toujours, donc cela arrivera finalement. Ce jour-là, bcrypt ne sera plus un excellent choix pour le hachage de mot de passe, et les cryptographes et les experts en sécurité devront remplacer bcrypt par un algorithme similaire qui est plus lent et plus gourmand en mémoire que le bcrypt existant. Peut-être que ce sera scrypt, mais qui va dire. Alors, pourquoi SHA désapprouvé?
SHA est généralement découragé non pas à cause de failles de sécurité, mais à cause de sa vitesse et de sa capacité à être implémenté sur un GPU. Quelqu'un avec des machines/une puissance de calcul illimitées pourrait casser n'importe quel type d'algorithme de hachage, que ce soit SHA, bcrypt ou scrypt, mais c'est théorique. Dans la pratique, un attaquant n'aura pas un nombre illimité de machines pour essayer de casser des hachages et, par conséquent, plus vous pouvez ralentir cet attaquant, plus il lui sera difficile de casser un mot de passe. Il y a une limite budgétaire pour tout, et le craquage de mot de passe ne fait pas exception. L'attaquant ne peut casser les mots de passe que si son budget le permet. ( La meilleure technologie qu'ils peuvent acheter dans le cadre de leur budget, le coût de fonctionnement de cette technologie (par exemple, les coûts électriques), etc. ) Bien sûr, vous pourriez implémenter plusieurs séries de SHA pour ralentir sévèrement un attaquant, mais pourquoi ne pas simplement utiliser bcrypt à ce stade? Entre autres choses, à mesure que la technologie GPU progresse dans un avenir proche, vous devrez ajouter plus et plus de tours/itérations à vos SHA calculs pour le ralentir au point où il est plus lent que bcrypt. Cependant, à mesure que la technologie GPU progresse, bcrypt restera sans phase, jusqu'au point où GPU La technologie permet à bcrypt d'être calculé efficacement. Par conséquent, bcrypt est le choix préférable dans la mesure du possible, non pas parce que SHA n'est pas sûr, mais parce que SHA est trop efficace en termes de calcul).
Eh bien, l'un des caractéristiques de bcrypt est que c'est un algorithme très lent. Cette lenteur offre une sécurité supplémentaire pour les attaques par force brute. Mais pour cette même raison, ce n'est peut-être pas la meilleure solution, par exemple pour les serveurs Web très utilisés, car ici une machine très chargée devra effectuer ce calcul lourd à chaque connexion.
Mais tant que votre système peut l'accepter, ce temps supplémentaire dérange en fait les attaquants de force brute.