SHA-1 est-il sécurisé pour le stockage des mots de passe?

Conclusion: SHA-1 est aussi sûr que n'importe quoi contre les attaques de pré-image, mais il est facile à calculer, ce qui signifie qu'il est plus facile de monter une attaque bruteforce ou par dictionnaire. (La même chose est vraie pour les successeurs comme SHA-256.) Selon les circonstances, une fonction de hachage conçue pour être coûteuse en calcul (comme bcrypt) pourrait être un meilleur choix.

Certaines personnes lancent souvent des remarques comme "SHA-1 est cassé", alors j'essaie de comprendre ce que cela signifie exactement. Supposons que j'ai une base de données de hachages de mots de passe SHA-1 et qu'un attaquant avec un algorithme de rupture SHA-1 de pointe et un botnet avec 100000 machines y accède. (Avoir le contrôle de plus de 100 000 ordinateurs personnels signifierait qu'ils peuvent effectuer environ 10 à 15 opérations par seconde.) Combien de temps leur faudrait-il pour

1. trouver le mot de passe d'un utilisateur?
2. trouver le mot de passe d'un utilisateur donné?
3. connaître le mot de passe de tous les utilisateurs?
4. trouver un moyen de se connecter en tant que l'un des utilisateurs?
5. trouver un moyen de se connecter en tant qu'utilisateur spécifique?

Comment cela change-t-il si les mots de passe sont salés? La méthode de salage (préfixe, suffixe, les deux ou quelque chose de plus compliqué comme xor-ing) est-elle importante?

Voici ma compréhension actuelle, après quelques recherches sur Google. Veuillez corriger les réponses si j'ai mal compris quelque chose.

• S'il n'y a pas de sel, une attaque arc-en-ciel trouvera immédiatement tous les mots de passe (sauf ceux extrêmement longs).
• S'il existe un salt aléatoire suffisamment long, le moyen le plus efficace de trouver les mots de passe est une attaque par force brute ou par dictionnaire. Ni les attaques de collision ni les attaques de pré-image ne sont d'une aide pour trouver le mot de passe réel, donc les attaques cryptographiques contre SHA-1 ne sont d'aucune aide ici. L'algorithme utilisé n'a même pas beaucoup d'importance - on pourrait même utiliser MD5 ou MD4 et les mots de passe seraient tout aussi sûrs (il y a une légère différence car le calcul d'un hachage SHA-1 est plus lent).
• Pour évaluer à quel point "tout aussi sûr" est sûr, supposons qu'une seule exécution sha1 nécessite 1000 opérations et que les mots de passe contiennent des majuscules, des minuscules et des chiffres (c'est-à-dire 60 caractères). Cela signifie que l'attaquant peut tester 10 ¹⁵ * 60 * 60 * 24/1000 ~ = 10 ¹⁷ mots de passe potentiels par jour. Pour une attaque par force brute, cela signifierait tester tous les mots de passe jusqu'à 9 caractères en 3 heures, jusqu'à 10 caractères en une semaine, jusqu'à 11 caractères en un an. (Cela prend 60 fois plus pour chaque caractère supplémentaire.) Une attaque par dictionnaire est beaucoup, beaucoup plus rapide (même un attaquant avec un seul ordinateur pourrait la retirer en quelques heures), mais ne trouve que des mots de passe faibles.
• Pour se connecter en tant qu'utilisateur, l'attaquant n'a pas besoin de trouver le mot de passe exact; il suffit de trouver une chaîne qui donne le même hachage. C'est ce qu'on appelle une première attaque de préimage. Autant que je sache, il n'y a pas d'attaques pré-image contre SHA-1. (Une attaque bruteforce nécessiterait 2 ¹⁶⁰ opérations, ce qui signifie que notre attaquant théorique aurait besoin de 10 à ³⁰ ans pour la réaliser. Les limites de la possibilité théorique sont d'environ 2 ⁶⁰ opérations, au cours desquelles l'attaque prendrait quelques années.) Il y a des attaques de pré-image contre les versions réduites de SHA-1 avec un effet négligeable (pour le SHA-1 réduit qui utilise 44 pas au lieu de 80, le temps d'attaque est passé de ²¹⁶⁰ opérations à ²¹⁵⁷). Il y a des attaques par collision contre SHA-1 qui sont tout à fait dans les limites des possibilités théoriques ( le meilleur que j'ai trouvé ramène le temps de 2 ⁸⁰ à 2 ⁵² ), mais celles-ci sont inutiles contre les hachages de mots de passe, même sans salage.

En bref, stocker les mots de passe avec SHA-1 semble parfaitement sûr. Ai-je oublié quelque chose?

Mise à jour: Marcelo a signalé un article qui mentionne une deuxième attaque pré-image dans 2 ¹⁰⁶ opérations . ( Edit: Comme Thomas l'explique , cette attaque est une construction hypothétique qui ne s'applique pas aux scénarios de la vie réelle.) Je ne vois toujours pas comment cela représente un danger pour l'utilisation de SHA-1 comme fonction de dérivation de clé, cependant. Existe-t-il généralement de bonnes raisons de penser qu'une attaque par collision ou une seconde attaque de pré-image peut éventuellement être transformée en une première attaque de pré-image?

La réponse courte à votre question est: SHA-1 est aussi sûr que possible. MD5 conviendrait aussi, même MD4; mais cela pourrait rendre certains investisseurs nerveux. Pour les relations publiques , il est préférable d'utiliser une «meilleure» fonction de hachage, par exemple SHA-256, même si vous tronquez sa sortie à 160 ou 128 bits (pour économiser sur le coût de stockage). Certains des candidats de la ronde 2 de SHA-3 semblent être plus rapides que SHA-1 tout en étant sans doute «plus sûrs»; pourtant ils sont encore un peu nouveaux, donc s'en tenir à SHA-256 ou SHA-512 serait une route plus sûre pour le moment. Cela vous donnerait une apparence professionnelle et prudente, ce qui est bien.

Notez que «aussi sûr que possible» n'est pas la même chose que «parfaitement sûr». Voir ci-dessous pour des explications assez longues.

À propos des attaques connues:

Les attaques connues sur MD4, MD5 et SHA-1 concernent des collisions, qui n'ont pas d'impact sur la résistance de pré-image. Il a été démontré que MD4 a quelques faiblesses qui peuvent être (seulement théoriquement) exploitées en essayant de casser HMAC / MD4, mais cela ne s'applique pas à votre problème. L' attaque de 2 ¹⁰⁶ secondes de pré-image dans l'article de Kesley et Schneier est un compromis générique qui ne s'applique qu'aux entrées très longues (2 ⁶⁰ octets; c'est un million de téraoctets - remarquez comment 106 + 60 dépasse 160; c'est là que vous voyez que le compromis n'a rien de magique).

