Quelle est votre méthode préférée/type de données pour stocker des mots de passe dans une base de données (préférence SQL Server 2005). La façon dont j’ai fait il dans plusieurs de nos applications est de d’abord utiliser les bibliothèques de chiffrement de .NET et puis les stocker dans la base de données comme Binary (16). C’est la méthode préférée ou dois-je être à l’aide d’un type de données différent ou allouer plus d’espace que 16 ?
Réponses
Trop de publicités?
J’ai stocker l’équivalent de hachage salted du mot de passe dans la base de données et jamais le mot de passe, puis toujours comparer le hash à celui généré de ce que l’utilisateur a passé dans.
C’est trop dangereux pour jamais stocker les données de mot de passe littéral n’importe où. Cela rend impossible la récupération, mais quand quelqu'un oublie ou perd un mot de passe vous pouvez exécuter par le biais de quelques vérifications et créer un nouveau mot de passe.
Assaf Lavie
Points
20181
Josh Stodola
Points
42410
Je fais la même chose que vous avez décrit, mais il est stocké sous forme de chaîne. Base64 encoder la valeur binaire cryptée. La quantité d’espace à allouer dépend de la force d’algorithme de chiffrement/cryptage.
Je pense que vous le faites droit (compte tenu du fait que vous utilisiez un sel).
MiniQuark
Points
8927
- stocker la valeur de hachage de l'salée, mot de passe, comme bcrypt(nounce+pwd). Vous préférerez peut-être bcrypt sur SHA1 ou MD5, car il peut être réglé pour être CPU-intensive, donc de faire une attaque en force façon de plus.
- ajouter un captcha pour le formulaire de connexion après quelques erreurs de connexion (pour éviter les attaques en force)
- si votre application dispose d'un "j'ai oublié mon mot de passe", assurez-vous de ne pas envoyer le nouveau mot de passe par e-mail, mais au lieu de cela, il doit envoyer un lien à un (sécurisé) page permettant à l'utilisateur de définir un nouveau mot de passe (peut-être seulement après la confirmation de certains renseignements personnels, tels que votre date de naissance, par exemple). Aussi, si votre application permet à l'utilisateur de définir un nouveau mot de passe, assurez-vous de demander à l'utilisateur de confirmer le mot de passe actuel.
- et, évidemment, de sécuriser le formulaire de connexion (généralement avec HTTPS) et les serveurs eux-mêmes
Avec ces mesures, vos mots de passe utilisateur sera assez bien protégés contre:
- => les attaques par dictionnaire hors ligne
- => live les attaques de dictionnaire.
- => attaques par déni de service
- => toutes sortes d'attaques!
erickson
Points
127945
Depuis le résultat d'une fonction de hachage est une série d'octets dans la plage de 0 à 255 (ou -128 à 127, selon l'signé-ness de votre 8 bits type de données), de les stocker en tant que données binaires brutes champ qui fait le plus de sens, car il est le plus compact de la représentation et ne nécessite pas de supplémentaire de codage et de décodage étapes.
Certaines bases de données ou les pilotes n'ont pas un grand soutien pour les types de données binaires, ou parfois, les développeurs ne sont pas assez familiers avec eux pour se sentir à l'aise. Dans ce cas, à l'aide d'une binaire à l'encodage du texte de Base-64 ou Base de 85, et de stocker le texte dans un champ de caractères est acceptable.
La taille du champ nécessaire est déterminée par la fonction de hachage que vous utilisez. MD5 toujours sorties de 16 octets, SHA-1 toujours les sorties de 20 octets. Une fois que vous sélectionnez une fonction de hachage, vous êtes habituellement coincé avec elle, car la modification nécessite une remise à zéro de tous les mots de passe existants. Donc, à l'aide d'une variable de taille de champ, ne pas acheter quelque chose.
Quant à la "meilleure" façon d'effectuer le hachage, j'ai essayé d'apporter beaucoup de réponses à d'autres DONC des questions sur ce sujet:
