BCrypt est-il un bon algorithme de hachage à utiliser dans C#? Où puis-je le trouver? [fermé]
j'ai lu que lors du hachage d'un mot de passe, de nombreux programmeurs recommandent d'utiliser l'algorithme BCrypt.
je suis en programmation en C# et je me demande si quelqu'un connaît une bonne implémentation pour BCrypt? J'ai trouvé cette page , mais je ne sais pas vraiment si c'est faux ou pas.
Que dois-je savoir lorsque je choisis un système de hachage de mot de passe? BCrypt est-il une "bonne" mise en œuvre?
2 réponses
D'abord, certains termes qui sont importants:
Hashing - acte consistant à prendre une chaîne de caractères et à produire une séquence de caractères qui ne peut pas être retournée à la chaîne originale.
Chiffrement Symétrique - (Habituellement dénommé "cryptage") - L'acte de prendre une chaîne et la production d'une séquence de caractères peut être déchiffré à la chaîne d'origine grâce à l'utilisation de la même clé de chiffrement chiffrée.
"Rainbow Table - une table de recherche qui contient toutes les variations de caractères hachés dans un algorithme de hachage spécifique.
Salt - une chaîne aléatoire connue annexée à la chaîne originale avant qu'elle ne soit hachée.
pour le .net Framework, Bcrypt ne dispose pas encore d'une implémentation de référence vérifiée . C'est important parce qu'il n'y a aucun moyen de savoir s'il y a de graves lacunes dans une mise en œuvre existante. Vous pouvez obtenir une implémentation de BCrypt pour .NET ici . Je ne connais pas assez la cryptographie pour dire si c'est une bonne ou une mauvaise implémentation. La cryptographie est un domaine très profond. N'essayez pas de construire votre propre algorithme de chiffrement . Sérieusement.
si vous voulez implémenter votre propre sécurité de mot de passe (sigh), alors vous devez faire plusieurs choses:
- utilisez un algorithme de hachage relativement sûr .
- salez chaque mot de passe avant qu'il ne soit hashé.
- utilisez un sel unique et long pour chaque mot de passe , et stocker le sel avec le mot de passe.
- nécessite des mots de passe forts .
malheureusement, même si vous faites tout cela, un pirate déterminé pourrait encore potentiellement comprendre les mots de passe, il lui faudrait juste un temps vraiment long. C'est votre ennemi principal: Time .
l'algorithme de bcrypt fonctionne parce qu'il faut cinq ordres de grandeur plus longtemps pour hacher un mot de passe que MD5 ; (et encore beaucoup plus longue que AES ou SHA-512). Il force le hacker à passer beaucoup plus de temps à créer une table arc-en-ciel pour chercher vos mots de passe, ce qui rend beaucoup moins probable que vos mots de passe seront en danger d'être piraté.
si vous salez et hashez vos mots de passe, et chaque sel est différent, alors un pirate potentiel devrait créer une table arc-en-ciel pour chaque variation de sel , juste pour avoir une table arc-en-ciel pour un salé+hashé le mot de passe. Cela signifie que si vous avez 1 million d'utilisateurs, un hacker doit générer 1 million de tables arc-en-ciel. Si vous utilisez le même sel pour chaque utilisateur, alors le hacker n'a qu'à générer 1 table arc-en-ciel pour hacker avec succès votre système.
si vous ne salez pas vos mots de passe, alors tout ce qu'un attaquant doit faire est de tirer vers le haut d'une table existante arc-en-ciel pour chaque implémentation là-bas (AES, SHA-512, MD5) et juste voir si un correspond au hachage. Ce a déjà fait , un attaquant n'a pas besoin de calculer ces tables arc-en-ciel eux-mêmes .
même avec tout cela, vous devez utiliser de bonnes pratiques de sécurité . S'ils peuvent utiliser avec succès un autre vecteur d'attaque (XSS, SQL Injection, CSRF, et. Al. ) sur votre site, une bonne sécurité de mot de passe n'a pas d'importance. Cela ressemble à une déclaration controversée, mais pensez-y: si je peux obtenir tout vos informations d'utilisateur par une attaque D'injection SQL, ou je peux obtenir vos utilisateurs pour me donner leurs cookies par XSS, alors il n'a pas d'importance de la façon dont la sécurité de votre mot de passe est .
autres ressources:
- Jeff Atwood: ."
- Jeff Atwood: je viens de me connecter en tant que vous
- Jeff Atwood: vous stockez probablement les mots de passe incorrectement
- Jeff Atwood: Vitesse De Hachage
Note: veuillez recommander d'autres bonnes ressources. J'ai dû lire une douzaine d'articles par des dizaines d'auteurs, mais peu écrivent aussi clairement sur le sujet que Jeff. Veuillez modifier les articles que vous trouvez.
You must not use BCrypt in .NET. Vous doit utiliser PBKDF2 comme c'est le cas avec L'implémentation.NET framework. Il s'agit de la seule implémentation cryptographique disponible librement et vérifiée dans .NET avec l'algorithme recommandé par le NIST .
StackId utilisé précédemment BCrypt et déplacé à PBKDF2 pour cette même raison:
pour les curieux, nous hachons les mots de passe avec PBKDF2. Code Relavent est ici ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), à travers quelques couches d'actions indirectes. Dans une itération antérieure, nous ont utilisé BCrypt; mais déplacé à PBKDF2 comme il est construit dans le. bcrypt nous demanderait de vérifier une implémentation (pas de petite entreprise).
Edit: le sens de vérifié en termes cryptographiques ne semble pas être facilement compris, une implémentation vérifiée signifie qu'elle a été mise en œuvre cryptographiquement prouvée sans erreur. Le coût peut facilement atteindre 20 000 $ ou plus. Je me souviens de cela quand je faisais des recherches sur OpenSSL et lire où ils ont déclaré n'ont pas terminé le processus de vérification complète, mais si vous avez besoin entièrement vérifié qu'ils peuvent vous indiquer la bonne voie pour elle et les coûts mentionnés associés. Certaines exigences gouvernementales comprennent des mandats pour des algorithmes de chiffrement vérifiés.
les implémentations de bcrypt dans .NET n'ont pas été vérifiées. En utilisant une implémentation de cryptage non vérifiée, vous ne pouvez pas être absolument certain qu'il n'y a pas non plus de défauts intentionnels malveillants, comme autoriser un backdoor dans ce qui est crypté ou défauts involontaires de mise en œuvre qui se traduisent par des données cryptographiques insécurité.
édition 2014: Pour quelqu'un qui a mis en question l'impératif de l'aide vérifié cryptopgraphical algorithims regarder la dévastation qui a été forgé par le heartbleed hack exploités dans OpenSSL. C'est le coût de l'utilisation d'une implémentation non vérifiée. Il est sécurisé.... jusqu'à ce que tu découvres qu'une personne il suffit de lire l'intégralité du contenu mémoire de votre serveur.
L'auteur du changement qui a introduit Heartbleed, Robin Seggelmann, a déclaré qu'il" manquait la validation d'une variable contenant une longueur " et a nié toute intention de soumettre une implémentation défectueuse. À la suite de la divulgation de Heartbleed, Seggelmann a suggéré de se concentrer sur le second aspect, déclarant Qu'OpenSSL n'est pas évalué par suffisamment de personnes.
C'est le définition d'une mise en œuvre non vérifiée. Même le moindre défaut peut paralyser toute la sécurité.
2015 modifier: supprimer le langage fondé sur la recommandation et remplacé par absolues. Commentaire original de Kevin Montrose intégré pour la postérité.