Le reste de ce message suppose que la fonction de hachage que vous utilisez (par exemple SHA-1) est une "boîte noire" sans propriété spéciale que l'attaquant peut utiliser. C'est ce que vous avez en ce moment même avec les fonctions de hachage "cassées" MD5 et SHA-1.

À propos des tables arc-en-ciel:

L '«attaque arc-en-ciel» est en fait le partage des coûts d'une attaque par dictionnaire ou par force brute. C'est un dérivé du compromis temps-mémoire décrit pour la première fois par Hellman en 1980. En supposant que vous ayez N mots de passe possibles (c'est la taille de votre dictionnaire, ou 2 ⁿ si vous envisagez de forcer brutalement une fonction de hachage avec une sortie de n bits), il y a une attaque en temps partagé dans laquelle vous précalculez les N mots de passe hachés et les stockez dans une grande table. Si vous triez les sorties de hachage, vous pouvez obtenir votre mot de passe en une seule recherche. Une table arc-en-ciel est un moyen intelligent de ranger cette table avec un espace beaucoup plus réduit. Vous stockez uniquement les mots de passe hachés N / t , et vous craquez les mots de passe avec O (t ² ) recherches. Les tables Rainbow vous permettent de gérer virtuellement des tables précalculées beaucoup plus grandes que ce que vous pouvez stocker de manière réaliste.

Cependant, arc-en-ciel ou non, l'attaquant doit toujours lancer l'attaque complète au moins une fois. Cela peut être vu comme plusieurs couches d'optimisation successives:

1. L'attaque par force brute / dictionnaire a coûté N pour déchiffrer chaque mot de passe.
2. Avec une table pré-calculée, l'attaquant paie ce coût N une fois et peut ensuite attaquer de nombreux mots de passe avec un très faible coût supplémentaire par mot de passe.
3. Si la table pré-calculée est une table arc-en-ciel, alors N peut être un peu plus grand, car le coût de stockage est réduit. Le goulot d'étranglement sur N devient la puissance du processeur que l'attaquant peut rassembler, pas la taille de ses disques durs.

Si N est suffisamment grand pour que le coût CPU du hachage de N mots de passe soit ridicule, alors une telle attaque n'est pas réalisable, que des tables arc-en-ciel soient utilisées ou non. Cela signifie qu'une fonction de hachage (résistante à la pré-image) avec une sortie de 80 bits ou plus est suffisante pour rendre impossible une attaque par force brute.

À propos des sels:

