Est-ce que SHA-1 est sécurisé pour le stockage du mot de passe?

Question

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 un dictionnaire ou une force vive attaque. (Il en va de même pour les successeurs tels que SHA-256.) Selon les circonstances, une fonction de hachage conçue pour être onéreuse en calcul (telle que bcrypt) peut constituer un meilleur choix.

Certaines personnes font souvent des remarques telles que "SHA-1 est cassé", j'essaie donc de comprendre ce que cela signifie exactement. Supposons que je dispose d'une base de données de hachages de mots de passe SHA-1 et qu'un attaquant doté d'un algorithme de pointe SHA-1 et d'un botnet de 100 000 machines y ait accès. (Avoir le contrôle de 100 000 ordinateurs domestiques signifierait qu’ils peuvent effectuer environ 10 ^ 15 opérations par seconde.) Combien de temps faudrait-il à

trouver le mot de passe d'un utilisateur?
trouver le mot de passe d'un utilisateur donné?
trouver le mot de passe de tous les utilisateurs?
trouver un moyen de se connecter en tant qu'utilisateur?
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, postfixe, les deux, ou quelque chose de plus compliqué que le xor-ing) est-elle importante?

Voici ma compréhension actuelle, après avoir googlé. S'il vous plaît corriger dans les réponses si j'ai mal compris quelque chose.

S'il n'y a pas de sel, une attaque Rainbow trouvera immédiatement tous les mots de passe (à l'exception des extrêmement longs).
S'il existe un sel aléatoire suffisamment long, le moyen le plus efficace de connaître les mots de passe est une attaque par force brute ou par dictionnaire. Ni les attaques par collision ni les attaques de pré-image ne sont utiles pour connaître le mot de passe actuel. Les attaques cryptographiques contre SHA-1 ne sont donc d'aucune aide. Le type d’algorithme utilisé importe peu - on pourrait même utiliser MD5 ou MD4 et les mots de passe seraient tout aussi sûrs (il existe une légère différence, car le calcul d’un hachage SHA-1 est plus lent).
Pour évaluer le niveau de sécurité "tout aussi sûr", supposons qu'une seule exécution de sha1 nécessite 1 000 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¹⁷ mot de passe potentiel par jour. Pour une attaque par force brute, cela impliquerait de tester tous les mots de passe jusqu'à 9 caractères en 3 heures, jusqu'à 10 caractères dans une semaine, jusqu'à 11 caractères dans une année. (Cela prend 60 fois plus pour chaque caractère supplémentaire.) Une attaque par dictionnaire est beaucoup plus rapide (même un attaquant avec un seul ordinateur pourrait l'arracher 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 connaître 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 j'ai pu trouver, il n'y a pas d'attaque de pré-image contre SHA-1. (Une attaque en force brute prendrait 2¹⁶⁰ opérations, ce qui signifie que notre attaquant théorique aurait besoin de 10³⁰ des années pour y arriver. Les limites des possibilités théoriques sont d'environ 2⁶⁰ opérations, au cours desquelles l'attaque prendrait quelques années.) Il y a attaques avant imagerie contre des 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, attaque le temps est en baisse de 2¹⁶⁰ opérations à 2¹⁵⁷). Il y a des attaques par collision contre SHA-1 qui sont bien dans les possibilités théoriques ( le meilleur que j'ai trouvé réduit le temps de 2⁸⁰ à 2⁵²), mais ceux-ci sont inutiles contre les hachages de mots de passe, même sans salage.

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

Mise à jour: Marcelo a souligné un article qui mentionne ne seconde attaque de pré-image sur 2¹⁰⁶ opérations . ( Edit: Comme Thomas 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 en quoi cela constitue un danger. pour l’utilisation de SHA-1 en tant que fonction de dérivation de clé. 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?

Thomas Pornin · Accepted Answer

La réponse courte à votre question est la suivante: SHA-1 est aussi sécurisé que possible. MD5 serait bien aussi, même MD4; mais cela pourrait rendre certains investisseurs nerveux. Pour 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 en 160 ou 128 bits (pour réduire les coûts de stockage). Certains des candidats à la deuxième ronde du SHA- semblent être plus rapides que le SHA-1, tout en étant "plus sûrs"; mais ils sont encore un peu nouveaux, donc rester fidèle à SHA-256 ou SHA-512 serait une voie plus sûre en ce moment. Vous auriez l'air professionnel et prudent, ce qui est bien.

Notez que "aussi sûr que vous pouvez obtenir" n’est pas la même chose que "parfaitement en sécurité". 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'affectent pas la résistance à la pré-image. Il a été démontré que MD4 présente quelques faiblesses qui peuvent être exploitées (uniquement théoriquement) lorsque vous essayez de casser HMAC/MD4, mais cela ne s'applique pas à votre problème. Les deux¹⁰⁶ La deuxième attaque de Kesley et Schneier dans l’image pré-image est un compromis générique qui ne s’applique qu’à des entrées très longues (2⁶⁰ octets; c'est un million de téraoctets - remarquez comment 106 + 60 en 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 pouvant être utilisée par l'attaquant. C'est ce que vous avez maintenant même avec les fonctions de hachage "cassées" MD5 et SHA-1.

À propos des tables Rainbow:

"L'attaque arc-en-ciel" est en fait le partage des coûts d'un dictionnaire ou d'une attaque 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 existe une attaque par partage de temps dans laquelle vous calculez à l'avance le [~ # ~] n [~ # ~] mots de passe hachés et les stocker dans une grande table. Si vous triez les sorties de hachage, vous pouvez obtenir votre mot de passe en une seule recherche. A Rainbow table est un moyen astucieux de stocker cette table avec un espace très réduit. Vous ne stockez que N/t les mots de passe hachés, et vous déchiffrez les mots de passe avec O ( t²) les recherches. Les tables arc-en-ciel vous permettent de gérer virtuellement des tables précalculées bien plus grandes que ce que vous pouvez stocker de façon réaliste.

Cependant, qu’il s’agisse de Rainbow ou non, l’attaquant doit encore lancer l’attaque au moins une fois. Ceci peut être vu comme plusieurs couches d'optimisation successives:

L’attaque par force brute/dictionnaire a coûté [~ # ~] n [~ # ~] pour avoir déchiffré chaque mot de passe.
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 coût supplémentaire très faible par mot de passe.
Si la table pré-calculée est une table Rainbow, alors [~ # ~] n [~ # ~] peut être un peu plus grand, car stockage coût est réduit. Le goulot d'étranglement sur [~ # ~] n [~ # ~] devient la puissance du processeur que l'attaquant peut rassembler, et non la taille de ses disques durs.

Si [~ # ~] n [~ # ~] est suffisamment important pour que le coût en CPU du hachage [~ # ~] n [~ # ~] les mots de passe sont ridicules, alors une telle attaque n'est pas réalisable, que les tables Rainbow soient utilisées ou non. Cela signifie qu’une fonction de hachage (résistant à l’image) avec une sortie de 80 bits ou plus est suffisante pour empêcher toute attaque par force brute.

À propos des sels:

Les sels sont un moyen de vaincre les pré-calculs. Dans la description ci-dessus, le sel ramène l'attaquant à l'étape 1: le salage empêche l'attaquant de partager le caractère O ( [~ # ~] n [~ # ~]) entre plusieurs mots de passe attaqués. . Les tables pré-calculées, a fortiori Les tables Rainbow, ne sont plus réalisables.

Vous voulez saler parce que lorsque les données hachées consistent en mots de passe, c'est-à-dire quelque chose qui tient dans le cerveau d'un être humain aléatoire, puis [~ # ~] n [~ # ~] peut être assez faible: les humains sont vraiment difficiles à choisir et à mémoriser les mots de passe. C’est le sens des "attaques par dictionnaire": utiliser un espace réduit de mots de passe potentiels (le "dictionnaire") en supposant que de nombreux mots de passe utilisateur se trouveront 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 Rainbow. Cela suppose que l'attaquant sera capable de casser un mot de passe ou deux; nous ne voulons pas qu’il casse 1000 autres mots de passe avec un minimum de temps système.

En outre, 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 cela pour un seul cœur. MD5 et MD4 sont plus rapides, comptent environ 400 et 250 cycles, respectivement. N'oubliez pas que la plupart des processeurs modernes ont plusieurs cœurs, multipliez-les en conséquence.

Certains schémas de salage prescrivent d’énormes sels; par exemple. Ce qui entre dans la fonction de hachage est en réalité 40000 copies successives d'un seul sel 128 bits, suivi du mot de passe lui-même. Cela rend le hachage de mot de passe plus coûteux (par un facteur 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. Cela est utile pour la connexion à un ordinateur de bureau: l'utilisateur ne remarquera même pas qu'il a fallu 10 ms 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 10000. Sur des serveurs partagés avec des milliers de clients par seconde, le coût total peut devenir prohibitif. Sur le plan conceptuel, élever la barre avec le même facteur pour l'utilisateur légitime et l'attaquant ne constitue pas en définitive une bonne sécurité; mais cela peut être une idée valable dans certaines situations.

À propos des attaques en ligne:

Tout ce qui précède concerne l'élimination des attaques hors ligne. Une attaque hors ligne est une attaque dans laquelle l'attaquant dispose de toutes les données nécessaires 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 dans laquelle chaque attaque de l'attaquant doit passer par un vérificateur honnête (l'attaquant tente simplement de se connecter au système attaqué). Les attaques en ligne sont contrecarrées par la limitation du nombre de mots de passe pouvant être essayés par seconde. Les exemples extrêmes sont les cartes à puce qui se ferment après trois mauvais codes confidentiels.

Habituellement, pour la sécurité des mots de passe, il est beaucoup plus rentable d'arranger le système pour ne pas permettre à un attaquant de mener une attaque hors ligne. C'est ce que font les systèmes Unix: les mots de passe hachés, qui étaient autrefois lisibles pour le monde /etc/password fichier, sont maintenant dans le fichier /etc/shadow fichier protégé contre les accès en lecture, à l’exception de quelques applications privilégiées. L’hypothèse est ici que si l’attaquant sait lire /etc/shadow, alors il a probablement assez de contrôle sur le système pour ne plus avoir besoin de mots de passe ...

jammycakes · Answer

Les réponses précédentes ne font aucune mention des GPU, ce qui peut 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 que plusieurs jours ou semaines, même si les mots de passe ont été salés.

Les algorithmes de hachage de mots de passe modernes tels que bcrypt ou scrypt sont conçus spécifiquement pour être difficiles à exécuter sur les GPU en raison du fait qu'ils sont des chiffreurs de blocs avec des besoins en mémoire beaucoup plus élevés (et l'accès en 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 au fur et à mesure que la technologie progresse.

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

Pour en savoir plus:

Nick Johnson · Answer

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: au minimum, vous devriez effectuer plusieurs itérations (1000 itérations du hachage multiplient par 1 000 le travail de l'attaquant. Cela augmente d'autant votre travail, vous faites beaucoup moins de hachage de mot de passe qu’ils ne le sont).

Idéalement, cependant, vous devriez utiliser une primitive de stockage de mot de passe existante, telle que celles décrites ici .

Erwan Legrand · Answer

SHA1 est un résumé de message , il n'était jamais destiné à être un mot de passe - fonction de hachage (ou dérivation de clé). (Bien qu'il soit possible d'utiliser un bloc de construction pour une 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 Rainbow. Plusieurs algorithmes ont été conçus pour atteindre cet objectif.

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

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

Wikipedia a des pages pour ces fonctions:

Marcelo Cantos · Answer

De graves vulnérabilités ont été découvertes dans SHA-1 qui rendent la recherche beaucoup plus rapide que la force brute. Il reste encore largement insoluble, mais on ne s’attend pas à ce que ce soit le cas plus 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, vers les sorties de secours. Vous ne voyez pas de fumée, mais les alarmes incendie se sont déclenchées."

Ce n'est pas que l'analyse cryptographique actuelle rende SHA-1 dangereux, mais plutôt que la communauté cryptographique s'inquiète du fait que la pire nouvelle pourrait être imminente. 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 en cours de SHA- .

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

Aaron · Answer

En février 2017, SHA-1 ne devrait plus être considéré comme sécurisé. Google a signalé des succès avec 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 d'autres l'ont fait remarquer, les mots de passe ne sont pas vulnérables aux attaques par 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 sur le marché.

VladV · Answer

Si vous stockez le mot de passe salé, SHA-1 convient parfaitement. SHA-2 est considéré comme plus sûr, mais SHA-1 n'est pas un problème, sauf si vous avez une raison d'être vraiment paranoïaque.

Voici ce que le NIST dit :

Les résultats présentés jusqu'ici 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 de fonctions de hachage plus grandes et plus puissantes (SHA-224, SHA-256, SHA-384 et SHA-512) d'ici 2010.