最好的安全实践是根本不存储密码(甚至不加密)，而是存储加密密码的咸散列(每个密码具有唯一的盐)。

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

作为一个密钥加固的咸散列，使用安全算法，如sha-512。

You are correct that storing the password in a plain-text field is a horrible idea. However, as far as location goes, for most of the cases you're going to encounter (and I honestly can't think of any counter-examples) storing the representation of a password in the database is the proper thing to do. By representation I mean that you want to hash the password using a salt (which should be different for every user) and a secure 1-way algorithm and store that, throwing away the original password. Then, when you want to verify a password, you hash the value (using the same hashing algorithm and salt) and compare it to the hashed value in the database.

所以，虽然你在思考这个问题是一件好事，这是一个好问题，但这实际上是这些问题的副本(至少):

如何最好地存储用户信息和用户登录名和密码 存储数据库密码的最佳实践 给密码加盐:最佳做法? 是否可以在php变量或php常量中以纯文本形式存储密码?

To clarify a bit further on the salting bit, the danger with simply hashing a password and storing that is that if a trespasser gets a hold of your database, they can still use what are known as rainbow tables to be able to "decrypt" the password (at least those that show up in the rainbow table). To get around this, developers add a salt to passwords which, when properly done, makes rainbow attacks simply infeasible to do. Do note that a common misconception is to simply add the same unique and long string to all passwords; while this is not horrible, it is best to add unique salts to every password. Read this for more.

在你的场景中，你可以看看asp.net会员，这是一个很好的做法，存储用户的密码作为散列字符串在数据库中。您可以通过将散列后的传入密码与存储在数据库中的密码进行比较来验证用户。

所有东西都是为此目的而构建的，请查看asp.net会员

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

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

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

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

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