我正在开发一个必须具有身份验证（用户名和密码）的项目
它还连接到数据库，所以我想我会在那里存储用户名和密码 . 但是，将密码仅仅放在数据库中的表中的文本字段似乎不是一个好主意 .
我正在使用C＃并连接到2008 Express服务器 . 任何人都可以（尽可能多的例子）建议存储此类数据的最佳方法是什么？
P.S我愿意这样的想法，如果可以提供一个很好的理由，这些信息不会存储在数据库中
最好的安全做法是根本不存储密码（甚至不加密），而是存储加密密码的盐渍哈希（每个密码具有唯一的盐） .
这样（实际上）检索明文密码是不可能的 .
你是正确的，将密码存储在纯文本字段中是一个可怕的想法 . 但是，就位置而言，对于大多数情况，你可以想到任何反例）在数据库中存储密码的表示是正确的 . 通过表示我的意思是你想要使用salt（对每个用户应该是不同的）和一个安全的单向算法来存储密码并存储它，丢弃原始密码 . 然后，当您要验证密码时，您将对该值进行散列（使用相同的散列算法和salt）并将其与数据库中的散列值进行比较 .
所以，虽然你正在思考这个问题是一件好事，这是一个很好的问题，但这实际上是这些问题的重复（至少）：
How to best store user information and user login and password
Best practices for storing database passwords
Salting Your Password: Best Practices?
Is it ever ok to store password in plain text in a php variable or php constant?
为了进一步澄清盐渍位，只需散列密码并存储的危险就是如果侵入者获得了数据库，他们仍然可以使用所谓的rainbow tables来密码（在至少那些出现在彩虹表中的人） . 为了解决这个问题，开发人员在密码中添加了一个salt密码，这些密码在正确完成后会使彩虹攻击变得不可行 . 请注意，一个常见的误解是只需在所有密码中添加相同的唯一和长字符串;虽然这并不可怕，但最好为每个密码添加独特的盐 . Read this for more.
在您的场景中，您可以查看asp.net成员资格，最好将用户密码作为散列字符串存储在数据库中 . 您可以通过将散列的传入密码与存储在数据库中的密码进行比较来验证用户身份 .
一切都是为此目的而建的，请查看asp.net membership
作为密钥加强的盐渍哈希，使用sha-512等安全算法 .
我可能会略微偏离主题，因为你提到了用户名和密码的需要，而我对这个问题的理解并不是最好的，但OpenID是值得考虑的吗？
如果您使用OpenID，那么如果我正确理解了该技术并且用户可以使用他们已有的凭据，那么您根本不会最终存储任何凭据，从而无需创建特定于您的应用程序的新身份 .
如果相关的应用程序纯粹是供内部使用，则可能不合适
RPX提供了一种将OpenID支持集成到应用程序中的简便方法 .
Background 你永远......真的......需要知道用户的密码 . 您只想验证传入用户是否知道帐户的密码 .
Hash It: 通过强哈希函数存储用户密码哈希（单向加密） . 搜索"c# encrypt passwords"会给出大量示例 .
有关哈希函数产生的概念，请参阅online SHA1 hash creator（但不要使用SHA1作为哈希函数，使用更强大的东西，如SHA256） .
现在，散列密码意味着您（和数据库小偷）不应该将该散列反转回原始密码 .
How to use it: 但是，你说，我如何使用存储在数据库中的这个混合密码？
当用户登录时，他们会向您提供用户名和密码（在其原始文本中）您只需使用相同的哈希代码来哈希该输入的密码以获取存储的版本 .
因此，比较两个散列密码（用户名的数据库哈希和键入的密码和哈希密码） . 您可以通过比较它们的哈希值来判断“他们键入的内容”是否与“原始用户为其密码输入的内容”相匹配 .
Extra credit:
问题：如果我有你的数据库，那么我不能只是像开膛手约翰这样的破解者开始制作哈希值，直到找到你存储的哈希密码匹配？ （因为用户选择简短的字典单词......应该很容易）
答：是的......是的，他们可以 .
所以，你应该'salt'你的密码 . 见Wikipedia article on salt
见"How to hash data with salt" C# example
我完全建议阅读文章Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes [dead link，copy at the Internet Archive]和How To Safely Store A Password .
包括我在内的很多编码员都认为他们理解安全和散列 . 可悲的是，我们大多数人都没有 .
如果您不需要能够反转哈希，我会将MD5 / SHA1作为密码 . 当用户登录时，您只需加密给定的密码并将其与哈希值进行比较 . 在这种情况下，哈希冲突几乎是不可能的，除非有人获得对数据库的访问权并且看到他们已经发生冲突的哈希 .
8 回答
最好的安全做法是根本不存储密码（甚至不加密），而是存储加密密码的盐渍哈希（每个密码具有唯一的盐） .
这样（实际上）检索明文密码是不可能的 .
你是正确的，将密码存储在纯文本字段中是一个可怕的想法 . 但是，就位置而言，对于大多数情况，你可以想到任何反例）在数据库中存储密码的表示是正确的 . 通过表示我的意思是你想要使用salt（对每个用户应该是不同的）和一个安全的单向算法来存储密码并存储它，丢弃原始密码 . 然后，当您要验证密码时，您将对该值进行散列（使用相同的散列算法和salt）并将其与数据库中的散列值进行比较 .
所以，虽然你正在思考这个问题是一件好事，这是一个很好的问题，但这实际上是这些问题的重复（至少）：
How to best store user information and user login and password
Best practices for storing database passwords
Salting Your Password: Best Practices?
Is it ever ok to store password in plain text in a php variable or php constant?
为了进一步澄清盐渍位，只需散列密码并存储的危险就是如果侵入者获得了数据库，他们仍然可以使用所谓的rainbow tables来密码（在至少那些出现在彩虹表中的人） . 为了解决这个问题，开发人员在密码中添加了一个salt密码，这些密码在正确完成后会使彩虹攻击变得不可行 . 请注意，一个常见的误解是只需在所有密码中添加相同的唯一和长字符串;虽然这并不可怕，但最好为每个密码添加独特的盐 . Read this for more.
在您的场景中，您可以查看asp.net成员资格，最好将用户密码作为散列字符串存储在数据库中 . 您可以通过将散列的传入密码与存储在数据库中的密码进行比较来验证用户身份 .
一切都是为此目的而建的，请查看asp.net membership
作为密钥加强的盐渍哈希，使用sha-512等安全算法 .
我可能会略微偏离主题，因为你提到了用户名和密码的需要，而我对这个问题的理解并不是最好的，但OpenID是值得考虑的吗？
如果您使用OpenID，那么如果我正确理解了该技术并且用户可以使用他们已有的凭据，那么您根本不会最终存储任何凭据，从而无需创建特定于您的应用程序的新身份 .
如果相关的应用程序纯粹是供内部使用，则可能不合适
RPX提供了一种将OpenID支持集成到应用程序中的简便方法 .
Background 你永远......真的......需要知道用户的密码 . 您只想验证传入用户是否知道帐户的密码 .
Hash It: 通过强哈希函数存储用户密码哈希（单向加密） . 搜索"c# encrypt passwords"会给出大量示例 .
有关哈希函数产生的概念，请参阅online SHA1 hash creator（但不要使用SHA1作为哈希函数，使用更强大的东西，如SHA256） .
现在，散列密码意味着您（和数据库小偷）不应该将该散列反转回原始密码 .
How to use it: 但是，你说，我如何使用存储在数据库中的这个混合密码？
当用户登录时，他们会向您提供用户名和密码（在其原始文本中）您只需使用相同的哈希代码来哈希该输入的密码以获取存储的版本 .
因此，比较两个散列密码（用户名的数据库哈希和键入的密码和哈希密码） . 您可以通过比较它们的哈希值来判断“他们键入的内容”是否与“原始用户为其密码输入的内容”相匹配 .
Extra credit:
问题：如果我有你的数据库，那么我不能只是像开膛手约翰这样的破解者开始制作哈希值，直到找到你存储的哈希密码匹配？ （因为用户选择简短的字典单词......应该很容易）
答：是的......是的，他们可以 .
所以，你应该'salt'你的密码 . 见Wikipedia article on salt
见"How to hash data with salt" C# example
我完全建议阅读文章Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes [dead link，copy at the Internet Archive]和How To Safely Store A Password .
包括我在内的很多编码员都认为他们理解安全和散列 . 可悲的是，我们大多数人都没有 .
如果您不需要能够反转哈希，我会将MD5 / SHA1作为密码 . 当用户登录时，您只需加密给定的密码并将其与哈希值进行比较 . 在这种情况下，哈希冲突几乎是不可能的，除非有人获得对数据库的访问权并且看到他们已经发生冲突的哈希 .