La meilleure façon de stocker le mot de passe dans la base de données

Je suis en train de travailler sur un projet qui a pour avoir une authentification (nom d'utilisateur et mot de passe)

Il se connecte également à une base de données, alors j'ai pensé que je voudrais stocker le nom d'utilisateur et mot de passe. Cependant, il semble que pas une bonne idée d'avoir des mots de passe comme un simple champ de texte dans une table, assis sur la base de données.

Je suis à l'aide de C# et de le connecter à un server 2008 express. Quelqu'un peut-il suggérer (avec le plus d'exemples possibles) quelle est la meilleure façon de stocker les données de ce type serait?

P. S je suis ouvert à l'idée que cette info ne pas être stockées dans la base de données si une bonne raison peut être fourni

  • Quoi que vous fassiez, si vous allez avec le cryptage, ne pas stocker la clé dans le code précédent affiche mentionné. C'est juste une mauvaise pratique.
  • Comment faire des mots de passe droit? " est une question vitale. C'est un problème difficile et les erreurs ont des conséquences graves (rappel de ce qui s'est passé à Tesco et LinkedIn). Je pense que cette question devrait être ré-ouvert en programmers.stackexchange.com
  • Il est préférable de s'en tenir à des normes - voir en.wikipedia.org/wiki/PBKDF2 Vous n'avez qu'à trouver une application dans votre langue
  • Cette question est largement répondu dans le forum sur la sécurité: security.stackexchange.com/questions/211/...
InformationsquelleAutor Crash893 | 2009-06-28
  1. 393

    Il est exact que de stocker le mot de passe dans un simple champ de texte est un horrible idée. Cependant, aussi loin que l'endroit va, pour la plupart des cas, vous allez rencontrer (et honnêtement, je ne peux penser à aucune des contre-exemples) le stockage de l' représentation d'un mot de passe dans la base de données est la bonne chose à faire. Par la représentation, je veux dire que vous voulez hash le mot de passe à l'aide d'un sel (qui doit être différent pour chaque utilisateur) et une sécurité 1-algorithme et de stocker que, de jeter le mot de passe d'origine. Ensuite, lorsque vous voulez vérifier un mot de passe, vous hachage de la valeur (en utilisant le même algorithme de hachage et de sel) et de la comparer à la valeur hachée dans la base de données.

    Ainsi, alors que c'est une bonne chose que vous pensez à ce sujet et c'est une bonne question, c'est en fait un double de ces questions (au moins):

    De clarifier un peu plus loin sur le saler peu, le danger avec simplement le hachage d'un mot de passe et le stockage, c'est que si un intrus obtient une emprise de votre base de données, ils peuvent toujours utiliser ce qui est connu comme rainbow tables pour être en mesure de "décrypter" le mot de passe (au moins ceux que l'on peut voir dans l'arc-en-ciel de la table). Pour contourner ce problème, les développeurs d'ajouter un sel de mots de passe qui, lorsqu'il est fait correctement, rend arc-en-ciel attaques tout simplement impossible à faire. Notez qu'une idée fausse commune est de simplement ajouter le même et unique long de la chaîne de tous les mots de passe; si ce n'est pas horrible, il est préférable d'ajouter unique de sels de chaque mot de passe. Lisez ceci pour en savoir plus.

    • Bergantino: "stocker le mot de passe dans la base de données est la bonne chose à faire" - je ne serais pas d'accord avec cette déclaration.
    • Je voulais stocker le mot de passe dans la base de données plutôt que de les stocker ailleurs. En prenant cette phrase hors de son contexte permet de croire que je suis prend en charge le stockage de la plaine des mots de passe, si vous lisez le reste je n'ai évidemment pas.
    • Bergantino: j'ai compris ce que tu voulais dire à la perfection. Et je n'ai pas le sortir de son contexte. La meilleure pratique est de ne pas stocker le ecnrypted mot de passe, mais pour stocker un salée hachage du mot de passe crypté.
    • Non seulement est-ce que j'ai dit, je l'ai dirigé à une pléthore de posts qui traitent de sels et autres...
    • Bergantino: vous assurer qu'il n'y est pas une faute de frappe dans votre post? Il dit: "Pour la plupart des cas, vous allez rencontrer (et honnêtement, je ne peux penser à aucune des contre-exemples) de stocker le mot de passe dans la base de données est la bonne chose à faire." ??? Il semble contrdict vos commentaires
    • Ce que Paolo a dit directement contredit lui-même. Un salée de hachage d'un mot de passe n'est pas un mot de passe. Le stockage d'un salée hachage du mot de passe dans la base de données n'est pas stocker le mot de passe dans la base de données. Le corps de la réponse est tout à fait approprié, mais sa première phrase est extrêmement trompeur.
    • C'est rapprochait dangereusement d'une querelle sémantique de jeu, mais je vais le corriger néanmoins...
    • owasp.org/index.php/Password_Storage_Cheat_Sheet c'est une bonne référence sur le hachage/salage.

    InformationsquelleAutor Paolo Bergantino
  2. 52

    Fond
    Vous n'avez jamais ... vraiment ... besoin de connaître le mot de passe utilisateur. Vous voulez juste pour vérifier l'arrivée d'un utilisateur connaît le mot de passe pour un compte.

    De Hachage Elle:
    Stocker des mots de passe hachés (chiffrement à sens unique) sur une fonction de hachage.
    Une recherche pour "c# chiffrer les mots de passe" donne une charge d'exemples.

    Voir le en ligne de hachage SHA1 créateur pour avoir une idée de ce qu'est une fonction de hachage produit (Mais ne pas utiliser SHA1 une fonction de hachage, utiliser quelque chose de plus fort comme SHA256).

    Maintenant, un hachage de mots de passe signifie que vous (et de la base de données des voleurs) ne devrait pas être en mesure d'inverser que de hachage de retour dans le mot de passe d'origine.

    Comment l'utiliser:
    Mais, dites-vous, comment puis-je utiliser cette purée jusqu'mot de passe stocké dans la base de données?

    Lorsque l'utilisateur se connecte, ils vont vous remettre le nom d'utilisateur et le mot de passe (dans le texte original)
    Il vous suffit d'utiliser le même code de hachage de hachage tapé un mot de passe pour obtenir le numéro de version.

    Comparez les deux mots de passe hachés (base de données de hachage pour le nom d'utilisateur et le tapé en & hachage de mot de passe). Vous pouvez dire si "ce qu'ils ont tapé dans" appariés "ce que l'original utilisateur a entré son mot de passe" en comparant leurs empreintes.

    Un crédit supplémentaire:

    Question: Si j'avais votre base de données, ne pourrais-je pas simplement prendre un pirate, comme John the Ripper et commencer à faire des hachages jusqu'à ce que je trouve correspond à votre stockées, les mots de passe hachés?
    (puisque les utilisateurs à sélectionner court, dictionnaire des mots de toute façon ... il devrait être facile)

    Réponse: Oui ... oui ils le peuvent.

    Donc, vous devriez " sel " vos mots de passe.
    Voir la Article de wikipédia sur le sel

    Voir "Comment hachage de données avec le sel" exemple en C#

    • Nice post, sauf pour une chose: md5 et sha1 ont tous les deux été brisé. Vous devriez sans doute aller avec un plus fort algorithme, comme peut-être le SHA2 de la famille.
    • Merci Paolo -- vous avez raison. Comme l'utilisation de SHA2 est aussi facile que d'utiliser MD5 & SHA1, veuillez utiliser le plus fort de l'algorithme de hachage.
    • SHA-1 n'a pas été brisé. Mais à paraphase Bruce Schneier: Walk, don't run, SHA-2.
    • "Donc, vous devriez 'sel' votre mot de passe"... Mais le sel est généralement stocké dans la base de données avec le mot de passe, alors, comment fait-il m'aider? Te attaquant suffit d'ajouter le sel à l'attaque de dictionnaire des expressions qu'il est à l'essai contre. Comment est-ce plus sûr d'autres qu'il ne révèle pas de dupliquer les mots de passe?
    • jamais ... vraiment ... besoin de connaître le mot de passe utilisateur" - c'est une très myope hypothèse. Il existe de nombreux types d'applications où le fait d'avoir un mot de passe stocké dans une manière qui peut être récupéré est véritablement nécessaire. Par exemple, une application qui doit fréquemment de connexion à un autre système avec des informations d'identification stockées, transmises et mises à jour par un utilisateur.
    • c'est une mauvaise conception des deux systèmes, parce que quand mon système est compromis, maintenant mes utilisateurs sur votre système sont trop. oAuth et l'envie de contourner ce problème, mais vous avez besoin d'un "autre système" afin de la soutenir. Vous ne devriez jamais réversible crypter un mot de passe des utilisateurs.
    • De nouveau en disant: "vous ne devriez jamais"... Dites-moi, comment voulez-vous stocker les informations d'identification pour accéder à une API comme une API REST pour PayPal ou Twilio ou tout autre système qui vous offre un utilisateur et la clé (qui agit comme un mot de passe)? Que faire si votre système d'interfaces avec les Api non seulement pour vous mais pour plusieurs clients? Vous avez BESOIN de trouver un moyen de sécuriser ces données et que le moyen n'existe pas. Deux façon de méthodes de cryptage de servir un but, ils ne sont pas là comme un "mauvais choix". De mauvais choix à la façon dont vous décidez de la mettre en œuvre.
    • PayPal utilise le protocole OAuth 2.0 comme auth mécanisme. Si PayPal vous a permis de conserver mon PayPal pwd dans une 3e partie application, il serait une catastrophe, car ils ont peu de contrôle sur tous les indépendants de l'application de sécurité. Un jeton OAuth permet de contourner cela, et c'est pas le mot de passe, donc c'est ok pour stocker de façon réversible sous forme chiffrée. Ni mon PayPal pwd jamais mis à la disposition du système de tiers, comme lorsque je me connecte à PayPal, je suis sur leur site, pas le tiers. C'est la façon dont votre système devrait interface avec eux. Cette discussion pourrait justifier sa propre question pour lui demander si c'est toujours OK"!
    • vous devriez jeter un oeil à la POP et IMAP et de revenir avec la bonne façon de s'authentifier sur ces services. Aussi ping de Google au sujet de comme ils sont le stockage de ces informations dans votre compte gmail (quand vous avez besoin d'accéder à des systèmes de messagerie via le protocole IMAP ou POP). Sérieux en disant cela montre simplement que vous n'avez pas travaillé sur la vie réelle des Api.
    • Gardons cette technique et de laisser les suppositions au sujet de mon histoire personnelle pour la pub. J'avoue que le webmail est un cas, je n'ai jamais pensé, mais de la POP et IMAP remontent aux années 80 lorsque la sécurité est une chose différente. Juste parce que vous pouvez le faire ne signifie pas que vous devriez le faire, cependant, et je l'ai utilisé pour transférer mon courrier POP de gMail pour que je puisse éviter cette situation. PayPal pourrait bloquer votre système à partir d'y accéder si vous avez fait la même, pour une bonne raison. Moderne API de développeur doit s'assurer que le stockage de mots de passe n'est pas nécessaire (ou possible) en fournissant oAuth et d'autres mécanismes.

    InformationsquelleAutor joej
  3. 30

    Comme l'un des principaux durci salé de hachage, à l'aide d'un algorithme sécurisé tels que sha-512.

    • À mon avis, vous devriez toujours utiliser lente algorithmes (comme Blowfish, par exemple) pour stocker les mots de passe. Cet article est une bien meilleure réponse: security.stackexchange.com/questions/211/.... Il suffit de le mettre ici, parce que cette page apparaît toujours en haut dans les résultats de recherche.
    • En suivant ces conseils pour le stockage de mot de passe serait de le faire terriblement mal.
    InformationsquelleAutor nilamo
  4. 26

    La meilleure pratique de sécurité est de ne pas stocker le mot de passe à tous (même cryptées), mais pour stocker le salé de hachage (avec un unique sel par mot de passe) du mot de passe crypté.

    De cette façon, il est (quasiment) impossible de récupérer un mot de passe en clair.

    • Wayne, par salage avant de calculer le hachage, l'arc-en-ciel de la table est effectivement vaincu, à condition que le sel est d'une taille suffisante.
    • Hartman: Pas tellement. Si le sel de la valeur est exposé, alors vous devez générer un nouveau rainbow table pour le sel de la valeur. Le point d'un arc-en-ciel de la table est d'avoir des valeurs de hachage calculé au préalable. Et personne n'aura un arc-en-ciel de la table de son sel.
    InformationsquelleAutor Mitch Wheat
  5. 10

    J'avais recommandons de lire les articles Assez Avec Les Tables Arc-En-Ciel: Ce Que Vous Devez Savoir Sur Les Régimes De Mot De Passe Sécurisé [lien mort, copie à l'Internet Archive] et Comment Stocker En Toute Sécurité D'Un Mot De Passe.

    Beaucoup de codeurs, moi y compris, pense qu'ils comprennent la sécurité et de hachage. Malheureusement, la plupart d'entre nous ne le font pas.

    InformationsquelleAutor zebrabox
  6. 6

    J'ai peut-être un peu hors-sujet, comme vous l'avez fait mention de la nécessité d'un nom d'utilisateur et le mot de passe, et ma compréhension de la question est peut l'admettre comme pas le meilleur, mais est OpenID quelque chose à considérer?

    Si vous utiliser OpenID, alors vous n'avez pas à stocker des informations d'identification à tous, si je comprends la technologie correctement et les utilisateurs peuvent utiliser les informations d'identification qu'ils ont déjà, en évitant la nécessité de créer une nouvelle identité qui est spécifique à votre application.

    Il peut ne pas être adaptée à l'application en question est purement pour l'usage interne, mais

    RPX fournit une bonne manière de intégrons OpenID de la prise en charge d'une application.

    • Je suis d'accord que openID roches peuples face off, mais pour cette application, il est dans la maison de base de données pour une entreprise, je doute qu'ils seraient comme toute personne âgée de venir se connecter. aussi un accès web n'est pas nécessaire pour cette application fonctionne correctement, donc je ne voudrais pas besoin.
    InformationsquelleAutor Crippledsmurf
  7. 3

    Dans votre scénario, vous pouvez jeter un oeil à asp.net l'adhésion, il est de bonne pratique pour stocker de l'utilisateur mot de passe hashé en chaîne de caractères dans la base de données. vous pouvez vous authentifier l'utilisateur en comparant hachés entrant le mot de passe avec celui stocké dans la base de données.

    Tout a été construit pour cet usage, découvrez asp.net l'adhésion

    InformationsquelleAutor Ray Lu
  8. 2

    Je MD5/SHA1 le mot de passe si vous n'avez pas besoin d'être en mesure d'inverser la valeur de hachage. Lors de la connexion des utilisateurs, vous pouvez crypter le mot de passe donné et le comparer à la valeur de hachage. Les collisions de hachage sont presque impossible dans ce cas, à moins que quelqu'un accède à la base de données et voit un hachage ils ont déjà une collision pour.

    • Je ne voudrais pas utiliser MD5 pour le hachage - c'est fondamentalement cassé, msc.dal.ca/~selinger/md5collision
    • En fait, il n'est pas cassé. Ce qu'ils peuvent faire est de trouver la même valeur de hachage pour les deux fichiers différents. Ce qu'ils ne peuvent pas faire est de renverser le MD5 et obtenir un mot de passe.
    • Eh bien, ce ne serait pas cassé aussi alors? Il vous suffit d'entrer le autre mot de passe que génère le même hash, et vous êtes dans. Vous n'avez pas besoin de connaître le mot de passe original. Le moyen de résoudre ce problème est si vous le sel le mot de passe avant de hachage.
    • si vous ajoutez du sel pour le mot de passe avant de vous utiliser MD5 de la collision n'a pas d'importance parce que vous ne pouvez pas utiliser un autre mot de passe
    InformationsquelleAutor waiwai933