散列和腌制密码字段

时间:2011-08-18 07:16:47

标签: c# database passwords hash

我一直在讨论如何将密码存储在我的数据库中一段时间​​的问题。这是我第一次使用Web登录创建安全的应用程序,所以我想设置一些好的做法。

首先,我读了哈希和盐腌。似乎这个想法是......

  1. 获取散列算法
  2. 从用户那里获取密码
  3. 将'salt'添加到用户的纯文本密码
  4. 哈希整个密码(包括盐)
  5. 将盐存储在数据库中,以便以后可以检索它(用于验证PSWD)
  6. 这让我思考...如果黑客知道你的盐(因为它存储在某个地方的数据库中,可能是一个名为this_is_not_the_salt_ur_looking_for的列或同样模棱两可的列),他们可以重新生成密码字典和获得访问权限

    然后我有了一个主意。如果您将盐存储在散列密码字段中,该怎么办?所以按照步骤1-4(随机生成盐),然后在步骤5中,将盐插入密码解释类或服务所知的密码中:

    xxxxxsaltvaluexxxxxxxxxxxxxxxx

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

    答案:
    没有理由不这样做。正如Yahia所述,其他保护密码的方法包括双(或n)散列。另一方面,BCrypt几乎完全是一种阻止暴力攻击的好方法,但是我找不到一个可信赖的C#库

    谢谢!
    TTD

3 个答案:

答案 0 :(得分:6)

从安全的角度来看,只要你只存储哈希密码(从不存储明文密码!)加上盐......攻击者“允许”< / em>要知道盐 - 你的安全必须以一种方式设计,即使知道盐,它仍然是安全的。

盐有什么作用?

Salt使用预先计算的“彩虹表”帮助抵御暴力攻击 对于攻击者来说,盐使蛮力更加昂贵(在时间/记忆方面) 计算这样一个表是很昂贵的,通常只有当它可以用于多个攻击/密码时才会这样做 如果您对所有密码使用相同的盐,则攻击者可以预先计算此类表格,然后将您的密码暴力强制为明文...
只要你为每个密码生成一个新的(最好的cryptogrpahically强)随机盐你想存储哈希就没有问题。

关于“掩饰”盐的想法
这更多是“默默无闻的安全”应该避免的 虽然在这种情况下我既没有看到任何积极的或消极的影响。

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

答案 1 :(得分:3)

你将陷入一个兔子洞。 Use bcrypt

答案 2 :(得分:0)

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

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

阅读this