Meilleure pratique pour hacher les mots de passe - SHA256 ou SHA512?
J'utilise actuellement SHA256 avec un sel pour hacher mes mots de passe. Est-il préférable de continuer à utiliser SHA256 ou dois-je passer à SHA512?
Passer à SHA512 ne rendra pas votre site Web plus sûr. Vous ne devez pas écrire votre propre fonction de hachage de mot de passe. Utilisez plutôt une implémentation existante.
SHA256 et SHA512 sont des résumés de messages , ils n'étaient jamais destinés à être des mots de passe -des fonctions de hachage (ou dérivation de clé). (Bien qu'un résumé de message 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 par dictionnaire et les tables Rainbow. Afin de se défendre contre les attaques par dictionnaire, un schéma de hachage de mot de passe doit inclure un facteur de travail pour le rendre aussi lent que possible.
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 standard 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'un standard n'est pas requis, incluent bcrypt et scrypt.
Wikipedia a des pages pour ces fonctions:
Cela a déjà été répondu assez bien, si vous me demandez: https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512
Jeff a également publié un article intéressant sur le hachage: http://www.codinghorror.com/blog/2012/04/speed-hashing.html
Notez que SHA512 est beaucoup plus lent à calculer que SHA256. Dans le contexte du hachage sécurisé, c'est un atout. Plus le calcul est lent, plus le temps de calcul est long, donc si vous pouvez vous permettre le calcul le coût SHA512 sera plus sûr pour cette raison.
SHA512 peut être significativement plus rapide lorsqu'il est calculé sur la plupart des processeurs 64 bits comme SHA256ses mathématiques 32 bits, une opération qui est souvent légèrement plus lente.
SHA256 est toujours approuvé par le NIST, mais il serait bon de passer à SHA512, ou bcrypt, si vous le pouvez.
La liste des fonctions de hachage approuvées par le NIST, au moment de la rédaction, est la suivante: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256 et SHA3- 224, SHA3-256, SHA3-384 et SHA3-512, SHAKE128 et SHAKE256.
Voir https://csrc.nist.gov/projects/hash-functions
Selon le système d'exploitation que vous utilisez, vous n'avez probablement pas accès aux fonctions de hachage SHA3 ou SHAKE.
Beaucoup de gens préfèrent bcrypt à SHA512, mais bcrypt n'est également disponible que sur certains systèmes d'exploitation.
SHA512 sera disponible sur votre système, ou sinon, vous avez probablement un tel ancien système que le choix de l'algorithme de hachage est le moindre de vos problèmes.
Une des raisons généralement données pour préférer bcrypt est que bcrypt est ajustable - vous pouvez augmenter le nombre de tours (facteur de travail) pour augmenter le temps qu'il faut pour casser les hachages bcrypt.
Mais SHA256 et SHA512 sont également réglables. Alors que la valeur par défaut est de 5000 tours, vous pouvez en spécifier plus si vous le souhaitez. 500000 prend mon ordinateur actuel à environ 0,45 seconde pour calculer, ce qui semble tolérable.
par exemple.:
password required pam_unix.so sha512 shadow rounds=500000 ...
La raison de passer de SHA256 à SHA512 est que SHA256 a besoin de beaucoup plus de tours pour être aussi sûr que SHA512, donc bien qu'il ne soit pas dangereux, il l'est moins.
Voir, par exemple: https://medium.com/@davidtstrauss/stop-using-sha-256-6adbb55c608
Crypto change rapidement, donc toute réponse que vous obtiendrez pourrait se révéler fausse demain, mais l'état actuel de la technique est que même si bcrypt est peut-être meilleur que SHA512, SHA512 va bien.
Si SHA512 est ce que vous avez disponible `` prêt à l'emploi '', utilisez-le (pas SHA256), et ne vous inquiétez pas de bcrypt ou de la famille SHA3 jusqu'à ce qu'ils deviennent standard pour votre distribution.
Soit dit en passant, la réponse actuellement la mieux notée comporte un certain nombre d'allégations qui sont soit fausses, soit trompeuses.
"Passer à SHA512 ne rendra pas votre site Web plus sûr."
C'est trompeur. Le passage à SHA512 rendra votre site légèrement plus sécurisé. SHA256 n'est pas aussi bon que SHA512, mais ce n'est pas terrible non plus. Il n'y a rien de mieux que SHA512 qui soit susceptible d'être disponible sur votre système pour le moment. Bcrypt est peut-être mieux, mais ce n'est pas clair et bcrypt n'est pas disponible sur de nombreux systèmes. La famille SHA3 est probablement meilleure, mais elle n'est pas non plus largement disponible.
"SHA256 et SHA512 n'ont jamais été conçus pour hacher un mot de passe"
C'est faux. SHA256 et SHA512 sont tous deux des algorithmes de hachage NIST approuvés.
"Pour se défendre contre les attaques par dictionnaire, un schéma de hachage de mot de passe doit inclure un facteur de travail pour le rendre aussi lent que possible."
C'est faux. Un facteur de travail élevé protégera contre le craquage de hachage par force brute, mais pas contre une attaque par dictionnaire. Il n'y a pas de facteur de travail suffisamment faible pour être utilisable mais suffisamment élevé pour se protéger contre une attaque par dictionnaire. Si votre mot de passe est un dictionnaire Word, il tombera dans une attaque de dictionnaire. La protection contre une attaque par dictionnaire pour ne pas utiliser de mots de passe que l'on peut trouver dans les dictionnaires.
Sur mon PC actuel, la limite de tours semble être de 10 millions, ce qui produit un retard de 8,74 secondes pour chaque mot de passe entré. C'est assez long pour être extrêmement douloureux, plus long que vous ne voudriez en utiliser. C'est assez long pour empêcher une attaque par force brute - mais un adversaire déterminé avec une bonne plate-forme de craquage et un peu de patience pourrait toujours parcourir un dictionnaire s'il le voulait.
"Une fonction de hachage de mot de passe devrait se défendre contre ... les tables Rainbow"
C'est, au mieux, trompeur. La défense contre les tables Rainbow est de s'assurer que chaque mot de passe a son propre "sel". C'est à peu près la pratique courante de nos jours, et cela se produit avant l'appel de la fonction de hachage. (Le salage signifie l'ajout d'une chaîne aléatoire au mot de passe avant de le hacher. Le sel est stocké avec le mot de passe, ce n'est donc pas un secret, mais cela signifie que même si un utilisateur choisit un mot de passe bien connu, l'attaquant ne peut pas simplement reconnaissent que {ce hachage} appartient à {ce mot de passe}, ils doivent toujours déchiffrer le hachage.)
"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."
Ce n'est pas clair. Toute `` nouvelle '' fonction cryptographique peut être rompue de manière non évidente, c'est pourquoi la plupart des gens préfèrent les fonctions qui ont été largement utilisées. En plus de cela, Argon2 n'est probablement pas à votre disposition.
"D'autres choix, si l'utilisation d'une norme n'est pas requise, incluent bcrypt et scrypt."
Ce n'est pas clair. À un moment donné, scrypt a été considéré comme un meilleur bcrypt. Cependant, pour diverses raisons, le sentiment est passé de scrypt à bcrypt. Voir, par exemple: https://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html
Pour répéter, à ce stade, SHA512 semble être un bon choix, tout comme bcrypt.
SHA512 est approuvé par le NIST et bcrypt ne l'est pas.
SHA512 sera presque certainement disponible sur votre système. Bcrypt peut l'être ou non.
Si les deux sont sur votre système, je recommanderais probablement bcrypt, mais c'est un appel serré. N'importe quel.