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

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

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

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

我强烈建议你阅读《足够的彩虹表:关于安全密码方案你需要知道什么》和《如何安全存储密码》这两篇文章。

很多程序员，包括我自己，认为他们理解安全和哈希。可悲的是，我们大多数人就是不这样做。

背景 你从来没有……真的……需要知道用户的密码。您只是想验证输入的用户知道某个帐户的密码。

散列: 通过强哈希函数存储哈希(单向加密)的用户密码。 搜索“c#加密密码”会给出大量的例子。

查看在线SHA1哈希创建者，了解哈希函数产生的内容(但不要使用SHA1作为哈希函数，使用更强的函数，如SHA256)。

现在，散列密码意味着您(和数据库窃贼)不应该能够将散列反转回原始密码。

如何使用: 但是，如何使用存储在数据库中的这个混合密码呢?

当用户登录时，他们会给你用户名和密码(在原始文本中) 您只需使用相同的哈希代码来哈希输入的密码以获得存储的版本。

因此，比较两个散列密码(用户名的数据库散列和输入的&散列密码)。您可以通过比较他们的散列来判断“他们输入的内容”是否与“原始用户输入的密码”相匹配。

额外学分:

问:如果我有你的数据库，难道我不能像开膛手约翰一样，开始进行哈希，直到找到与你存储的哈希密码匹配的密码吗? (因为用户选择了简短的字典单词……这应该很容易)

答案:是的……是的，他们可以。

所以，你应该“盐”你的密码。 参见维基百科关于盐的文章

参见“如何使用salt散列数据”c#示例(已存档)

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

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

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

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

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.