Quel algorithme dois-je utiliser pour hacher les mots de passe dans ma base de données? [dupliquer]

https://stackoverflow.com/questions/116684

02-07-2019
|

Question

Cette question a déjà une réponse ici:

hachage de mot de passe sécurisé 9 réponses

Y a-t-il quelque chose disponible qui ne soit pas cassable trivialement?

La solution

Cette réponse de 2008 est maintenant dangereusement obsolète. SHA (toutes les variantes) est maintenant cassable de manière triviale, et la meilleure pratique consiste maintenant (à compter de janvier 2013) à utiliser un hachage à extension de clé (comme PBKDF2) ou idéalement à forte consommation de RAM (comme Bcrypt ) et d’ajouter un sel par utilisateur aussi.

Les points 2, 3 et 4 méritent encore d’être pris en compte.

Consultez le site IT Security SE pour en savoir plus.

Réponse originale de 2008:

Utilisez un algorithme éprouvé. SHA-256 utilise 64 caractères dans la base de données, mais avec un index sur la colonne qui ne pose pas de problème, il s'agit d'un hachage éprouvé et plus fiable que MD5 et SHA-1. Il est également implémenté dans la plupart des langues dans le cadre de la suite de sécurité standard. Cependant, ne vous sentez pas mal si vous utilisez SHA-1.
Ne divisez pas simplement le mot de passe, mais mettez-y d'autres informations. Vous utilisez souvent le hachage de " nom d'utilisateur: mot de passe: salt " ou similaire, plutôt que juste le mot de passe, mais si vous jouez avec cela, vous rendez encore plus difficile le fait de lancer une attaque par dictionnaire.
La sécurité est un domaine difficile, ne pensez pas que vous pouvez inventer vos propres algorithmes et protocoles.
N'écrivez pas de journaux comme "[AddUser]. Hash of GeorgeBush: Rep4Lyfe: ASOIJNTY est xyz"

Autres conseils

La première règle de cryptographie et de stockage du mot de passe est " ne l'inventez pas vous-même ,". mais si vous devez respecter le minimum absolu, vous devez avoir un semblant de sécurité:

Règles cardinales:

Ne stockez jamais un mot de passe en texte brut (vous ne pouvez donc jamais l'afficher ni le transmettre.)
Ne transmettez jamais la représentation stockée d'un mot de passe sur une ligne non sécurisée (texte brut, codé ou haché).
La vitesse est votre ennemie.
Réanalysez régulièrement et améliorez votre processus à mesure que le matériel et la cryptanalyse s'améliorent.
La cryptographie et les processus constituent une très petite partie de la solution.
Les points de défaillance incluent: stockage, client, transmission, traitement, utilisateur, mandats légaux, intrusion et administrateurs.

Étapes:

Appliquez certaines exigences minimales raisonnables en matière de mot de passe.
Modifiez fréquemment les mots de passe.
Utilisez le hachage le plus puissant possible - SHA-256 a été suggéré ici.
Combinez le mot de passe avec un sel fixe (identique pour toute votre base de données).
Combinez le résultat de l'étape précédente avec un sel unique (peut-être le nom d'utilisateur, l'identifiant de l'enregistrement, un guid, un nombre aléatoire long, etc.) qui est stocké et attaché à cet enregistrement.
Exécutez l'algorithme de hachage plusieurs fois - environ 1000 fois . Idéalement, incluez un sel différent à chaque fois avec le hachage précédent. La vitesse est votre ennemi et les itérations multiples la réduisent. De temps en temps, doublez le nombre d'itérations (cela nécessite la capture d'un nouveau hachage - faites-le lors du prochain changement de mot de passe.)

Oh, et si vous utilisez SSL ou une autre sécurité de ligne, n'autorisez pas la transmission de votre mot de passe en texte brut. Et si vous ne faites que comparer le hachage final du client à votre hachage stocké, ne laissez pas cela être transmis en texte brut non plus. Vous devez envoyer un nonce (numéro utilisé une fois) au client et lui demander de le hacher avec son hachage généré (en utilisant les étapes ci-dessus) puis il vous envoie celui-ci. Sur le serveur, vous exécutez le même processus et vous voyez si les deux hashs identiques correspondent. Puis en disposer. Il existe un meilleur moyen, mais c’est le plus simple.

CodingHorror a publié un excellent article sur cette année

http://www.codinghorror.com/blog/archives/000953.html

La recommandation figurant à la fin de l'article est BCrypt

Les algorithmes susmentionnés sont des algorithmes de hachage sécurisés par cryptographie (mais MD5 n'est pas considéré comme sécurisé aujourd'hui).

Cependant, il existe des algorithmes, spécialement créés pour dériver des clés à partir de mots de passe. Ce sont les fonctions de dérivation de clé . Ils sont conçus pour être utilisés avec des chiffrements symétriques, mais ils sont également utiles pour stocker le mot de passe. PBKDF2 utilise par exemple salt, un grand nombre d'itérations et une bonne fonction de hachage. Si vous avez une bibliothèque, quelle qu’elle soit implémentée (par exemple .NET), je pense que vous devriez l’envisager.

Ajoutez un sel unique à la valeur du mot de passe haché (stockez la valeur du sel dans le db). Quand un sel unique est utilisé . L’avantage d’utiliser un algorithme plus sécurisé que SHA1 ou MD5 n’est pas vraiment nécessaire (à ce stade, c’est une amélioration incrémentale, alors que l’utilisation d’un sel est une amélioration monumentale).

Utilisez une fonction de hachage cryptographique forte telle que MD5 ou SHA1, mais veillez à utiliser un bon sel , sinon vous serez exposé aux table arc-en-ciel .

Mise à jour janvier 2013

La réponse initiale date de 2008 et la situation a quelque peu évolué au cours des 5 dernières années. Grâce à la disponibilité du cloud computing et aux puissantes cartes graphiques à processeurs parallèles, les mots de passe comportant jusqu'à 8 ou 9 caractères hachés comme MD5 ou SHA1 sont désormais trivialement cassables.

Maintenant, un long sel est indispensable, tout comme quelque chose de plus dur comme SHA512.

Cependant, toutes les variantes de hachage SHA sont conçues pour le cryptage de communication - les messages échangés dans lesquels chaque message est crypté. Ils sont donc conçus pour être rapides .

Dans le monde du hachage de mots de passe, cette conception est un gros inconvénient, car plus le hash est rapide, plus il génère longtemps, moins il faut de temps pour générer un grand nombre de hachages.

Un hachage rapide comme SHA512 peut être généré des millions, voire des milliards de fois par seconde. Ajoutez un traitement parallèle bon marché et toute permutation possible d'un mot de passe devient un impératif absolu.

L’étirement des touches est un moyen de lutter contre cela. Un algorithme d'étirement de clé (tel que PBKDF2) applique un hachage plus rapide (tel que SHA512) des milliers de fois, ce qui a généralement pour conséquence que la génération de hachage prend environ 1/5 de seconde. Quelqu'un se connectant ne le remarquera pas, mais si vous ne pouvez générer que 5 hachages par seconde, les attaques par force brute sont beaucoup plus difficiles.

Deuxièmement, toujours devrait être un sel aléatoire par utilisateur. Cela peut être généré de manière aléatoire en tant que premiers n octets du hachage (qui sont ensuite supprimés et ajoutés au texte du mot de passe à vérifier avant de générer les hachages à comparer) ou en tant que colonne DB supplémentaire. / p>

Donc:

Quel algorithme dois-je utiliser pour hacher les mots de passe dans ma base de données?

Key-stretching pour ralentir la génération de hachage. J'irais probablement avec PBKDF2.
Le sel par utilisateur désigne une nouvelle attaque par utilisateur, et certains travaux tentent de déterminer comment obtenir le sel.

La puissance de calcul et la disponibilité augmentent de façon exponentielle - il est probable que ces règles changeront à nouveau dans 4 ans. Si vous avez besoin d'une sécurité évolutive, j'étudierais les hachages de style bcrypt / scrypt - ceux-ci prennent les algorithmes plus lents d'étirement de clé et ajoutent une étape qui utilise beaucoup de RAM pour générer le hachage. Utiliser autant de RAM réduit l'efficacité des processeurs parallèles bon marché.

Original septembre 2008 (laissé dans les commentaires ont donc un sens)

Le sel MD5 + ou SHA1 + n'est pas "trivialement cassable" - la plupart des hacks dépendent d'énormes tables arc-en-ciel et celles-ci deviennent moins utiles avec un [update, ils sont maintenant] .

Le sel MD5 + est une option relativement faible, mais il ne sera pas facile de le casser [mise à jour, il est maintenant très facile de le casser] .

SHA2 va jusqu’à 512 - ça va être assez impossible à craquer avec le kit disponible immédiatement [mise à jour, assez facile jusqu’à 9 mots de passe caractères] - même si je suis sûr qu’il existe un Cray dans un bunker militaire quelque part qui peut le faire [Vous pouvez maintenant louer ce 'Cray' d'Amazon]



	
		
	
	
			 MD5 ou SHA en combinaison avec une valeur de sel générée aléatoirement pour chaque entrée 
	


	
		
	
	
			 comme mentionné précédemment, les algorithmes de hachage simples ne doivent pas être utilisés pour cette raison: 

  http://arstechnica.com/security/2012/08/passwords sous l'assaut /  

 utilisez donc quelque chose d'autre, tel que  http: // msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx  
	


	
		
	
	
			 Tous les algorithmes de hachage sont vulnérables à une "attaque par dictionnaire". C’est simplement que l’attaquant dispose d’un très grand dictionnaire de mots de passe possibles, qu’ils hachent tous. Ils voient ensuite si l'un de ces hachages correspond au hachage du mot de passe qu'ils veulent déchiffrer. Cette technique peut facilement tester des millions de mots de passe. C'est pourquoi vous devez éviter tout mot de passe qui pourrait être prévisible à distance. 

 Toutefois, si vous êtes prêt à accepter la menace d’une attaque par dictionnaire, MD5 et SHA1 seraient plus que suffisants. SHA1 est plus sécurisé, mais pour la plupart des applications, cela ne représente pas une amélioration significative. 
	


	
		
	
	
			 Les hachages MD5 / SHA1 sont deux bons choix. MD5 est légèrement plus faible que SHA1.



	
		
			Licencié sous: CC-BY-SA avec attribution
			Non affilié à StackOverflow