Méthode préférée pour stocker les mots de passe dans la base de données

https://stackoverflow.com/questions/615704

03-07-2019
|

Question

Quelle est votre méthode / type de données préféré pour stocker les mots de passe dans une base de données (de préférence SQL Server 2005). Dans plusieurs de nos applications, je l’ai fait en premier lieu, en utilisant les bibliothèques de chiffrement .NET, puis en les stockant dans la base de données au format binaire (16). Est-ce la méthode préférée ou devrais-je utiliser un type de données différent ou allouer plus d'espace que 16?

La solution

Je stocke l'équivalent hash du mot de passe salted dans la base de données et jamais le mot de passe lui-même, puis compare toujours le hachage à celui généré par l'utilisateur.

Il est trop dangereux de stocker les données de mot de passe littérales n’importe où. Cela rend la récupération impossible, mais si quelqu'un oublie ou perd un mot de passe, vous pouvez effectuer certaines vérifications et créer un nouveau mot de passe.

Autres conseils

LA méthode préférée: ne stockez jamais les mots de passe dans votre base de données. Seuls les hashes. Ajoutez du sel à votre goût.

Je fais la même chose que vous avez décrite, sauf qu'elle est stockée sous forme de chaîne. I Base64 encoder la valeur binaire cryptée. La quantité d’espace à allouer dépend de l’algorithme de cryptage / de la force du chiffrement.

Je pense que vous faites bien les choses (étant donné que vous utilisez un Salt ). .

stocke le hachage du mot de passe salted, tel que bcrypt (nounce + pwd). Vous préférerez peut-être bcrypt à SHA1 ou MD5 car il peut être paramétré pour nécessiter une utilisation intensive du processeur, augmentant ainsi le temps d’attaque par force brute.
ajoutez un captcha au formulaire de connexion après quelques erreurs de connexion (pour éviter les attaques brutales)
si votre application dispose du " mot de passe oublié " link, assurez-vous qu'il n'envoie pas le nouveau mot de passe par courrier électronique, mais qu'il envoie plutôt un lien vers une page (sécurisée) permettant à l'utilisateur de définir un nouveau mot de passe (éventuellement uniquement après confirmation de certaines informations personnelles, telles que la naissance de l'utilisateur) date, par exemple). De même, si votre application permet à l'utilisateur de définir un nouveau mot de passe, assurez-vous que l'utilisateur doit confirmer le mot de passe actuel.
et bien sûr, sécurisez le formulaire de connexion (généralement avec HTTPS) et les serveurs eux-mêmes

Avec ces mesures, les mots de passe de vos utilisateurs seront assez bien protégés contre:

= > attaques par dictionnaire hors ligne
= > attaques de dictionnaire en direct
= > attaques par déni de service
= > toutes sortes d'attaques!

Etant donné que le résultat d’une fonction de hachage est une série d’octets allant de 0 à 255 (ou -128 à 127, en fonction de la signature de votre type de données 8 bits), son stockage sous forme de champ binaire brut rend le plus logique, car il s’agit de la représentation la plus compacte et ne nécessite aucune étape supplémentaire de codage et de décodage.

Certaines bases de données ou certains pilotes ne prennent pas en charge les types de données binaires, ou bien les développeurs ne les connaissent tout simplement pas suffisamment pour se sentir à l'aise. Dans ce cas, il est acceptable d'utiliser un codage binaire en texte comme Base 64 ou Base 85 et de stocker le texte obtenu dans un champ de caractère.

La taille du champ nécessaire est déterminée par la fonction de hachage que vous utilisez. MD5 génère toujours 16 octets, SHA-1 toujours 20 octets. Une fois que vous avez sélectionné une fonction de hachage, vous êtes généralement coincé avec cette dernière, car toute modification nécessite la réinitialisation de tous les mots de passe existants. Donc, utiliser un champ de taille variable ne vous rapporte rien.

En ce qui concerne le "meilleur" façon de réaliser le hachage, j'ai essayé de fournir de nombreuses réponses à d'autres questions SO sur ce sujet:

J'utilise le sha hash du nom d'utilisateur, un guide dans la configuration Web et le mot de passe, stocké sous la forme varchar (40). S'ils veulent utiliser brute force / dictionary, ils devront également pirater le serveur Web pour obtenir le guide. Le nom d'utilisateur interrompt la création d'une table arc-en-ciel sur l'ensemble de la base de données s'il trouve le mot de passe. Si un utilisateur souhaite modifier son nom d'utilisateur, il suffit de réinitialiser le mot de passe en même temps.

System.Web.Security.FormsAuthentication.HashPasswordForStoringInConfigFile(
    username.ToLower().Trim(),
    ConfigurationManager.AppSettings("salt"),
    password
);

Un simple hachage du mot de passe, ou même (sel + mot de passe) n'est généralement pas adéquat.

voir:

http://www.matasano.com/log/958/enough-with-the-rainbow-tables- what-you-neo-to-know-about-secure-password-schemes/

http://gom-jabbar.org/articles/2008/12/03/why-you-should-use-bcrypt-to-store-your-passwords

Les deux recommandent les algorithmes bcrypt. Des implémentations gratuites sont disponibles en ligne pour les langues les plus populaires.

Vous pouvez utiliser plusieurs hachages dans votre base de données, cela demande juste un petit effort supplémentaire. Cela en vaut la peine si vous croyez qu'il y a une chance, il vous faudra prendre en charge d'autres formats à l'avenir. Je vais souvent utiliser des mots de passe comme

{hashId} $ {salt} $ {mot de passe haché}

où " hashId " C’est juste un nombre que j’utilise en interne pour reconnaître que, par exemple, j’utilise SHA1 avec un motif de hachage spécifique; " sel " est un sel aléatoire codé en base64; et " mot de passe haché " est un hachage codé en base64. Si vous devez migrer des hachages, vous pouvez intercepter les personnes ayant un ancien format de mot de passe et leur demander de changer leur mot de passe lors de leur prochaine connexion.

Comme d'autres l'ont mentionné, vous voulez faire attention avec vos hachages car il est facile de faire quelque chose qui n'est pas vraiment sécurisé, par exemple, H (sel, mot de passe) est beaucoup plus faible que H (mot de passe, sel), mais en même temps. vous voulez équilibrer les efforts déployés dans ce domaine avec la valeur du contenu du site. Je vais souvent utiliser H (H (mot de passe, sel), mot de passe).

Enfin, le coût d’utilisation des mots de passe codés en base64 est modeste par rapport aux avantages de pouvoir utiliser divers outils qui attendent des données texte. Oui, ils devraient être plus flexibles, mais êtes-vous prêt à dire à votre patron qu'il ne peut pas utiliser son outil tiers préféré parce que vous souhaitez enregistrer quelques octets par enregistrement? : -)

Modifié pour ajouter un autre commentaire: si je proposais délibérément d’utiliser un algorithme qui graverait même un dixième de seconde en hachant chaque mot de passe, j’aurais de la chance que l’on se moque du bureau de mon patron. (Pas si chanceux? Il noterait quelque chose à discuter lors de mon prochain examen annuel.) Graver ce temps n'est pas un problème si vous avez des dizaines, voire des centaines d'utilisateurs. Si vous comptez 100 000 utilisateurs, plusieurs personnes se connectent en même temps. Vous avez besoin de quelque chose de rapide et fort, pas lent et fort. Le "mais qu'en est-il des informations de carte de crédit?" est au mieux illusoire dans la mesure où les informations de carte de crédit stockées ne devraient pas se trouver à proximité de votre base de données habituelle, et seraient de toute façon cryptées par l'application, pas par des utilisateurs individuels.

Si vous utilisez ASP.Net, vous pouvez utiliser l'API d'appartenance intégrée.

Il prend en charge de nombreux types d’options de stockage, y compris; un hachage à sens unique, cryptage à deux sens, md5 + sel. http://www.asp.net/learn/security pour plus d'informations.

Si vous n'avez besoin de rien d'extraordinaire, c'est très bien pour les sites Web.

Si vous n'utilisez pas ASP.Net, voici un bon lien vers quelques articles de 4guys et codeproject

http://aspnet.4guysfromrolla.com/articles/081705-1.aspx http://aspnet.4guysfromrolla.com/articles/103002-1.aspx http://www.codeproject.com/KB/security/SimpleEncryption.aspx

Étant donné que votre question concerne la méthode de stockage & amp; taille je vais répondre à cela.

Le type de stockage peut être une représentation binaire ou textuelle (base64 est le plus courant). Le binaire est plus petit mais je trouve plus facile de travailler avec du texte. Si vous effectuez un salage par utilisateur (sel différent par mot de passe), il est plus facile de stocker le sel + le hachage sous forme d'une seule chaîne combinée.

La taille dépend de l’algorithme de hachage. La sortie de MD5 est toujours de 16 octets, SHA1 de 20 octets. SHA-256 & amp; SHA-512 ont 32 ans et plus; 64 octets respectivement. Si vous utilisez l'encodage de texte, vous aurez besoin d'un peu plus d'espace de stockage en fonction de la méthode d'encodage. J'ai tendance à utiliser Base64 car le stockage est relativement bon marché. Base64 nécessitera un champ plus gros d'environ 33%.

Si vous utilisez le salage par utilisateur, vous aurez également besoin d'espace pour le hachage. En assemblant le tout, sel 64 bits + hachage SHA1 (160 bits) codé en base64 prend 40 caractères, je le stocke donc sous forme de caractère (40).

Enfin, si vous voulez le faire correctement, vous ne devriez pas utiliser un seul hachage, mais une fonction de dérivation de clé telle que RBKDF2. Les hachages SHA1 et MD5 sont incroyablement rapides. Même une seule application threadée peut déchiffrer environ 30K à 50K mots de passe par seconde, jusqu'à 200K mots de passe par seconde sur une machine quad core. Les GPU peuvent hacher de 100x à 1000x autant de mots de passe par seconde.Avec des vitesses telles que l'attaque par force brute devient une méthode d'intrusion acceptable. RBKDF2 vous permet de spécifier le nombre d’itérations pour ajuster avec précision le réglage "lent". votre hachage est. Il ne s'agit pas de mettre le système à genoux, mais bien de choisir un nombre d'itérations permettant de limiter la limite supérieure du débit de hachage (par exemple, 500 hachages par seconde). Une méthode future serait d'inclure le nombre d'itérations dans le champ du mot de passe (itérations + sel + hachage). Cela permettrait d'augmenter le nombre d'itérations à l'avenir pour suivre le rythme de processeurs plus puissants. Pour être encore plus flexible, utilisez varchar pour permettre des hachages potentiellement plus importants / alternatifs à l'avenir.

L’implémentation .Net est RFC2892DeriveBytes http://msdn.microsoft.com/en-us /library/system.security.cryptography.rfc2898derivebytes.aspx

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow