在 SQL Server 2008 中存储用户密码的建议做法是什么？
我正在存储 Intranet 的用户详细信息，并且希望获得有关存储用户详细信息（例如名称、密码和用户访问权限等）的最佳方式的建议。我正在考虑创建一个 nvarchar 列，然后在插入之前加密此文本到表中。
存储密码的常用方法是对密码使用哈希函数，但要事先对其进行salt。对密码进行“加盐”很重要，以防御 rainbow table 攻击。
所以你的桌子应该看起来像这样
._______._________________.______________.
|user_id|hash |salt |
|-------|-----------------|--------------|
|12 |adsgasdg@g4wea...|13%!#tQ!#3t...|
| |... |... |
检查给定密码是否与用户匹配时，应将盐连接到给定密码，并计算结果字符串的哈希函数。如果哈希函数输出与
hash然而，重要的是要理解盐哈希想法有一个特定的原因——防止任何有权访问数据库的人知道任何人的密码（反转哈希函数输出被认为是困难的问题）。例如，银行的 DBA 无法登录您的银行帐户，即使他有权访问所有列。
如果您认为您的用户会使用敏感密码（例如 Gmail 帐户的密码）作为您网站的密码，您也应该考虑使用它。
恕我直言，这并不总是需要的安全功能。所以你应该考虑一下你是否想要它。
请参阅本文，了解此机制的详细总结。
更新：值得一提的是，为了针对逆转个人密码哈希的针对性攻击提供额外的安全性，您应该使用bcrypt，这可能很难计算。 （但是除非你真的害怕神秘的黑衣人针对你的特定数据库，否则我认为 sha1 已经足够好了。我不会为了额外的安全性而为我的项目引入另一个依赖项。也就是说，没有理由不使用 sha1 100 次，会产生类似的效果）。
敏感数据的加密效果很好。然而，使用密码，您永远不需要知道原始值，并且由于任何加密的内容也可以解密，因此您将该信息置于被发现的危险之中。
相反，您应该保留密码的哈希值。这个过程获取该值并生成一个非常复杂的校验和。给定该数字，就无法返回原始密码，这提高了此类信息的安全性。当您想知道某人是否给了您正确的密码时，您可以对他们给您的值进行散列并比较散列值。
安全是一个复杂的话题。即使使用哈希值，您最终也可能会拥有一个存在重大安全缺陷的系统。如果您的团队中没有其他人具备此类知识，那么获得安全顾问的帮助并不是一个坏主意。
这通常是这样做的方法。
您的应用程序将处理加密（以及可选的解密），数据库将仅存储密码。
我建议使用比过时的事实更强的东西 - MD5
大多数 .net 开发人员似乎喜欢使用 TDES
T-Sql 包含加密功能 - 4Guys 有一篇关于 SQL Server 2005 的好文章 不久前，但我认为这一切仍然适用于 2008 年。
请读出密码存储