Quelle est la pratique recommandée pour stocker les mots de passe utilisateur dans SQL Server 2008? Je stocke les détails d'utilisateur pour un intranet, et voudrais obtenir des conseils sur la meilleure manière de stocker des détails d'utilisateur tels que nom, mot de passe et privillages d'accès d'utilisateur etc. Je pense à créer une colonne de nvarchar, puis crypter cette texte avant de l'insérer dans la table.stocker les mots de passe dans SQL Server
c'est généralement la façon de le faire.
Votre application se chargera de l'encryptage (et le cas échéant le décryptage), la base de données simplement stocker le mot de passe.
Je recommande d'utiliser quelque chose de plus fort que la defacto datée - MD5
La plupart des développeurs .net semblent aimer l'aide TDES
Je suis d'accord que vous voulez aller avec quelque chose de plus fort que MD5 quand vous pouvez –
MD5 n'est pas un algorithme de cryptage, c'est un algorithme de hachage. http://en.wikipedia.org/wiki/MD5 –
D'accord. Je suppose que je n'étais pas explicite donc vous obtenez un up :) –
T-Sql inclut des fonctions de chiffrement - 4Guys avait une good article on it for SQL Server 2005 aa en arrière, mais je pense qu'il tout s'applique encore à 2008.
Cet article est sur le cryptage de clé symétrique. Les mots de passe doivent être hachés. – Swoogan
Je suis d'accord - l'article auquel je suis lié est daté de manière significative. C'est pourquoi j'ai personnellement rejeté la réponse d'elazar-leibovich ci-dessus. –
Le cryptage des données sensibles est bon. Toutefois, avec les mots de passe, vous ne devriez jamais avoir besoin de connaître la valeur d'origine, et puisque tout ce qui est chiffré peut également être décrypté, vous risquez d'être découvert.
Au lieu de cela, vous devez garder un hachage du mot de passe. Ce processus prend la valeur et génère ce qui équivaut à une somme de contrôle très compliquée. Compte tenu du nombre, il n'y a aucun moyen de revenir au mot de passe d'origine, ce qui augmente la sécurité de ces informations. Lorsque vous voulez savoir si quelqu'un vous a donné le mot de passe correct, vous devez hacher la valeur qu'il vous a donnée et comparer les hachages.
La sécurité est un sujet compliqué. Même avec des hachages, vous pouvez avoir un système qui a des failles de sécurité importantes. Obtenir l'aide d'un consultant en sécurité n'est pas une mauvaise idée si personne d'autre dans votre équipe n'a déjà ce genre de connaissances.
Très vrai dans la plupart des cas. Étant donné que l'OP utilise sur un intranet, il peut y avoir des circonstances (intégration avec d'autres applications sur l'intranet qui nécessitent une connexion) où il est utile de pouvoir récupérer le mot de passe. –
La manière habituelle de stocker le mot de passe, est d'utiliser une fonction de hachage du mot de passe, mais salt avance. Il est important de "salt" le mot de passe, pour se défendre contre les attaques rainbow table.
donc votre table devrait ressembler à quelque chose comme ça
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |[email protected]|13%!#tQ!#3t...|
| |... |... |
Lors de la vérification si un mot de passe donné correspond à un utilisateur, vous devez concaténer le sel du mot de passe donné, et calculer la fonction de hachage de la chaîne de résultat. Si la sortie de la fonction de hachage correspond à la colonne hash - c'est le mot de passe correct. Il est important de comprendre cependant que l'idée de hachage de sel a une raison spécifique - pour empêcher quiconque ayant accès à la base de données de connaître un mot de passe (il est considéré comme un problème difficile d'inverser une sortie de hachage). Ainsi, par exemple, le DBA de la banque ne serait pas en mesure de se connecter à votre compte bancaire, même s'il a accès à toutes les colonnes.
Vous devriez également envisager de l'utiliser si vous pensez que vos utilisateurs utiliseront un mot de passe sensibles (par exemple leur mot de passe pour leur compte gmail) comme un mot de passe à votre site Web.
à mon humble avis, il est pas toujours une fonction de sécurité qui est nécessaire. Donc vous devriez penser si vous le voulez ou non.
Voir this article pour un bon résumé de ce mécanisme.
Mise à jour: Il est à noter que pour plus de sécurité contre les attaques ciblées pour inverser le hachage de mot de passe individuel, vous devez use bcrypt, qui peut être arbitrairement difficile à calculer. (Mais à moins que vous ayez vraiment peur de l'homme mystérieux en noir qui cible votre base de données spécifique, je pense que sha1 est assez bon.Je ne voudrais pas introduire une autre dépendance pour mon projet pour cette sécurité supplémentaire.Cela dit, il n'y a aucune raison de ne pas utiliser sha1 100 fois, ce qui donnerait un effet similaire).
lien ci-dessus ne fonctionne pas, mais [ceci] (http://msdn.microsoft.com/en-us/library/ff649202.aspx) on fait. – JumpingJezza
@JumpingJezza, merci, ça marchait, je suis en train de mettre à jour le lien –
S'il s'agit d'un domaine AD, ne pouvez-vous pas laisser AD gérer l'authentification? – Rytmis
Merci à tous pour vos suggestions. Richard – Richard