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


148

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 15 * 60 * 60 * 24/1000 ~ = 10 17 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 160 opérations, ce qui signifie que notre attaquant théorique aurait besoin de 10 à 30 ans pour la réaliser. Les limites de la possibilité théorique sont d'environ 2 60 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 2160 opérations à 2157). 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 80 à 2 52 ), 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 106 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?


Il a maintenant 7 ans et beaucoup de choses se sont passées depuis sa dernière édition. SHA-1 n'est plus considéré comme suffisamment sécurisé pour le hachage de mot de passe
GordonM

@GordonM que s'est-il passé? Avec la croissance de la puissance de calcul, les attaques par collision SHA-1 deviennent de plus en plus pratiques mais elles ne sont pas vraiment pertinentes ici. SHA-1 n'a jamais été vraiment sécurisé pour le hachage de mot de passe (les hachages rapides ne le sont généralement pas), mais dans la mesure où c'était le cas, c'est toujours AFAIK.
Tgr

SHA-1 n'a jamais été sécurisé pour le hachage de mot de passe car il n'avait jamais eu l'intention de sécuriser les mots de passe en premier lieu ...
Azxdreuwa

Réponses:


209

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 106 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 60 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 n 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 2 ) 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 ...


5
Excellente réponse. Le seul point avec lequel je ne suis pas d'accord est "Conceptuellement, relever la barre du même facteur pour l'utilisateur légitime et l'attaquant n'est pas une bonne sécurité en fin de compte" - l'attaquant doit effectuer un grand nombre d'opérations qu'un utilisateur doit effectuer. L'ajout d'un cycle d'horloge pour une connexion utilisateur ajoute des millions pour un attaquant.
Nick Johnson

1
@Thomas Cela reste exact et le restera probablement dans un avenir prévisible indéfini. Les pirates peuvent deviner les mots de passe réels grâce à n'importe quel type de hachage en raison de la mauvaise qualité des mots de passe courants. Devinez "123456" et vous obtiendrez toujours quelques résultats. Cela restera vrai quel que soit le stockage de mot de passe que vous utilisez.
tylerl

1
Juste mon point de vue, mais pourquoi resteriez-vous avec SHA1, alors qu'un cryptage de mot de passe plus fort est déjà largement disponible? Il y a un an, MD5 était considéré comme "sécurisé", et maintenant ce n'est plus le cas - la même chose pourrait arriver à SHA1 n'importe quand, pour autant que nous en sachions. Personnellement, je vais parier sur Blowfish à partir de maintenant - il semble avoir un meilleur représentant et moins d'experts concernés dans la crypto-communauté, il est disponible presque partout, il n'y a donc aucune raison de jouer avec SHA1.
mindplay.dk

1
Je suis profondément choqué de m'égarer sur une réponse de @ThomasPornin disant que MD5 est sécurisé pour le stockage des mots de passe. Si MD5 va bien, pourquoi TOUT dit de ne pas l'utiliser, utilisez bcrypt ?? Sont-ils trop prudents? J'ai tout lu et tout compris et j'avais l'impression que MD5 était très mauvais parce que vulnérable à la force brute. Commentaires comme récemment il y a un an ne contredisent pas la réponse ...
temporary_user_name

1
@Aerovistae: vous voudrez peut-être jeter un œil à cette réponse sur le site security.SE; il contient plus d'analyses et des détails récents sur le hachage de mot de passe.
Thomas Pornin

30

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:


2
"Les algorithmes modernes de hachage de mot de passe tels que bcrypt ou PBKDF2 sont conçus spécifiquement pour être difficiles à exécuter sur les GPU" - vouliez-vous dire "bcrypt ou scrypt"? PBKDF2 est juste un hachage itéré, il n'y a rien dedans qui serait problématique pour un GPU.
Tgr

4
S'il vous plaît laissez-moi savoir quel GPU vous utilisez, je vais acheter le même. Si vous pouvez faire 2 ^ 160 calculs SHA-1 en "minutes" (ce serait moins de "heures", donc au plus 59 minutes), vous devez être capable d'effectuer plus de 10 ^ 44 par seconde. Étant donné que les transferts PCIe plafonnent à environ 128 GT / s, votre GPU doit également disposer d'une mémoire intégrée impressionnante. Je le veux.
Damon