Les sels sont un moyen de contourner les pré-calculs. Dans la description ci-dessus, le salt ramène l'attaquant à l'étape 1: le salage empêche l'attaquant de partager le coût O ( N ) entre plusieurs mots de passe attaqués. Les tableaux pré-calculés, a fortiori les tableaux arc-en-ciel, ne sont plus réalisables.

Vous voulez saler parce que lorsque les données hachées consistent en des mots de passe , c'est-à-dire quelque chose qui rentre dans le cerveau d'un être humain aléatoire, alors N peut être assez faible: les humains sont vraiment mauvais pour choisir et se souvenir des mots de passe. C'est ce que sont les "attaques par dictionnaire": c'est utiliser un espace réduit de mots de passe potentiels (le "dictionnaire") sous l'hypothèse que de nombreux mots de passe d'utilisateurs seront dans cet espace spécialement sélectionné.

Par conséquent, le salage empêchera au moins l'attaquant d'utiliser des tables pré-calculées, en particulier des tables arc-en-ciel précalculées. Cela suppose que l'attaquant sera capable de casser un ou deux mots de passe; nous ne voulons pas qu'il casse 1000 autres mots de passe avec peu de frais supplémentaires.

De plus, le salage est bon pour les relations publiques.

À propos du coût SHA-1:

Le coût élémentaire de SHA-1 concerne le hachage d'un bloc de 64 octets. C'est ainsi que fonctionne SHA-1: les données sont complétées, puis divisées en blocs de 64 octets. Le coût de traitement d'un seul bloc est d'environ 500 cycles d'horloge sur un système Intel Core2, et c'est pour un seul cœur. MD5 et MD4 sont plus rapides, comptent respectivement environ 400 et 250 cycles. N'oubliez pas que la plupart des processeurs modernes ont plusieurs cœurs, alors multipliez-les en conséquence.

Certains systèmes de salage prescrivent des sels énormes; Par exemple, ce qui entre dans la fonction de hachage est en fait 40000 copies successives d'un seul sel de 128 bits, suivies du mot de passe lui-même. Cela rend le hachage de mot de passe plus cher (par un facteur de 10000 avec mon exemple), à ​​la fois pour l'utilisateur légitime et pour l'attaquant. Que ce soit une bonne idée dépend de la configuration. Pour se connecter sur un ordinateur de bureau, c'est bien: l'utilisateur ne remarquera même pas qu'il a fallu 10ms pour hacher son mot de passe, au lieu de 1µs; mais le coût pour l'attaquant a augmenté d'un facteur très notable de 10 000. Sur les serveurs partagés avec des milliers de clients par seconde, le coût global peut devenir prohibitif. Conceptuellement, relever la barre du même facteur pour l'utilisateur légitime et l'attaquant n'est pas en fin de compte une bonne sécurité; mais cela peut être une idée valable dans certaines situations spécifiques.

À propos des attaques en ligne:

Tout ce qui précède consiste à vaincre les attaques hors ligne . Une attaque hors ligne est une attaque où l'attaquant dispose de toutes les données dont il a besoin pour «tester» les mots de passe; par exemple, l'attaquant pourrait obtenir une copie de la base de données contenant les mots de passe hachés. Dans une attaque hors ligne, l'attaquant n'est limité que par ses ressources de calcul. Inversement, une attaque en ligne est une attaque où chaque hypothèse de l'attaquant doit passer par un vérificateur honnête (par exemple, l'attaquant essaie simplement de se connecter au système attaqué). Les attaques en ligne sont contrecarrées en imposant des limites sur le nombre de mots de passe pouvant être essayés par seconde. Des exemples extrêmes sont les cartes à puce qui s'éteignent après trois mauvais codes PIN.

Habituellement, pour la sécurité des mots de passe, il est beaucoup plus rentable d'organiser le système pour ne pas laisser un attaquant créer une attaque hors ligne. C'est ce que font les systèmes Unix: les mots de passe hachés, qui se trouvaient auparavant dans le /etc/passwordfichier lisible par le monde , sont maintenant dans le /etc/shadowfichier qui est protégé contre l'accès en lecture, sauf par quelques applications privilégiées. L'hypothèse ici est que si l'attaquant peut lire /etc/shadow, alors il a probablement suffisamment de contrôle sur le système pour qu'il n'ait plus vraiment besoin de mots de passe ...

Les réponses précédentes ne font aucune mention des GPU, qui peuvent paralléliser le hachage SHA-1 dans la mesure où une base de données entière peut maintenant être forcée brutalement en quelques minutes ou heures plutôt qu'en jours ou semaines, même si les mots de passe ont été salés.

