隐藏盐的哈希的必要性隐藏盐的哈希的必要性(The necessity of hiding the s

2019-05-08 23:52发布

站内文章 / 前端开发

42 0

狗以群分

女 | 书童

私信

在工作中，我们有盐的两个相互竞争的理论。该产品我在使用类似的用户名或电话号码，以盐哈希工作。本质的东西是不同的每个用户，但随时提供给我们。的其它产品随机地生成盐为每个用户和每个用户改变密码改变一次。该盐然后在数据库中加密。

我的问题是，如果第二种方法是真的有必要？我可以从纯理论的角度来看，它比第一种方法更安全，但大约从一个实用性点什么了解。眼下对用户进行身份验证，该盐必须是未加密和应用于登录信息。

经过考虑之后，我就没有看到这种方法真正的安全收益。从帐户更改盐帐户，仍然使得很难有人试图蛮力即使攻击者知道如何快速确定这是什么每个帐户的哈希算法。这是怎么回事假设密码足够强。（显然，找到正确的散列一组，他们都是两位数字的密码是不是发现这是8位数字密码的哈希值正确容易显著）。我是不正确的我的逻辑，或者是有，我失去了一些东西？

编辑：好了，这里就是为什么我认为这是真正的实际意义加密盐的原因。（还是让我知道如果我在正确的轨道上）。

对于下面的说明，我们假设密码总是8个字符，该盐为5，密码由小写字母（它只是使数学更容易）。

有每个条目不同的盐意味着我不能使用相同的彩虹表（实际上是在技术上我可以，如果我有足够的尺寸之一，但让我们忽略的时刻）。这才是真正的关键，从我了解的盐，因为破解每个帐户我不得不推倒重来，从而为每一个发言。现在，如果我知道如何正确的盐适用于密码生成散列，我会做到这一点，因为盐真的只是延长了散列短语的长度/复杂性。所以，我会削减我需要生成“知道”的可能组合的数目我有密码+盐从13 ^ 26〜8 ^ 26，因为我知道盐是什么。现在，可以更容易，但还是真的很难。

所以在加密盐。如果我知道盐是加密的，我不会试图和解密（假设我知道它的加密足够的水平），它第一。我会忽略它。而不是试图弄清楚如何解密，回到前面的例子，我只想生成一个包含所有键的13 ^ 26更大的彩虹表。不知道盐肯定会慢下来，但我不认为这会增加试图先破解盐加密的艰巨任务。这就是为什么我不认为这是值得的。思考？

这里是描述长的密码将如何撑起下蛮力攻击的链接： http://www.lockdown.co.uk/?pg=combi

Answer 1:

这里的答案是要问自己，你真正想从保护？如果有人访问你的数据库，那么他们可以访问加密的盐，他们可能有机会获得你的代码。所有他们可以解密加密的盐？如果是这样，则加密是几乎无用反正。盐还真是有做它，所以它是不可能形成的彩虹表，如果它被分成一气呵成破解整个密码数据库。从这个角度来看，只要每个盐是唯一的没有什么区别，蛮力攻击将与您的盐或为每个单独的密码加密的盐是必需的。

Answer 2:

隐藏盐是不必要的。

不同的盐应该用于每个哈希值。在实践中，这是很容易通过加密质量随机数发生器获得8个或多个字节来实现。

从我的以前的答案：

盐有助于阻止预先计算的字典攻击。
假设攻击者有可能的密码列表。他可以散列每把它比作他的受害人的密码的哈希值，看看是否匹配。如果列表很大，这可能需要很长的时间。他不想花那么多时间在他的下一个目标，于是他结果记录在“字典”，其中一个散列点，其对应的输入。如果密码列表是很长很长，他可以像使用彩虹表技术，以节省一些空间。
但是，假设他的下一个目标腌制他们的密码。即使攻击者知道盐是什么，他的预计算表是不值钱的，盐改变每个密码造成的哈希值。他要重新哈希所有的密码在他的名单中，附着目标的盐的输入。每一个不同的盐需要不同的字典，如果使用足量的盐，攻击者将没有足够的空间来存储字典对于他们所有。交易空间，以节省时间，不再是一种选择; 攻击者必须退回到他的名单散列每个密码，他想要攻击的每个目标。
所以，没有必要保持盐的秘密。确保攻击者不具有对应于该特定盐预先计算的字典就足够了。

思考这个多一点之后，我已经意识到愚弄自己，以为可以隐藏的盐是很危险的。这是更好的承担盐不能被隐藏，设计系统是安全的，尽管这一点。我提供一个更详细的解释在另一个答案。

Answer 3:

我的“盐”的理解是，它使破解更加困难，但它并没有试图隐藏额外的数据。如果您正试图通过使盐“秘密”，以获得更多的安全性，那么你真的只是想在你的加密密钥更多的比特。

Answer 4:

第二种方法是只是稍微更安全。盐防止字典攻击和彩虹表攻击用户。他们使它更难了一个雄心勃勃的攻击者危及整个系统，但仍然容易专注于您的系统的一个用户的攻击。如果您使用的是公开的，像电话号码的信息，攻击者意识到这一点 ，那么你已经保存他们在进攻的一个步骤。当然，这个问题是没有实际意义，如果攻击者得到你的整个数据库，盐和所有。

编辑：阅读重新过这个答案和一些评论后，它发生，我认为一些混乱可能是由于这样的事实，我只在比较的问题提出了两个非常特殊的情况：随机盐与非随机盐。 使用电话号码作为盐的问题是没有实际意义，如果攻击者得到你的整个数据库，使用盐在所有的问题不在这里。

Answer 5:

隐藏的盐不再是盐。这是辣椒。它有它的用途。这是从盐不同。

胡椒是添加到这使得散列到HMAC（基于哈希的消息验证代码）的密码+盐的秘密密钥。与访问散列输出和所述盐可以理论上蛮力黑客猜测这将生成的散列（并因此在文本框口令通过验证）的输入。通过添加辣椒，你增加一个加密的随机方式的问题空间，渲染问题顽固不严重的硬件。

有关辣椒的更多信息，请点击这里。

另请参阅HMAC 。

Answer 6:

下面是说明为什么它是坏到具有相同的盐为每个哈希一个简单的例子

考虑下面的表

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

壳体1时，盐1相同salt2如果HASH2替换HASH1然后用户2可以与用户1密码登录

案例2时，盐1不一样salt2如果HASH2替换HASH1然后用户2无法与用户的登录密码1。

Answer 7:

...像一个用户名或电话号码，以盐的哈希值。 ...
我的问题是，如果第二种方法是真的有必要？我可以从纯理论的角度理解，它比第一种方法更安全， 但是从一个实用性点什么呢？

从实用的角度来看，其盐是一个实现细节。如果你更改用户信息是如何收集和维护 - 两者的用户姓名和电话号码有时会改变，使用您的具体实例 - 那么你可能会损害您的安全。你想这样的朝外的变化有更深层次的安全问题？

是否停止，每个账户有一个电话号码需要涉及到一个完整的安全审查，以确保你没有打开这些帐户的安全性妥协的要求？

Answer 8:

有两种技术，具有不同的目标：

“盐”是用来做两个原本平等的加密密码不同。这样一来，入侵者不能有效地利用对加密密码的完整列表字典攻击。
（共享）“秘密”被散列的消息，使入侵者无法创建自己的消息，并让他们接受前加入。

Answer 9:

我倾向于隐藏的盐。我通过散列之前预先计算从1随机数为1024到密码的开始使用盐的10位。当比较密码的用户与哈希进入，我从循环1至1024，并尝试盐的每一个可能的值，直到我找到了比赛。这需要小于1/10秒。我得到了主意，做从PHP这样password_hash和password_verify 。在我的例子中，“成本”是10盐的10位。或者从另一个什么用户说，隐藏的“盐”被称为“辣椒”。的盐没有在数据库中加密。它的野蛮逼出来的。它将使必要的彩虹表扭转哈希1000倍。我使用SHA256，因为它的速度快，但仍然被认为是安全的。