对密码字段进行散列和腌制

本文关键字：密码 字段 | 更新日期: 2023-09-27 18:05:51

我一直在考虑如何在数据库中存储密码的问题，现在已经有一段时间了。这是我第一次使用web登录来制作一个安全的应用程序，所以我想建立一些好的做法。

首先，我阅读了哈希和盐。这个想法似乎是……

  1. 获取哈希算法
  2. 从用户
    3. 获取密码
  3. 在用户
    4. 的明文密码中添加'salt'
  4. 散列整个密码(包括salt)
  5. 将盐存储在数据库中，以便稍后检索(用于验证PSWD)

这让我想到…如果黑客知道您的密码(因为它存储在数据库的某个地方，可能是一个名为this_is_not_the_salt_ur_looking_for的列或其他同样模棱两可的东西)，他们可以重新生成密码字典并获得访问权限。

然后我有了一个主意。如果将salt 存储在散列密码字段中会怎么样?因此，遵循步骤1-4(随机生成盐)，然后在步骤5中，将盐插入密码解释类或服务已知的密码中:

xxxxxsaltvaluexxxxxxxxxxxxxxxx

，其中x是散列字符串值。有人能看出这有什么问题吗?是不是完全没有必要?

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

谢谢!
运输大亨

对密码字段进行散列和腌制

从安全的角度来看，这是没有必要的，只要你只存储哈希密码(NEVER存储明文密码!)加上盐…攻击者"允许"知道盐——您的安全性必须被设计成即使知道盐也是安全的。

盐有什么作用

Salt通过预先计算的"彩虹表"帮助防御暴力攻击。
对于攻击者来说，Salt使得暴力破解的成本(在时间/内存方面)大大增加。
计算这样的表是昂贵的，通常只在它可以用于多个攻击/密码时才进行。
如果你对所有密码使用相同的盐，攻击者可以预先计算出这样一个表，然后暴力破解你的密码成明文…
只要你为你想要存储哈希的每个密码生成一个新的(最好的加密强)随机盐，就没有问题。

关于你"伪装"盐的想法
这是更多应该避免的"模糊安全"。
尽管在这种情况下，我没有看到任何积极或消极的影响。

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

你马上就要掉进兔子洞了。使用bcrypt。

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

如果您使用Salt，您将通过保存Salt和它所属的哈希值来提高安全性，最终值是使用生成的Salt和计算哈希值的密码来计算的，密码不会保存在您的数据库中，而只保存计算的哈希值，这意味着evtl。只有哈希值和盐，黑客无法做任何事情。

读这本

相关文章：