Les algorithmes de hachage de mot de passe modernes tels que bcrypt ou scrypt sont spécialement conçus pour être difficiles à exécuter sur les GPU en raison du fait qu'il s'agit de chiffrements par blocs avec des exigences de mémoire beaucoup plus élevées (et l'accès à la mémoire dans un GPU ne peut pas être parallélisé dans la même mesure). Ils ont également une «fonction de travail» qui leur permet d'être ralentis à la volée à mesure que la technologie s'améliore.

En bref, vous ne devez utiliser que les meilleurs outils pour le travail. Et SHA-1 est très loin de l'état de l'art.

Pour en savoir plus:

• /crypto/400/why-cant-one-implement-bcrypt-in-cuda
• http://codahale.com/how-to-safely-store-a-password/
• http://www.codinghorror.com/blog/2012/04/speed-hashing.html
• /security/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

Votre description semble exacte pour l'état actuel de la technique.

Cependant, vous ne devriez pas utiliser une seule itération d'une fonction de hachage: à tout le moins, vous devez effectuer plusieurs itérations (1000 itérations du hachage multiplient par 1000 le travail de l'attaquant. Cela augmente votre travail du même montant, mais vous faites beaucoup moins de hachage de mot de passe qu'eux).

Dans l'idéal, cependant, vous devez utiliser une primitive de stockage de mot de passe existante, telle que celles décrites ici .

SHA1 est un résumé de message , il n'a jamais été conçu pour être une fonction de hachage de mot de passe (ou de dérivation de clé). (Bien qu'il puisse être utilisé comme un bloc de construction pour un KDF, comme dans PBKDF2 avec HMAC-SHA1.)

Une fonction de hachage de mot de passe devrait se défendre contre les attaques de dictionnaire et les tables arc-en-ciel. Plusieurs algorithmes ont été conçus pour atteindre cet objectif.

Actuellement, le meilleur choix est probablement Argon2 . Cette famille de fonctions de hachage de mot de passe a remporté le concours de hachage de mot de passe en 2015.

Si Argon2 n'est pas disponible, la seule autre fonction standardisée de hachage de mot de passe ou de dérivation de clé est PBKDF2 , qui est une ancienne norme NIST. D'autres choix, si l'utilisation d'une norme n'est pas requise, incluent bcrypt et le scrypt .

Wikipedia a des pages pour ces fonctions:

• https://en.wikipedia.org/wiki/Argon2
• https://en.wikipedia.org/wiki/Bcrypt
• https://en.wikipedia.org/wiki/Scrypt
• https://en.wikipedia.org/wiki/PBKDF2

De graves vulnérabilités ont été découvertes dans SHA-1 qui rendent la recherche beaucoup plus rapide que la force brute. Il est encore largement insoluble, mais on ne s'attend pas à ce que ce soit le cas trop longtemps; les programmeurs paranoïaques préfèrent quelque chose de la famille SHA-2.

De cet article concernant le résultat original de 2005:

"Il est temps de marcher, mais pas de courir, jusqu'aux sorties de secours. Vous ne voyez pas de fumée, mais les alarmes d'incendie se sont déclenchées."

Ce n'est pas que l'analyse cryptographique actuelle rend SHA-1 dangereux, mais plutôt que la communauté cryptographique craint que de pires nouvelles ne se profilent. Cette crainte s'applique également à SHA-2, qui présente les mêmes défauts que SHA-1, bien que sur un espace de recherche beaucoup plus grand, d'où la quête continue de SHA-3 .

En bref, SHA-1 est sûr pour le moment, et le sera probablement pendant un certain temps, mais la communauté crypto est mal à l'aise avec le pronostic.

Depuis février 2017, SHA-1 ne devrait plus être considéré comme sécurisé. Google a signalé le succès des attaques par collision contre le SHA-1 complet et non réduit ( lien vers le rapport ). Pour l'annonce de Google, cliquez ici .

Edit: Comme indiqué par d'autres, les mots de passe ne sont pas vulnérables aux attaques de collision de hachage. Cependant, en règle générale, je ne choisirais pas SHA-1 pour les applications liées à la sécurité. Il existe de meilleures alternatives.

Si vous stockez le mot de passe salé, SHA-1 convient à des fins pratiques. SHA-2 est considéré comme plus sûr, mais SHA-1 n'est pas un problème à moins que vous n'ayez une raison d'être vraiment paranoïaque.

Voici ce que dit le NIST :

Les résultats présentés jusqu'à présent sur SHA-1 ne remettent pas en cause sa sécurité. Cependant, en raison des progrès technologiques, le NIST prévoit d'éliminer progressivement SHA-1 au profit des fonctions de hachage plus grandes et plus puissantes (SHA-224, SHA-256, SHA-384 et SHA-512) d'ici 2010.