BCrypt est-il un bon algorithme de hachage à utiliser en C #? Où puis-je le trouver?
J'ai lu que lors du hachage d'un mot de passe, de nombreux programmeurs recommandent d'utiliser l'algorithme BCrypt.
Je programme en C # et je me demande si quelqu'un connaît une bonne implémentation de BCrypt? J'ai trouvé cette page , mais je ne sais pas vraiment si c'est faux ou pas.
Que dois-je savoir lors du choix d'un schéma de hachage de mot de passe? BCrypt est-il une "bonne" implémentation?
Tout d'abord, quelques termes qui sont importants:
Hashing - Le fait de prendre une chaîne et de produire une séquence de caractères qui ne peut pas être retournée à la chaîne d'origine.
Cryptage symétriqueHabituellement appelé simplement "cryptage") - Le fait de prendre une chaîne et de produire une séquence de les caractères qui peuvent être déchiffrés dans la chaîne d'origine en utilisant la même clé de chiffrement qui l'a 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 ajoutée à la chaîne d'origine avant qu'elle ne soit hachée.
Pour le .NET Framework, Bcrypt n'a pas encore d'implémentation de référence vérifié. Ceci est important car il n'y a aucun moyen de savoir s'il existe de graves failles dans une implémentation 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 créer votre propre algorithme de chiffrement . Sérieusement.
Si vous allez implémenter votre propre sécurité par mot de passe (soupir), vous devez faire plusieurs choses:
- Utilisez un algorithme de hachage relativement sécurisé .
- Salez chaque mot de passe avant de le hacher.
- Utilisez un sel unique et long pour chaque mot de passe , et stockez 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 toujours trouver les mots de passe, cela lui prendrait très longtemps. C'est votre principal ennemi: Time .
l'algorithme bcrypt fonctionne car il faut cinq ordres de grandeur plus longs pour hacher un mot de passe que MD5 ; (et toujours beaucoup plus long que AES ou SHA-512). Cela oblige le pirate à consacrer beaucoup plus de temps à créer une table Rainbow pour rechercher vos mots de passe, ce qui rend beaucoup moins probable que vos mots de passe risquent d'être piratés.
Si vous salez et hachez vos mots de passe, et que chaque sel est différent, alors un pirate potentiel devrait créer une table Rainbow pour chaque variation de sel , juste pour avoir une table Rainbow pour une salée + mot de passe haché. Cela signifie que si vous avez 1 million d'utilisateurs, un pirate doit générer 1 million de tables Rainbow. Si vous utilisez le même sel pour chaque utilisateur, le pirate n'a qu'à générer 1 table Rainbow pour réussir à pirater votre système.
Si vous ne saluez pas vos mots de passe, tout ce qu'un attaquant a à faire est de récupérer une table Rainbow existante pour chaque implémentation (AES, SHA-512, MD5) et de voir simplement si une correspond au hachage. Ceci a déjà été fait , un attaquant n'a pas besoin de calculer lui-même ces tables Rainbow.
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é par mot de passe n'a pas d'importance. Cela ressemble à une déclaration controversée, mais pensez-y: si je peux obtenir toutes vos informations utilisateur via une attaque par injection SQL, ou je peux demander à vos utilisateurs de me donner leurs cookies via XSS, alors cela n'a pas d'importance la qualité de la sécurité de votre mot de passe .
Autres ressources:
- Jeff Atwood: . NET Encryption Simplified (idéal pour un aperçu du hachage)
- Jeff Atwood: je viens de me connecter en tant que vous
- Jeff Atwood: Vous stockez probablement des mots de passe incorrectement
- Jeff Atwood: hachage rapide
Remarque: Veuillez recommander d'autres bonnes ressources. J'ai dû lire une douzaine d'articles de dizaines d'auteurs, mais peu écrivent aussi clairement sur le sujet que Jeff. Veuillez modifier les articles au fur et à mesure que vous les trouvez.
Vous ne devez pas utiliser BCrypt dans .NET. Vous devez utiliser PBKDF2 tel quel avec l'implémentation du framework .NET intégré. C'est la seule implémentation vérifiée cryptographiquement disponible gratuitement dans .NET en plus d'être algorithme recommandé par le NIST .
StackId utilisait auparavant BCrypt et est passé à PBKDF2 pour cette raison:
Pour les curieux, nous hachons les mots de passe avec PBKDF2. Le code Relavent est ici ( http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135 ), à travers quelques couches d'indirection. Dans une précédente itération, nous utilisions BCrypt; mais déplacé vers PBKDF2 car il est intégré dans le framework .NET, alors que BCrypt nous obligerait à vérifier une implémentation (pas une petite entreprise).
Edit: La signification de vérifié en termes cryptographiques ne semble pas être facilement comprise, une implémentation vérifiée signifie qu'elle a été cryptographiquement avéré être mis en œuvre sans erreur. Le coût peut facilement atteindre 20 000 $ ou plus. Je me souviens de cela lorsque je faisais des recherches sur OpenSSL et lisais où ils ont déclaré qu'ils n'avaient pas terminé le processus de vérification complet, mais si vous avez besoin d'une vérification complète, ils peuvent vous indiquer la bonne voie et mentionner les coûts associés. Certaines exigences gouvernementales incluent 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 chiffrement non vérifiée, vous ne pouvez pas être absolument certain qu'il n'y a pas de défauts malveillants intentionnels, comme autoriser une porte dérobée vers ce qui est chiffré ou des défauts d'implémentation involontaires qui entraînent des données cryptographiques non sécurisées.
Édition 2014: Pour tous ceux qui ont mis en doute l'impératif de l'utilisation d'algorithmes cryptopgraphiques vérifiés, regardez la dévastation causée par le hack heartbleed exploité dans OpenSSL. C'est le coût d'utilisation d'une implémentation non vérifiée. C'est sécurisé .... jusqu'à ce que vous découvriez que n'importe qui peut lire le contenu de la mémoire entière de votre serveur.
L'auteur du changement qui a introduit Heartbleed, Robin Seggelmann, a déclaré qu'il "n'avait pas validé une variable contenant une longueur" et a nié toute intention de soumettre une implémentation imparfaite. Suite à la divulgation de Heartbleed, Seggelmann a suggéré de se concentrer sur le deuxième aspect, déclarant que OpenSSL n'est pas examiné par suffisamment de personnes.
Il s'agit de la définition d'une implémentation non vérifiée. Le moindre petit défaut peut paralyser toute la sécurité.
Édition 2015: Suppression du langage basé sur les recommandations et remplacement par des absolus. Commentaire original de Kevin Montrose intégré pour la postérité.