散列和加盐密码字段

Question

一段时间以来，我一直在纠结如何将密码存储在我的数据库中。这是我第一次使用 Web 登录创建一个安全的应用程序，所以我想建立一些好的做法。

首先，我阅读了散列和加盐。看来这个想法是……

1. 获取哈希算法
2. 从用户那里获取密码
3. 在用户的纯文本密码中添加“salt”
4. 散列整个密码（包括盐）
5. 将盐存储在数据库中，以便以后检索（用于验证 PSWD）

这让我开始思考……如果黑客知道你的 salt（因为它存储在数据库中的某个地方，可能是名为 this_is_not_the_salt_ur_looking_for 的列或同样模棱两可的东西），他们可以重新生成密码字典并获得访问权限.

然后我有了一个想法。如果您将盐存储在 内部 散列密码字段中会怎样。所以按照步骤 1-4（随机生成 salt），然后在步骤 5 中，将 salt 插入密码解释类或服务已知的密码中：

xxxxxx盐值xxxxxxxxxxxxxxxxxx

其中 x 是散列字符串值。任何人都可以看到这有什么问题吗？这完全没有必要吗？

答案：
没有理由不能这样做。正如 Yahia 所说，保护密码的其他方法包括双（或 n）散列。另一方面，BCrypt 看起来像是几乎完全阻止暴力攻击的好方法，但我找不到 C# 的受信任库

谢谢！
TTD

Answer 1

你快掉进兔子洞了。 Use bcrypt.

Answer 2

只需哈希密码并将哈希值保存在您的数据库中，一旦用户再次登录，您计算他输入的密码的哈希值并将其与保存在您的数据库中的密码进行比较，您不需要知道密码.一个黑客如果得到了哈希值，就无法得到密码。

如果您使用 Salting，您将通过保存 Salt 及其所属的 Hash 值来提高安全性，最终值是使用生成的 salt 结合计算哈希值的密码来计算的，密码不会保存在您的数据库但只有计算出的哈希值，这意味着一个evtl。黑客不能做任何只有哈希值和盐的事情。

阅读this

Answer 3

从安全的角度来看，只要您只存储散列密码（绝不存储明文密码！）加上盐......攻击者是“允许的” 要知道盐 - 你的安全性必须设计成即使知道盐它仍然是安全的。

盐有什么作用？

Salt 使用预先计算的“彩虹表”帮助防御暴力攻击。
Salt 让攻击者的暴力破解成本更高（在时间/内存方面）。
计算这样的表很昂贵，并且通常仅在它可用于多个攻击/密码时才进行。
如果您对所有密码使用相同的盐，攻击者可以预先计算这样一个表，然后将您的密码强制转换为明文...
只要您为要存储哈希值的每个密码生成一个新的（最好的加密强度）随机盐就没有问题。

至于你“伪装”盐的想法
这更像是应该避免的“默默无闻的安全”。
虽然在这种情况下我看不到任何积极或消极的影响。

如果您想进一步加强安全性
您可以多次计算哈希（哈希哈希等） - 这不会花费您太多，但它会使暴力攻击/计算“彩虹表”更加昂贵......请不要发明自己- 有经过验证的标准方法可以做到这一点，例如参见 http://en.wikipedia.org/wiki/PBKDF2 和 http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx