Security 把盐藏起来做杂烩的必要性

在工作中，我们对盐有两种相互竞争的理论。我所研究的产品使用用户名或电话号码之类的东西对散列进行加密。本质上，对每个用户来说都是不同的，但我们可以随时使用。另一个产品为每个用户随机生成一个salt，并在用户每次更改密码时进行更改。然后在数据库中对盐进行加密

我的问题是，第二种方法是否真的有必要？我可以从纯理论的角度理解，它比第一种方法更安全，但是从实用的角度来看呢。现在要验证用户身份，salt必须是未加密的，并应用于登录信息

经过思考，我认为这种方法并没有带来真正的安全性收益。将salt从一个帐户更改到另一个帐户，仍然会使攻击者很难尝试强制执行哈希算法，即使攻击者知道如何快速确定每个帐户的salt。这是在假设密码足够强的情况下进行的。（显然，为一组密码（其中所有密码都是两位数字）查找正确的哈希要比查找8位密码的正确哈希容易得多）。我的逻辑是错误的，还是我遗漏了什么

编辑：好吧，这就是为什么我认为对盐进行加密是毫无意义的。（让我知道我是否在正确的轨道上）

对于下面的解释，我们假设密码总是8个字符，salt是5个字符，所有密码都由小写字母组成（这只是让数学更容易）

每个条目使用不同的salt意味着我不能使用相同的rainbow表（实际上，如果我有一个足够大的表，从技术上讲我可以使用，但我们暂时忽略它）。从我的理解来看，这是盐的真正关键，因为要破解每个账户，我必须为每个账户重新发明轮子。现在，如果我知道如何对密码应用正确的salt来生成散列，我会这样做，因为salt实际上只是扩展了散列短语的长度/复杂性。因此，我将把我需要生成的可能组合的数量从13^26减少到8^26，以“知道”我有密码+salt，因为我知道salt是什么。现在这使它更容易，但仍然很难

所以我们开始加密盐。如果我知道salt是加密的，我不会先尝试解密（假设我知道它有足够的加密级别）。我会忽略它。回到上一个示例，我不想试图找出如何解密它，而是生成一个更大的彩虹表，其中包含13^26的所有密钥。不知道盐肯定会让我慢下来，但我不认为这会增加试图首先破解盐加密的艰巨任务。这就是为什么我认为这不值得。想法

下面是一个链接，描述了密码在暴力攻击下可以保存多长时间：

---

我对“salt”的理解是，它使破解更加困难，但它并不试图隐藏额外的数据。如果您试图通过将salt设置为“机密”来获得更高的安全性，那么您真的只需要在加密密钥中添加更多的位。

有两种技术，目标不同：

• “salt”用于使两个本来相等的密码进行不同的加密。这样，入侵者就不能有效地对一整列加密密码使用字典攻击

• （共享的）“秘密”是在散列消息之前添加的，因此入侵者无法创建自己的消息并接受它们

---

这里的答案是问问自己，你真正想要保护的是什么？如果有人可以访问您的数据库，那么他们就可以访问加密的盐，而且他们可能也可以访问您的代码。他们能把加密的盐解密吗？如果是这样的话，那么加密无论如何都是毫无用处的。盐真的存在，所以它是不可能形成一个彩虹表，一次破解你的整个密码数据库，如果它被入侵。从这个角度来看，只要每个salt都是唯一的，没有区别，就需要对您的salt或每个密码的加密salt分别进行暴力攻击。
第二种方法只是稍微安全一些。SALT保护用户免受字典攻击和彩虹表攻击。它们使雄心勃勃的攻击者更难危害您的整个系统，但仍然容易受到针对您系统的一个用户的攻击。如果您使用公开的信息，如电话号码，而攻击者意识到了这一点，则您为他们的攻击节省了一步。当然，如果攻击者获取了您的整个数据库，那么这个问题是没有意义的

---

编辑：在重新阅读了这个答案和一些评论之后，我意识到一些困惑可能是因为我只是比较了问题中提出的两个非常具体的案例：随机盐和非随机盐。如果攻击者获取了整个数据库，那么使用电话号码作为salt的问题是没有意义的，而不是使用salt的问题。
下面是一个简单的示例，说明了为什么每个哈希使用相同的salt是不好的
考虑下表

UserId  UserName,   Password
     1  Fred       Hash1 =  Sha(Salt1+Password1)    
     2  Ted        Hash2 =  Sha(Salt2+Password2)    

当salt 1与salt 2相同时的情况1 如果用Hash1替换Hash2，则用户2可以使用用户1密码登录
当盐1与盐2不同时，情况2

---

如果用Hash1替换Hash2，则user2不能使用user1密码登录。
实际上，这取决于您试图保护数据的攻击类型
每道菜都有一种独特的食盐

Marianne2ae85fb5d