听说了大型科技公司最近发生的所有黑客攻击，这让我想知道他们如何使用密码存储。
我知道加盐 + 散列通常被认为是安全的，但我见过的加盐示例将盐密钥硬编码到通常存储在同一服务器上的密码脚本中。
那么，首先对用户密码进行哈希处理，然后将该哈希值传递给“加盐服务器”或存储在场外的某个函数，然后将加盐哈希值传回，这是一个合乎逻辑的解决方案吗？
我的看法是，如果入侵者获得对包含存储密码的服务器或数据库的访问权限，他们将无法立即访问 salt key。
【问题讨论】：
有道理。对于攻击者来说，似乎付出的努力多于价值（除非它是一个具有重要价值或重要性的网站）。
所有网站大小，重要与否，都应将密码哈希视为高度重要
只要每个散列都有自己的大随机盐，那么它确实变得几乎不切实际，如果每个散列使用静态盐，您可以使用 Rainbow 表来清除使用密码 1 的用户散列
使用良好的散列算法也很重要（使用 MD5 或 SHA1 几乎就像使用明文和 mutli gpu 设置这些天）使用 scrypt 如果不是然后 bcrypt 或者如果你必须使用 PBKDF2 然后（你需要回合非常高）
【讨论】：
我想指出，您使用硬编码盐描述的方案实际上不是盐，而是像钥匙或胡椒一样工作。盐和胡椒解决了不同的问题。
应该为每个密码随机生成一个salt，并且可以与散列密码一起存储在数据库中。它可以存储纯文本，即使攻击者知道它也能实现其目的。
pepper 是一个密钥，将用于所有密码。它不会存储在数据库中，而是应存放在安全的地方。如果攻击者知道辣椒，它就会变得毫无用处。
我试图在一个小的tutorial 中解释不同之处，也许你想看看那里。
【讨论】：
加盐密码可保护密码免受攻击者拥有哈希密码列表的攻击。有一些常见的散列算法，黑客有表格可以让他们查找散列并检索密码。为此，黑客必须侵入密码存储并窃取哈希值。
如果密码被加盐，那么攻击者必须使用散列算法和加盐重新生成他们的散列表。根据散列算法，这可能需要一些时间。为了加快速度，黑客还使用最常见的密码和字典单词列表。盐的想法是减慢攻击者的速度。
为每个密码使用不同盐的最佳方法，使其长且随机，并且可以将盐存储在每个密码旁边。这确实减慢了攻击者的速度，因为他们必须为每个单独的密码、常见密码和字典单词的每种组合运行哈希表生成。这将使攻击者无法推断出强密码。
我读过一篇关于这方面的好文章，但现在找不到了。但是谷歌搜索“密码盐”给出了一些很好的结果。看看this article。
【讨论】：
即使入侵者知道盐，加盐也是有用的。
如果密码未加盐，则可以使用广泛可用的预计算 rainbow tables 来快速攻击您的密码。
如果您的密码表被加盐，那么预先计算彩虹表就变得非常困难 - 为每种可能的盐创建彩虹表是不切实际的。
如果您对每个密码条目使用不同的随机盐，并将其以明文形式放在旁边，那么入侵者就很难攻击您的密码，除非是暴力破解。
【讨论】：
不——即使攻击者知道，盐仍然有效。
盐的想法是它使对大量用户的字典攻击变得更加困难。如果没有盐，攻击者会对字典中的所有单词进行哈希处理，并查看哪些与您用户的哈希密码匹配。使用 salt，他必须多次对字典中的每个单词进行哈希处理（每个可能的哈希值一次），以确保有一个适合每个用户。
这种乘以几千（或可能是几百万，取决于您使用的盐的大小）会增加散列所有值的时间，并且存储需要存储结果 - （您希望）它是不切实际。
然而，我应该补充一点，在许多（大多数？）情况下，非常大的盐并不能真正增加很多安全性。问题是，如果您使用 24 位盐（约 1600 万个可能值）但只有几百个用户，攻击者可以提前收集您实际使用的盐值，然后执行他的字典攻击只针对那些值，而不是完整的约 1600 万个潜在值。简而言之，您的 24 位 salt 仅比 ~8 位 salt 增加了一点点难度。
OTOH，对于大型服务器（Google、Facebook 等），情况完全不同——大盐变得非常有益。
【讨论】：