散列和腌制密码字段

Question

我一直在折腾如何将密码存储在我的数据库中一段时间​​的问题。这是我第一次通过网络登录创建一个安全的应用程序，所以我想建立一些良好的实践。

首先，我读了散列和腌制。看来这个想法是......

1. 获得哈希算法
2. 获得来自用户的密码
3. 从用户添加“盐”以明文密码
4. 哈希整个密码（包括食盐）
5. 存储在数据库中的盐，这样就可以在以后检索（为PSWD验证）

这让我思考......如果黑客知道你的盐（b因为它存储在数据库的某处，可能是一个名为this_is_not_the_salt_ur_looking_for的列或者其他含义不明的列），他们可以重新生成密码字典并获得访问权限。

然后我有一个想法。如果您将盐存储在哈希密码字段中，该怎么办？所以按照步骤1-4（随机地产生的盐），则在步骤5中，插入在由密码口译类或服务某处已知的密码的盐：

xxxxxsaltvaluexxxxxxxxxxxxxxxx

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

答案：
没有理由不能这样做。正如Yahia所说，保护密码的其他方法包括双（或n）散列。在另一个说明中，BCrypt看起来像是一种几乎完全停止蛮力攻击的好方法，但我找不到C＃的可信库。
TTD

Answer 1

从安全的角度看是没有必要的，只要你只存储哈希密码（NEVER店的明文密码！）加上盐...攻击者是“允许”知道盐 - 你的安全必须设计的方式，即使有了盐的知识，它仍然是安全的。

盐是做什么的？

使用预先计算的“彩虹表”防止盐暴力攻击暴力攻击。
盐使攻击者的暴力成本（时间/内存）更加昂贵。
计算这样的表格非常昂贵，通常只有当它可以用于多个攻击/密码时才能完成。
如果您对所有密码使用相同的盐，攻击者可能会预先计算这样一个表，然后将您的密码暴力破解为明文...
只要您为每个密码生成一个新的（最好的密码强壮的）随机盐你想存储密码的密码没有问题。

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

如果您想进一步加强安全
你可以计算哈希几次了（哈希散列等等） - 这不会花费你很多，但它使蛮力攻击/计算“彩虹桌”更昂贵...请不要发明自己 - 有已证明的标准方法这样做，例如见http://en.wikipedia.org/wiki/PBKDF2和http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

Answer 2

你即将陷入兔子洞。 Use bcrypt。

Answer 3

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

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

读this