在数据库中存储密码的最佳方式 [已关闭]

如果您不需要能够反转哈希，我会MD5 / SHA1密码。当用户登录时，您只需加密给定的密码并将其与哈希值进行比较即可。在这种情况下，哈希冲突几乎是不可能的，除非有人获得对数据库的访问权限并看到他们已经发生冲突的哈希。

在您的方案中，您可以查看 asp.net 成员身份，最好将用户的密码作为哈希字符串存储在数据库中。您可以通过将经过哈希处理的传入密码与数据库中存储的密码进行比较来验证用户身份。

一切都是为此目的而构建的，请查看 asp.net 会员资格

您说得对，将密码存储在纯文本字段中是一个可怕的主意。但是，就位置而言，对于您将遇到的大多数情况（老实说，我想不出任何反例），将密码的表示形式存储在数据库中是正确的做法。通过表示，我的意思是您希望使用盐（每个用户都应该不同）和安全的单向算法对密码进行哈希处理并存储它，扔掉原始密码。然后，当您要验证密码时，对该值进行哈希处理（使用相同的哈希算法和盐），并将其与数据库中的哈希值进行比较。

所以，虽然你正在考虑这个问题是一件好事，这是一个很好的问题，但这实际上是这些问题的重复（至少）：

• 如何最好地存储用户信息以及用户登录名和密码
• 存储数据库密码的最佳实践
• 腌制密码：最佳实践？
• 是否可以将密码以纯文本形式存储在 php 变量或 php 常量中？

为了进一步澄清加盐位，简单地散列密码并存储密码的危险在于，如果入侵者掌握了您的数据库，他们仍然可以使用所谓的彩虹表来“解密”密码（至少是那些出现在彩虹表中的密码）。为了解决这个问题，开发人员在密码中添加了盐，如果操作得当，彩虹攻击根本无法进行。请注意，一个常见的误解是简单地将相同的唯一长字符串添加到所有密码中;虽然这并不可怕，但最好在每个密码中添加独特的盐。阅读此内容以了解更多信息。

作为密钥强化的加盐哈希，使用安全算法（如 sha-512）。

最佳安全做法是根本不存储密码（甚至不加密），而是存储加密密码的加盐哈希（每个密码具有唯一的盐）。

这样（实际上）就不可能检索明文密码。

背景你从不......真。。。需要知道用户的密码。您只想验证传入用户是否知道帐户的密码。

散列一下：通过强哈希函数存储经过哈希处理（单向加密）的用户密码。 搜索“c# 加密密码”会提供大量示例。

请参阅在线 SHA1 哈希创建器，了解哈希函数生成的内容（但不要使用 SHA1 作为哈希函数，请使用更强大的功能，例如 SHA256）。

现在，哈希密码意味着您（和数据库窃贼）不应该能够将该哈希反转回原始密码。

如何使用它：但是，你说，我如何使用存储在数据库中的这个混搭密码？

当用户登录时，他们会向你提供用户名和密码（原始文本） 您只需使用相同的哈希代码对键入的密码进行哈希处理即可获取存储的版本。

因此，比较两个哈希密码（用户名的数据库哈希和输入的哈希密码）。您可以通过比较他们的哈希值来判断“他们输入的内容”是否与“原始用户为其密码输入的内容”匹配。

额外积分：

问题：如果我有你的数据库，那么我就不能拿一个像开膛手约翰这样的破解者，开始进行哈希，直到我找到与你存储的哈希密码相匹配的密码吗？ （因为用户无论如何都会选择简短的字典单词......应该很容易）

答：是的。。。是的，他们可以。

因此，您应该“加盐”您的密码。 请参阅维基百科上关于盐的文章

请参阅“如何使用 salt 对数据进行哈希处理”C# 示例（已存档）

我可能有点跑题了，因为你确实提到了需要用户名和密码，我对这个问题的理解公认不是最好的，但 OpenID 值得考虑吗？

如果您使用 OpenID，那么如果我正确理解该技术，并且用户可以使用他们已经拥有的凭据，那么您最终根本不会存储任何凭据，从而避免了创建特定于您的应用程序的新标识的需要。

但是，如果所讨论的应用程序纯粹供内部使用，则它可能不适合

RPX 提供了一种将 OpenID 支持集成到应用程序中的简单方法。

我强烈建议您阅读文章 Enough With The Rainbow Tables： What You Need To Know About Secure Password Schemes [dead link， copy at the Internet Archive] 和 How To Secure Store A Password.

很多程序员，包括我自己，都认为他们了解安全和哈希。可悲的是，我们大多数人都没有。