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