Est BCrypt un bon algorithme de hachage à utiliser en C#? Où puis-je le trouver?

J'ai lu que lorsque le hachage d'un mot de passe, de nombreux programmeurs vous recommandons d'utiliser le BCrypt algorithme.

Je suis à la programmation en C# et se demande si quelqu'un connaît une bonne mise en œuvre de BCrypt? J'ai trouvé cette page, mais je ne sais pas vraiment si c'est faux ou pas.

Que dois-je savoir au moment de choisir un hachage de mot de passe système? Est BCrypt une "bonne" mise en œuvre?

InformationsquelleAutor Svish | 2009-01-26
  1. 142

    Tout d'abord, certains termes sont importants:

    Le hachage - L'acte de prendre une chaîne et la production d'une séquence de caractères qui ne peuvent pas être ramenés à la chaîne d'origine.

    Chiffrement Symétrique - (Habituellement dénommé "cryptage") - L'acte de prendre une chaîne et la production d'une séquence de caractères qui peut être déchiffré à la chaîne d'origine grâce à l'utilisation de la même clé de cryptage qui les a chiffrées.

    Table Arc-En-Ciel - une table qui contient toutes les variantes de caractères haché dans un algorithme de hachage.

    Sel - connu chaîne aléatoire ajouté à la chaîne d'origine avant qu'il est haché.

    Pour la .NET Framework, Bcrypt n'avez pas encore de vérifié l'implémentation de référence. Ceci est important car il n'y a aucun moyen de savoir si il y a de graves défauts dans la mise en œuvre existantes. Vous pouvez obtenir une mise en œuvre de BCrypt pour .NET ici. Je ne sais pas assez sur la cryptographie à dire si c'est une bonne ou une mauvaise mise en œuvre. La cryptographie est une grande profondeur de champ. Ne pas essayer de construire votre propre algorithme de chiffrement. Sérieusement.

    Si vous allez mettre en place votre propre mot de passe de sécurité (soupir), alors vous avez besoin de faire plusieurs choses:

    1. Utiliser un relativement algorithme de hachage sécurisé.
    2. De sel de chaque mot de passe avant qu'il soit haché.
    3. Utiliser un unique et long de sel pour chaque mot de passe, et de stocker le sel avec le mot de passe.
    4. Exiger des mots de passe forts.

    Malheureusement, même si vous faites tout cela, un déterminé hacker encore pourrait éventuellement comprendre les mots de passe, il serait juste de lui prendre un temps très long. C'est votre principal ennemi: Temps.

    La bcrypt algorithme fonctionne parce que ça prend du cinq ordres de grandeur plus pour hacher un mot de passe que MD5; (et encore beaucoup plus de temps que AES ou SHA-512). Il force le hacker à passer beaucoup plus de temps pour créer un arc-en-ciel de la table à la recherche de vos mots de passe, ce qui rend beaucoup moins de chances que vos mots de passe seront en danger d'être piraté.

    Si vous êtes le salage et le hachage des mots de passe, et chaque sel est différent, puis un pirate potentiel aurait pour créer un arc-en-ciel de la table pour chaque variation de sel, juste pour avoir un arc-en-ciel de la table pour un salée+mot de passe haché. Cela signifie que si vous avez 1 million d'utilisateurs, un pirate informatique a pour générer 1 million de rainbow tables. Si vous utilisez le même sel pour chaque utilisateur, alors le pirate n'a qu'à générer 1 arc-en-ciel de la table pour réussir à pirater votre système.

    Si vous n'êtes pas saler vos mots de passe, puis tout d'un attaquant n'a plus qu'à tirer une Rainbow table pour chaque mise en œuvre là-bas (AES, SHA-512, MD5) et voir si l'une correspond au hachage. Cette qui a déjà été fait, un attaquant n'a pas besoin de calculer ces tables arc-en-mêmes.

    Même avec tout cela, vous n'avez pas à être l'aide de bonnes pratiques en matière de sécurité. Si ils peuvent utiliser avec succès un autre vecteur d'attaque (XSS, SQL Injection, CSRF, et. al.) sur votre site, bonne sécurité de mot de passe n'a pas d'importance. Qui sonne comme une déclaration controversée, mais pensez-y: Si je peux obtenir toutes vos informations de l'utilisateur grâce à une attaque par injection SQL, ou je peux obtenir vos utilisateurs à me donner leurs témoins par le biais de XSS, ensuite, il n'a pas d'importance comment bon votre mot de passe de sécurité est.

    D'autres ressources:

    1. Jeff Atwood: .NET Simplifié de Chiffrement (idéal pour un aperçu de hachage)
    2. Jeff Atwood: Je viens de connecté en tant que vous
    3. Jeff Atwood: Vous êtes probablement stocker les mots de passe de manière incorrecte
    4. Jeff Atwood: La Vitesse De Hachage

    Remarque: s'il vous Plaît recommander d'autres bonnes ressources. J'ai dû lire une dizaine d'articles par des dizaines d'auteurs, mais quelques écrire aussi clairement sur le sujet que Jeff n'. Veuillez modifier les articles que vous trouvez.

    • peut-être ajouter à votre sel alinéa que le sel doit être choisie au hasard
    • Bon appel, a ajouté. Bien que ce n'est pas si important que cela. Vous pouvez simplement utiliser le timestamp de la connexion pour le sel. La différence qu'il fait, c'est que l'attaquant est alors nécessaire de recalculer l'arc-en-ciel de la table pour chaque sel. C'est ce qui rend difficile, pour ne pas qu'il est choisi au hasard. Rendant aléatoire voudrais ajouter une autre couche de obsfucation, mais c'est inutile une fois que l'attaquant est en mesure de voir votre base de données (qui est le problème qui cause l'ensemble de notre chagrin dans le premier lieu).
    • Pas vraiment, le sel n'a pas à être un secret, le juste unique pour chaque instance. Depuis unique (comme dans le monde entier) n'est pas possible, le hasard est la meilleure chose suivante. Aussi, timestamp n'est pas un bon sel comme il n'y a pas assez d'entropie.
    • Je prendrais le problème avec votre déclaration "Si l'on peut utiliser avec succès les XSS, SQL injection, une bonne sécurité de mot de passe n'a pas d'importance." Au contraire, si elles peuvent XSS ou SQL injecter votre site, bon mot de passe de sécurité est encore plus important. La clé ici est la "défense en profondeur" -- vous devriez renforcer la sécurité dans la mesure du possible au niveau de chaque couche de votre application.
    • Absolument, mon point était perdu: Vous ne pouvez pas juste dire, 'Hey, nous hachage et le sel de nos mots de passe, "nous sommes ok"!'
    • Un point très important à faire au sujet de BCrypt. Ce n'est pas seulement lent, c'est configurably, de façon exponentielle lent. Il a été spécialement conçu pour maintenir en place avec la loi de Moore. SHA/AES sont en fait conçu pour être rapide tout en restant sécurisé, car le plaintexts sont pensés pour avoir de haute entropie. BCrypt est forte est hachage de mot de passe car il peut utiliser la complexité algorithmique comme un substitut pour une faible entrée de l'entropie.

    InformationsquelleAutor George Stocker
  2. 71

    Vous ne devez pas utiliser BCrypt dans .NET. Vous devez utiliser PBKDF2 comme avec les construit dans .NET cadre de la mise en œuvre. C'est le seul disponible gratuitement cryptographiquement vérifié dans la mise en œuvre .NET est le algorithme recommandé par le NIST.

    StackId précédemment utilisé BCrypt et a déménagé à PBKDF2 pour cette raison même:

    Pour les curieux, nous sommes hachage des mots de passe avec PBKDF2. Relavent code
    est ici (
    http://code.google.com/p/stackid/source/browse/OpenIdProvider/Current.cs#1135
    ), par le biais de quelques couches d'indirection. Dans l'itération précédente, nous
    ont été à l'aide de BCrypt; mais a déménagé à PBKDF2 comme elle est intégrée à l' .NET
    cadre, alors que BCrypt nous obligerait à vérifier la mise en œuvre
    (pas une petite entreprise).

    Kevin Montrose, Le 27 Mai 2011

    (Lien mis à jour sur GitHub)

    Edit: Le sens de vérifié en termes de chiffrement semble ne pas être facilement compris, a vérifié la mise en œuvre signifie qu'il est cryptographiquement avéré être mises en œuvre sans erreur. Le coût de ce qui peut facilement atteindre 20 000 $ou plus. Je me souviens quand je faisais des recherches sur OpenSSL et de lire, où ils ont déclaré qu'ils n'ont pas terminé l'ensemble du processus de vérification, mais si vous avez besoin d'pleinement vérifié qu'ils peut vous diriger dans la bonne voie pour elle et a mentionné les coûts associés. Certaines exigences du gouvernement d'inclure des mandats pour vérifié les algorithmes de chiffrement.

    La bcrypt implémentations .NET n'ont pas été vérifiées. À l'aide d'un non vérifiées cryptage de mise en œuvre, vous ne pouvez pas être absolument certain qu'il n'y a pas intentionnels défauts, comme permettant une porte dérobée dans ce qui est crypté ou non de la mise en œuvre les défauts qui résultent en cryptographique non sécurisé.

    2014 edit: 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 d'utilisation d'un non vérifié la mise en œuvre. C'est sûr.... jusqu'à ce que vous découvrez que toute personne peut tout simplement lire l'ensemble du contenu de la mémoire de votre serveur.

    L'auteur de la modification qui a introduit Heartbleed, Robin Seggelmann, a déclaré qu'il a "manqué de la validation d'une variable contenant une longueur" et a nié toute intention de soumettre une mauvaise mise en œuvre. Suite à Heartbleed de communication de l'information, Seggelmann a suggéré de se concentrer sur le second aspect, indiquant que OpenSSL n'est pas examiné par un nombre suffisant de personnes.

    C'est la définition d'un non vérifié la mise en œuvre. Même le plus petit défaut peut entraîner paralysant toute sécurité.

    2015 edit: Retiré des recommandations en fonction de la langue et remplacés par des absolus. Intégré d'origine Kevin Montrose commentaire pour la postérité.

    • Pour citer le commentaire connexe: "[nous] avons déménagé à PBKDF2 comme elle est intégrée à l' .NET framework, alors que BCrypt nous obligerait à vérifier la mise en œuvre". Notez que le commentaire ne dit pas le algorithme est mieux, juste que SE de l'Équipe de développement estime le haut-PBKDF2 mise plus de confiance que d'une bibliothèque externe (qui est, en fin de compte, un jugement d'appel).
    • J'ai mis à jour ma réponse. Ce n'est pas ce qui est à l', DONC l'équipe estime sûr, mais un jugement d'appel entre intrinsèquement prouvé sécurisé ou je l'espère sécurisé. Le dernier quand il s'agit de la cryptographie est inacceptable.
    • J'ajouterais à ce que le but de BCrypt/SCrypt au-dessus et au-delà de la clé de l'étirement (qui PBKDF2-t-fine) est aussi de forcer l'utilisation d'une quantité importante de mémoire, ce qui réduit la quantité de tentatives que le même matériel peut faire en parallèle. Tout c'est très bien pour vraiment sécuriser les mots de passe, il pourrait aussi avoir des problèmes de performances dans un environnement partagé, où les utilisateurs se connectent simultanément. Il y a toute une couche de tests de performance requis pour un BCrypt en œuvre au cours de PBKDF2.
    • BCrypt ne nécessite que très peu de mémoire. Seulement SCrypt nécessite des quantités importantes.
    • Juste pour le rendre plus clair, la vérification peut signifier soit le algorithme (BCrypt) est vérifiée, ou de ses mise (.NET code) est vérifiée. La mise en œuvre peut être testé facilement, il suffit de comparer le résultat avec d'autres implémentations, si le résultat est le même, et donc de les corriger, alors pas de porte dérobée peut être caché à l'intérieur. La sécurité cryptographique vient de l'algorithme, et non à partir de la mise en œuvre, tant et aussi longtemps qu'une bibliothèque renvoie le bon de hachage de la valeur, vous pouvez l'utiliser en toute sécurité. Un point à prendre soin de est que, quand la bibliothèque a également crée un unique sel lui-même.
    • la question est à propos de la vérification de la mise en œuvre ET de l'algorithme. Juste parce que vous pouvez d'entrée x obtenir y à 2 implémentations doens pas dire que impl2 n'est pas une fuite de l'information qui compromet totalement de sécurité. Un non vérifié la mise en œuvre pourrait littéralement faire WebRequest.Send(salt, key, text); return verifiedImplementation(salt, key, text)
    • Je me demande comment DONC migré tous les bcrypt des mots de passe hachés à la nouvelle hachages? Wouldnt ils ont besoin de la crue des mots de passe de hachage à l'aide d'un nouvel algorithme?
    • Une façon dont je l'ai fait dans le passé, c'est quand les gens se connectent, leur demander de réinitialiser leur mot de passe, enregistrer le nouveau mot de passe dans le nouvel algorithme de hachage.
    • Je ne pense même pas que vous avez à leur demander de réinitialiser leur mot de passe. Sur la prochaine connexion (où ils alimentent leur mot de passe en clair), vous pouvez le faire je crois.
    • ajout d'informations en citant la récente heartbleed hack. La vérification n'est pas une "décision", soit elle est sécurisée ou pas, par définition.
    • si vous croyez vraiment que l'on peut procéder à une vérification puis être sûr à 100% que c'est sécurisé?
    • ce n'est pas de vérification de l'assure. Vérification permet de s'assurer qu'il n'y a pas de mathématique / cryptographiques majeures de la faute dans la mise en œuvre de l'algorithme de ses spécifications. De nombreux vérifié les implémentations ne sont d'aucune utilité maintenant que l'ensemble de l'algorithme a été invalidé en début de SHA-# et algorithmes MD5 sur le dessus de ma tête. C'est exactement le cœur saigner du problème, ce n'est pas que le protocole SSL est précaire (bien que plusieurs saveurs sont) c'était une erreur dans la mise en œuvre qui ont vaincu l'ensemble de la sécurité dans un spectaculaire horrible façon de l'exposer directement les lectures de mémoire pour serveurs connectés à l'internet.
    • C'est pas bons conseils et je suis surpris qu'il a beaucoup de upvotes. La vérification d'un BCrypt mise en œuvre dans un langage managé est beaucoup, beaucoup plus banal que d'en vérifier quelque chose comme un ensemble de SSL de mise en œuvre de C. Heartbleed est complètement hors de propos; vous seriez mieux de mentionner quelque chose comme type PHP le fait de contraindre des problèmes avec pommes de contrôles d'égalité. Ainsi, alors largement adapté dans un sens pratique, PBKDF2 est un KDF, pas un mot de passe algorithme de hachage, alors que BCrypt est mieux adapté. Peu importe, il serait beaucoup plus logique d'utiliser Argon2 ces jours de toute façon, pour ce qui est une bien testé C# bibliothèque
    • vous suggérons de lire ce fil de discussion avant de décider ce qui est un bon algorithme de hachage à utiliser. en c#, security.stackexchange.com/questions/35250/...
    • Voir aussi owasp.org/index.php/Using_Rfc2898DeriveBytes_for_PBKDF2
    • Quelles sont les preuves que Rfc2898DeriveBytes a été cryptographiquement vérifié sur toutes les plateformes prises en charge? Si je comprends bien, tous les certifiés FIPS algorithmes' les noms se terminent par "CryptoServiceProvider" ou "Gnc", ce qui ne l'est pas. Mais alors, ce n'est pas une fonction de hachage, mais un générateur pseudo que utilise une fonction de hachage, alors peut-être il n'est pas nécessaire, mais ensuite on en revient à la question de savoir, comment pouvons-nous dire si c'est vérifié?
    • la publication par le NIST en est la preuve. Il est inclus dans la deuxième phrase.
    • Le lien est cassé, mais j'ai trouvé le document. Malheureusement il ne parle que de la les algorithmes; il ne dit rien sur le C# ou le .NET Framework implémentations de ces algorithmes, qui a été ma préoccupation. La demande implicite par Kevin Montrose - et - que je suis en train de valider, c'est que l' .NET à leur mise en œuvre ont été vérifiées.
    • cela semble être la meilleure preuve support.microsoft.com/en-us/help/811833/...
    • Mm, oui. Je souhaite que MS aurait explicitement dire si leurs Rfc2898DeriveBytes est certifié. Il ne mentionne explicitement que "Les noms de ces classes de fin dans "CryptoServiceProvider" ou "Gnc."" (ce qui implique qu'elle n'est pas certifiée), mais je suppose qu'il doit au moins fournir un moyen par lequel vous pouvez vérifier pour vous, qui est, définissez l'option de système d'exploitation pour autoriser uniquement certifiés FIPS algorithmes et puis essayez d'exécuter un programme qui utilise PBKDF2 et le hasher de votre choix.

    InformationsquelleAutor Chris Marisic