3
@Damon: Vous semblez supposer que les utilisateurs ont des mots de passe "triviaux" (<8 bits d'entropie) ou des mots de passe "incassables" (> 60 bits d'entropie). Vous ignorez complètement tous ceux dont l'entropie de mot de passe est comprise entre 10 et 60 bits. Ce sont les utilisateurs où bcrypt, les tables arc-en-ciel et les GPU, et ils représentent généralement environ 80% d'une base d'utilisateurs typique.
jammycakes

1
(oups ... j'aurais dû dire: "Ce sont les utilisateurs où bcrypt, les tables arc-en-ciel et les GPU font la plus grande différence")
jammycakes

3
Pour quelques statistiques et analyses, voir troyhunt.com/2011/06/brief-sony-password-analysis.html - alors que 36% des utilisateurs choisissent des mots de passe qui apparaissent dans les dictionnaires de mots de passe, seuls 2-3% choisissent les plus courants.
jammycakes

7

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 .


Itérer des milliers de fois n'est pas une aussi bonne idée qu'on pourrait le penser. Cela augmente le risque de collision de hachage. yorickpeterse.com/articles/use-bcrypt-fool
jammycakes

1
Cet article semble complètement confus. Une fonction de hachage sécurisée ne perd pas d'entropie appréciable grâce au hachage itératif, et le hachage itératif est un composant essentiel des schémas d'étirement clés tels que PBKDF2 et scrypt. Même bcrypt, que l'auteur recommande, utilise une construction similaire. Son `` attaque '' repose sur la recherche d'une pré-image d'un hachage - auquel cas, la plupart des constructions utilisant ce hachage sont de toute façon complètement cassées. Enfin, je ne recommande pas aux gens d'utiliser directement le hachage itératif - comme je le dis dans ma question, vous devriez utiliser une primitive existante conçue à cet effet.
Nick Johnson

7

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:


4

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.


Pouvez-vous fournir un lien? Comme je l'ai dit, la meilleure attaque de pré-image que j'ai pu trouver rend la recherche 8 fois plus rapide, et même pour que cela fonctionne, vous devez omettre la moitié des étapes de SHA-1. (De plus, je pense que c'est une deuxième attaque de pré-image, qui est inutile contre les hachages de mot de passe.)
Tgr

Je suis également sceptique quant à quelque chose qui vient de la NSA, à la lumière des nouvelles récentes :)
Alex W

4

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.


OK, trouver une collision SHA-1 a pris environ 6500 années CPU et 100 années GPU , ce n'est pas une attaque de production. Cracker un mot de passe n'est pas une force brute contre toutes les entrées possibles mais contre des listes de 10 000 000 mots de passe fréquents. Voici le papier .
zaph

1
La faille utilise uniquement une fonction de hachage pour protéger les mots de passe. Le simple fait d'utiliser une fonction de hachage n'est pas suffisant et le simple fait d'ajouter un sel n'améliore pas la sécurité, les hachages cryptographiques sont très rapides. Au lieu de cela, parcourez un HMAC avec un sel aléatoire pendant environ 100 ms et enregistrez le sel avec le hachage. Utiliser des fonctions telles que PBKDF2(aka Rfc2898DeriveBytes), password_hash/ password_verify, Bcryptet des fonctions similaires. Le but est de faire en sorte que l'attaquant passe beaucoup de temps à trouver des mots de passe par force brute. La protection de vos utilisateurs est importante, veuillez utiliser des méthodes de mot de passe sécurisées.
zaph le

La collision n'est pas une pré-image et les mots de passe ne sont pas des signatures. Les attaques par collision ne fonctionnent pas avec les mots de passe car elles nécessitent la connaissance du texte brut d'origine.
Tgr

Tgr: d'accord, merci. Zaph: Oui, le salage pour se protéger contre les attaques arc-en-ciel et l'utilisation de hachages cryptographiques lents font partie des pratiques recommandées que je n'ai pas spécifiquement abordées dans cette réponse.
Aaron

3

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.


C'est un commentaire du NIST de 2004. Leur projet de recommandation de 2010 indique que SHA-1 est approuvé pour toutes les applications de génération de signature non numérique au-delà de 2010.
Tgr
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.