将密码存储到sql的最佳方法

Question

在我目前的C＃windows应用程序中，密码以纯文本形式存储，这显然不太好。所以我只想知道加密密码并存储到SQL Server的最佳方法是什么。我已经读过使用hash + salt更好。但我觉得“EncryptByPassPhrase”，“DecryptByPassPhrase”在sql 2005中的新功能更好用，因为你正在处理SQL Server本身的所有内容，我想它使用三重DES。有人建议使用它是否好？

Answer 1

您是否需要访问原始密码，或者您只是尝试将输入的密码与数据库中的密码进行比较？

如果您需要访问原始密码，那么您将不得不使用加密算法而不是哈希算法。

如果您所做的只是在数据库中存储密码，以便以后可以根据已知的输入值进行检查，那么使用salt的哈希就可以了。

请记住，当客户端发送凭证并进行验证时，您不希望以明文形式发送密码！

Answer 2

哈希＆amp; salt是要走的路，因为它无法从中检索原始密码。如果你加密然后解密密码，明文密码是可以检索的，所以它不是最好的。

Answer 3

我同意将加密全部放在一处是有意义的。但是，如果将密钥与数据（c＃代码中的密钥，数据库中的数据）分开，则可以提高安全性。此外，Sql Server在加密时使用主密钥，这意味着如果您需要将数据恢复到新服务器，则无法恢复数据。

这一切都归结为密钥管理以及您希望如何做到这一点。

Answer 4

与大多数问题一样，最佳答案取决于您的情况。没有好的解决方案。

一些选项：

1. 保留密码为纯文本或可逆加密。使用SQLServer工具加密RDBMS级别的重要字段或使用类似的加密功能，并希望MS实施合理的密钥管理，并且密钥对于您的目的而言是相当安全的。在实践中，所有加密都是将大量小秘密存储到一个大秘密的存储中。它可能使问题更容易管理，但问题本身永远不会消失。

2. 使用散列算法或某种形式的crypt（）不可逆地“加密”密码。根据可用的攻击媒介，这种方法可能无法提供明确存储的安全性提升方式。

。在选择安全认证算法方面，使用散列密码会限制您的选择。使用这种方法，您可能最终会发送纯文本或其他材料，而这些材料在传输方面并不好（无论是否使用未绑定的加密），这可能是信任POV的重大风险。

。如果哈希被盗，则可以接受离线字典攻击，如果密码对攻击者有任何价值，则应该直接假设恢复部分密码。

。在某些情况下，密码哈希的知识可能与在系统访问方面知道密码一样糟糕。

Answer 5

如果您确定永远不会使用散列方案进行身份验证（如HTTP Digest Auth），则散列密码更安全。为了避免彩虹表攻击，请使用nonce（或salt）。我会使用HMAC-SHA1并使用nonce作为密钥。它们必须与密码一起存储。

否则，您必须存储加密密码，因为散列密码无法与涉及哈希的身份验证一起使用。对于加密，我有以下建议，

1. 不要将密钥存储在DB中，也不要对其进行硬编码。将其存储在其他安全位置，例如在Windows上使用DPAPI。
2. 确保您拥有密钥版本，以便您可以旋转密钥以符合某些标准。
3. 我不熟悉SQLServer中的加密。确保它有一个随机的初始向量。您可以通过两次加密相同的密码来检查这一点，它应该产生不同的密文。如果没有随机IV，请不要使用它，只需在应用程序中对其进行加密即可。