Meilleur moyen de stocker le mot de passe dans la base de données [fermé]

476

Je travaille sur un projet qui doit avoir une authentification (nom d'utilisateur et mot de passe)

Il se connecte également à une base de données, j'ai donc pensé y stocker le nom d'utilisateur et le mot de passe. Cependant, il semble que ce ne soit pas une bonne idée d'avoir des mots de passe comme juste un champ de texte dans une table assise sur la base de données.

J'utilise C # et je me connecte à un serveur express 2008. Quelqu'un peut-il suggérer (avec autant d'exemples que possible) quelle serait la meilleure façon de stocker ce type de données?

PS Je suis ouvert à l'idée que ces informations ne soient pas stockées dans la base de données si une bonne raison peut être fournie

database security passwords

— Crash893
source

1

Quoi que vous fassiez, si vous optez pour le cryptage, ne stockez pas la clé dans le code comme une affiche précédente mentionnée. C'est juste une mauvaise pratique.

— Woody

12

'Comment bien faire les mots de passe?' est une question vitale. C'est un problème difficile et les erreurs ont de graves conséquences (rappelez-vous ce qui est arrivé à Tesco et LinkedIn). Je pense que cette question devrait être rouverte à programmers.stackexchange.com

— Colonel Panic

2

Il vaut mieux s'en tenir aux normes - voir en.wikipedia.org/wiki/PBKDF2 Vous n'avez qu'à trouver une implémentation dans votre langue

— Boris Treukhov

5

Cette question est largement répondue dans le forum de sécurité

— gioele

406

Vous avez raison, le stockage du mot de passe dans un champ en texte brut est une idée horrible . Cependant, en ce qui concerne l'emplacement , pour la plupart des cas que vous allez rencontrer (et je ne peux honnêtement pas penser à des contre-exemples), stocker la représentation d'un mot de passe dans la base de données est la bonne chose à faire. Par représentation Je veux dire que vous voulez hash du mot de passe en utilisant un sel (qui devrait être différent pour chaque utilisateur) et un algorithme de 1 manière sécurisée et un magasin qui , jeter le mot de passe d' origine. Ensuite, lorsque vous souhaitez vérifier un mot de passe, vous hachez la valeur (en utilisant le même algorithme de hachage et le même sel) et la comparez à la valeur hachée de la base de données.

Donc, même si c'est une bonne chose que vous y réfléchissiez et que c'est une bonne question, il s'agit en fait d'un double de ces questions (au moins):

Pour clarifier un peu plus le bit de salage, le danger avec simplement le hachage d'un mot de passe et le stockage est que si un intrus prend possession de votre base de données, il peut toujours utiliser ce que l'on appelle des tables arc- en- ciel pour pouvoir "décrypter" le mot de passe (au moins ceux qui apparaissent dans la table arc-en-ciel). Pour contourner ce problème, les développeurs ajoutent un sel aux mots de passe qui, lorsqu'ils sont correctement effectués, rendent les attaques arc-en-ciel tout simplement irréalisables. Notez qu'une idée fausse courante consiste simplement à ajouter la même chaîne unique et longue à tous les mots de passe; bien que ce ne soit pas horrible , il est préférable d'ajouter des sels uniques à chaque mot de passe. Lisez ceci pour en savoir plus.

— Paolo Bergantino
source

40

Je voulais dire stocker le mot de passe dans la base de données plutôt que de le stocker ailleurs. Sortir cette phrase de son contexte donne l'impression que je suis en faveur du stockage de mots de passe simples, si vous lisez le reste, je ne le fais évidemment pas.

— Paolo Bergantino

14

Non seulement c'est ce que j'ai dit, je l'ai dirigé vers une pléthore de messages qui traitent des sels et autres ...

— Paolo Bergantino

1

@Paolo Bergantino: vous êtes sûr qu'il n'y a pas de faute de frappe dans votre message? Il dit: "Dans la plupart des cas, vous allez rencontrer (et je ne peux honnêtement pas penser à des contre-exemples) stocker le mot de passe dans la base de données est la bonne chose à faire." ??? Il semble contredire vos commentaires

— Mitch Wheat

3

Ce que Paolo a dit se contredit directement. Un hachage salé d'un mot de passe n'est pas un mot de passe. Le stockage d'un hachage salé du mot de passe dans la base de données ne stocke pas le mot de passe dans la base de données. Le corps de la réponse est parfaitement approprié, mais sa première phrase est extrêmement trompeuse.

— Robert Rossney

40

@Robert: Cela se rapproche dangereusement d'un petit jeu de sémantique, mais je vais le corriger quand même ...

— Paolo Bergantino

54

Contexte Vous n'avez jamais ... vraiment ... besoin de connaître le mot de passe de l'utilisateur. Vous voulez simplement vérifier qu'un utilisateur entrant connaît le mot de passe d'un compte.

Hash It: Stockez les mots de passe des utilisateurs hachés (cryptage unidirectionnel) via une fonction de hachage puissante. Une recherche de "c # encrypt passwords" donne une multitude d'exemples.

Voir le créateur de hachage SHA1 en ligne pour une idée de ce que produit une fonction de hachage (mais n'utilisez pas SHA1 comme fonction de hachage, utilisez quelque chose de plus fort tel que SHA256).

Maintenant, un mot de passe haché signifie que vous (et les voleurs de base de données) ne devriez pas être en mesure de rétablir ce hachage dans le mot de passe d'origine.

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

Lorsque l'utilisateur se connecte, il vous remet le nom d'utilisateur et le mot de passe (dans son texte d'origine) Vous utilisez simplement le même code de hachage pour hacher ce mot de passe tapé pour obtenir la version stockée.

Donc, comparez les deux mots de passe hachés (hachage de la base de données pour le nom d'utilisateur et le mot de passe tapé et haché). Vous pouvez savoir si "ce qu'ils ont tapé" correspondait "à ce que l'utilisateur d'origine a entré pour son mot de passe" en comparant leurs hachages.

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 à créer des hachages jusqu'à ce que je trouve des correspondances avec vos mots de passe stockés et hachés? (puisque les utilisateurs choisissent de toute façon des mots de dictionnaire courts ... ça devrait être facile)

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

Donc, vous devez «saler» vos mots de passe. Voir l'article Wikipedia sur le sel

Voir l'exemple "Comment hacher des données avec du sel" C #

— joej
source

14

Beau message, sauf pour une chose: md5 et sha1 ont tous deux été cassés. Vous devriez probablement opter pour un algorithme plus puissant, comme peut-être la famille SHA2.

— Paolo Bergantino

3

Merci Paolo - tu as raison. Comme l'utilisation de SHA2 est aussi simple que l'utilisation de MD5 et SHA1, veuillez utiliser l'algorithme de hachage plus fort.

— joej

5

SHA-1 n'a pas été cassé. Mais pour paraphaser Bruce Schneier: Marchez, ne courez pas, vers SHA-2.

— Ian Boyd

3

"Donc, vous devriez" saler "vos mots de passe" ... Mais le sel est généralement stocké dans la base de données avec le mot de passe, alors comment cela peut-il aider? L'attaquant n'a qu'à ajouter le sel aux phrases d'attaque du dictionnaire contre lesquelles il teste. Comment est-ce plus sûr, sinon qu'il ne révèle pas les mots de passe en double?

— trusktr

4

@joej "Vous n'avez jamais ... vraiment ... besoin de connaître le mot de passe de l'utilisateur" - c'est une hypothèse à très courte vue. Il existe de nombreux types d'applications pour lesquelles un mot de passe stocké d'une manière qui peut être récupéré est vraiment nécessaire. Par exemple, une application qui doit se connecter fréquemment à un autre système avec des informations d'identification stockées, fournies et mises à jour par un utilisateur.

— Francisco Zarabozo

29

En tant que hachage salé renforcé, en utilisant un algorithme sécurisé tel que sha-512.

— nilamo
source

6

À mon avis, vous devriez toujours utiliser des algorithmes lents (comme Blowfish, par exemple) pour stocker les mots de passe. Cette rédaction est une bien meilleure réponse: security.stackexchange.com/questions/211/… . Il suffit de le mettre ici, car cette page apparaît toujours en haut dans les résultats de recherche.

— Dynom

2

Suivre ces conseils pour le stockage des mots de passe serait terriblement mal.

— mlissner

27

La meilleure pratique de sécurité n'est pas de stocker le mot de passe (pas même chiffré), mais de stocker le hachage salé (avec un sel unique par mot de passe) du mot de passe chiffré.

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

— Blé Mitch
source

11

Wayne, en salant avant de calculer le hachage, la table arc-en-ciel est efficacement vaincue, à condition que le sel soit de taille suffisante.

— Mike Rosenblum

12

@Wayne Hartman: Pas du tout. Si la valeur de sel est exposée, vous devez générer une nouvelle table arc-en-ciel pour cette valeur de sel spécifique. Le point d'une table arc-en-ciel est d'avoir des valeurs de hachage calculées à l'avance. Et personne n'aura de table arc-en-ciel pour son sel spécifique.

— Ian Boyd

10

Je vous recommande vivement de lire les articles Assez avec les tables arc-en-ciel: ce que vous devez savoir sur les schémas de mots de passe sécurisés [lien mort, copie sur les archives Internet ] et comment stocker en toute sécurité un mot de passe .

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

— zebrabox
source

1

@Johan On dirait que le lien est maintenant rompu, ce qui est dommage. Voici une alternative codahale.com/how-to-safely-store-a-password

— zebrabox

6

Je suis peut-être légèrement hors sujet, car vous avez mentionné la nécessité d'un nom d'utilisateur et d'un mot de passe, et ma compréhension du problème n'est certes pas la meilleure, mais OpenID mérite-t-il d'être envisagé?

Si vous utilisez OpenID, vous ne stockez pas du tout les informations d'identification si je comprends bien la technologie et les utilisateurs peuvent utiliser les informations d'identification qu'ils ont déjà, évitant ainsi de créer une nouvelle identité spécifique à votre application.

Elle peut ne pas convenir si l'application en question est purement à usage interne

RPX fournit un moyen simple et agréable d'intégrer la prise en charge d'OpenID dans une application.

— Crippledsmurf
source

Je suis d'accord que openID bouscule les peuples, mais pour cette application, il s'agit d'une base de données interne pour une entreprise, je doute qu'ils souhaitent que toute personne âgée se connecte. l'accès à Internet n'est également pas nécessaire pour que cette application fonctionne correctement, donc je détesterais l'exiger.

— Crash893

3

Dans votre scénario, vous pouvez consulter l'appartenance à asp.net, il est recommandé de stocker le mot de passe de l'utilisateur sous forme de chaîne hachée dans la base de données. vous pouvez authentifier l'utilisateur en comparant le mot de passe entrant haché avec celui stocké dans la base de données.

Tout a été construit à cet effet, consultez l' adhésion asp.net

— Ray Lu
source

1

Je voudrais MD5 / SHA1 le mot de passe si vous n'avez pas besoin de pouvoir inverser le hachage. Lorsque les utilisateurs se connectent, vous pouvez simplement crypter le mot de passe donné et le comparer au hachage. Les collisions de hachage sont presque impossibles dans ce cas, sauf si quelqu'un accède à la base de données et voit un hachage pour lequel il a déjà une collision.

— waiwai933
source

2

Je n'utiliserais pas MD5 pour le hachage - il est fondamentalement cassé mscs.dal.ca/~selinger/md5collision

— zebrabox

3

En fait, ce n'est pas si cassé. Ce qu'ils peuvent faire, c'est trouver la même valeur de hachage pour deux fichiers différents. Ce qu'ils ne peuvent pas faire, c'est inverser le MD5 et obtenir un mot de passe qui fonctionne.

— waiwai933

2

Eh bien, cela ne serait-il pas cassé aussi? Vous entrez simplement l'autre mot de passe qui génère le même hachage, et vous y êtes. Vous n'avez pas besoin de connaître le mot de passe d'origine. La solution consiste à saler le mot de passe avant le hachage.

— mjuarez

2

@mjuarez si vous ajoutez un sel au mot de passe avant d'utiliser MD5, la collision n'a pas d'importance car vous ne pouvez pas utiliser l'autre mot de passe

— WiiMaxx