security - 盐、密码和安全

Question

我已经阅读了有关此问题的许多问题，但许多答案相互矛盾或我不明白。

您应该始终将密码存储为哈希值，而不是纯文本。但是您是否应该将盐(对于每个用户来说都是唯一的)存储在数据库中的散列密码+盐旁边。这对我来说似乎不太聪明，因为有人不能访问数据库，查找名为 Admin 或其他的帐户，然后从中计算出密码吗？

Answer 1

很多人都在说“阻止彩虹表”，但没有解释彩虹表的作用或为什么会阻止它们。

彩虹表是一种聪明的方法，可以预先计算大量哈希值并将它们存储在比实际需要的内存更少的内存中，并且您可以使用它们非常快速地反转哈希值。裸函数表，例如 hash = md5(password)和hash = sha1(password)很常见。

但是，它们可以为任何哈希函数生成，可以描述为 output = f(input) 。如果您对所有用户密码使用站点范围的盐，例如 hash = md5(salt+password) ，你可以构造一个函数 f , f(password) = md5(salt+password) 。因此，您可以为此函数生成彩虹表，这将花费很长时间，但可以让您非常快速地破解数据库中的每个密码。

如果每个密码的盐值不同，则无法生成可以破解数据库中所有密码的彩虹表。您可以为每个用户生成一个新的，但这毫无意义——天真的暴力破解不会慢。因此，为每个用户提供单独的盐可以阻止彩虹表攻击。

有多种方法可以实现此目的。流行的方式包括:

• 每个用户都有一个单独的盐，与他们的其他详细信息一起存储在数据库中:hash = hashfunction(salt + password)
• 全局盐和每个用户的一些独特值(value):hash = hashfunction(salt + password + user_id)例如
• 全局盐和每用户盐:hash = hashfunction(global_salt + user_salt + password)

拥有全局盐可能会增加破解密码的额外复杂性，因为它可能存储在数据库外部(例如，在代码中)，在数据库泄露时攻击者可能无法访问。从密码学角度来看，我认为它不会增加太多，但实际上它可能会减慢速度。

最后，回答您的实际问题:

将盐与用户数据一起存储不会削弱哈希值。哈希函数是单向的:给定密码的哈希值，即使是未加盐的密码，也很难找到该密码。加盐背后的动机不是为了使单个哈希更安全，而是为了使多个哈希的集合更安全。对于未加盐的哈希值集合，有多种攻击方式:

• 彩虹 table
• 对常用密码( 123 、 password 、 god )进行哈希处理并查看数据库中是否存在任何密码，然后危及这些帐户
• 在数据库中查找相同的哈希值，这意味着(可能)相同的密码