hash - 如果有人可以访问加盐密钥，加盐密码是否毫无意义？关闭服务器盐渍？

Question

听说大型科技公司最近发生的所有黑客行为，我都想知道他们使用密码存储的方式。

我知道加盐+散列通常被认为是安全的，但是我见过的加盐示例将盐密钥硬编码到通常存储在同一台服务器上的密码脚本中。

那么，最初对用户密码进行哈希处理，将该哈希传递给“加盐服务器”或存储在场外的某个函数，然后将加盐哈希传回，这是一个合乎逻辑的解决方案吗？

我正在查看的方式是，如果入侵者可以访问包含存储密码的服务器或数据库，他们将无法立即访问 salt 密钥。

Answer 1

不——即使攻击者知道，盐仍然有效。

盐的想法是它使对大量用户的字典攻击变得更加困难。如果没有盐，攻击者会对字典中的所有单词进行哈希处理，并查看哪些与您用户的哈希密码匹配。使用 salt，他必须对字典中的每个单词进行多次散列（每个可能的散列值一次），以确保有一个适合每个用户的单词。

这种乘以几千（或可能几百万，取决于您使用的盐的大小）增加了散列所有值的时间，并且存储需要存储结果 - 这一点（您希望）它是不切实际的。

但是，我应该补充一点，在许多（大多数？）情况下，非常大的盐并不能真正增加很多安全性。问题是，如果您使用 24 位盐（约 1600 万个可能值）但只有几百个用户，攻击者可以提前收集您实际使用的盐值，然后执行他的字典攻击只针对那些值，而不是完整的约 1600 万个潜在值。简而言之，您的 24 位盐只增加了 8 位盐所能提供的一点点难度。

OTOH，对于大型服务器（谷歌、Facebook 等）来说，情况完全不同——大盐变得非常有益。

Answer 2

即使入侵者知道盐，加盐也是有用的。

如果密码未加盐，则可以使用广泛可用的预计算彩虹表来快速攻击您的密码。

如果您的密码表是加盐的，那么预先计算彩虹表就变得非常困难 - 为每种可能的盐创建彩虹表是不切实际的。

如果您对每个密码条目使用不同的随机盐，并将其以明文形式放在它旁边，那么入侵者就很难攻击您的密码，除非是暴力攻击。

Answer 3

加盐密码保护密码免受攻击者拥有散列密码列表的攻击。有一些常见的散列算法，黑客有表格可以让他们查找散列并检索密码。为此，黑客必须侵入密码存储并窃取哈希值。

如果密码被加盐，那么攻击者必须使用散列算法和加盐重新生成他们的散列表。根据散列算法，这可能需要一些时间。为了加快速度，黑客还使用最常见的密码和字典单词列表。盐的想法是减慢攻击者的速度。

为每个密码使用不同盐的最佳方法，使其长且随机，并且可以将盐存储在每个密码旁边。这确实减慢了攻击者的速度，因为他们必须为每个单独的密码、常见密码和字典单词的每种组合运行哈希表生成。这将使攻击者无法推断出强密码。

我读过一篇关于这方面的好文章，现在找不到了。但是谷歌搜索“密码盐”给出了一些很好的结果。看看这篇文章。

Answer 4

我想指出，您使用硬编码 salt 描述的方案实际上不是 salt，而是像钥匙或胡椒一样工作。盐和胡椒解决了不同的问题。

应该为每个密码随机生成一个盐，并且可以与散列密码一起存储在数据库中。它可以存储纯文本，即使攻击者知道它也可以实现其目的。

辣椒是一个密钥，将用于所有密码。它不会存储在数据库中，而是应存放在安全的地方。如果攻击者知道辣椒，它就会变得毫无用处。

我试图在一个小教程中解释这些差异，也许你想看看那里。

Answer 5

说得通。对于攻击者来说，似乎付出的努力多于价值（除非它是一个具有重要价值或重要性的网站）。

所有大小站点，重要与否，都应将密码哈希视为高度重要

只要每个散列都有自己的大随机盐，那么是的，它确实变得几乎不切实际，如果每个散列使用静态盐，您可以使用 Rainbow 表来清除使用密码 1 的用户散列

使用良好的散列算法也很重要（使用 MD5 或 SHA1 几乎就像使用明文和 mutli gpu 设置现在一样）使用 scrypt，如果不是，则使用 bcrypt，或者如果你必须使用 PBKDF2（你需要轮数非常高的）