散列和腌制密码字段

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

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

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

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

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

xxxxxsaltvaluexxxxxxxxxxxxxxxx

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

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

来源

2011-08-18 David Colwell

我一直在想这个问题，。 –

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

盐是做什么的？

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

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

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

来源

2011-08-18 07:25:08 Yahia

您将在哪里存储盐 - 在数据库中，在软件中，在配置文件中...？你说攻击者可以知道盐，所以或许它存储在哪里并不重要，因为知道它是什么没有好处 - 或者是否存在？ – GeoffM

我会将它存储在数据库中...如果你想使攻击者更难（有点），你可以将盐和散列存储在不同的表中 – Yahia

了解，谢谢。 – GeoffM

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

来源

2011-08-18 07:18:38

感谢您的支持，但我一直在寻找隐藏盐的方法，这样暴力攻击就毫无结果，除非黑客知道密码的哪个索引开始，盐的长度和它的长度。 –

+1有趣关于bcrypt的信息。 –

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

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

读this

来源

2011-08-18 07:23:46 CloudyMarble

我意识到我的问题是误导。我已经哈希密码，我正在寻找一种隐藏盐的方法，将它存储在密码字段中的已知索引处。因此，一个16字符的密码与一个6字符的盐将长达22个字符 –

散列和腌制密码字段

回答

相关问题