可以用散列存储盐吗？

2018-06-07 00:16:58

我的理解是盐并不是要保密的，它只是打算与任何集中的标准不同，所以你不能开发彩虹表或类似的攻击来打破使用算法的所有哈希，因为盐会中断彩虹桌。我在这里的理解可能不完全正确，如果我错了，请纠正我。

在一个广泛使用的开源软件中，盐会广为人知，这会让你面对攻击，因为现在他们只需攻击你的哈希版本，并创建包含盐数据的彩虹表。

正如我所看到的，有两个选项可以解决这个问题。首先是用每一个新版本的软件改变盐份，但这并不好，因为软件的新版本将不再能够对旧密码哈希进行测试。

我想到的第二个解决方案是存储每个密码的salt; 换句话说，每个密码都会得到不同的盐分。缺点是salt必须以某种方式与密码哈希关联，可能只是将它们粘在数据库中的密码旁边。甚至可以使用用户名（可能不会，但可能用户名太短）。

我的问题是，这是可以接受的吗？将盐直接存储在密码中会带来额外的风险吗？在我看来，将salt存储在源代码中并没有什么不同，因此通过将salt与密码存储在一起没有任何安全性损失。

免责声明：我没有将此用于任何真实生活安全系统。事实上，我从来没有设计过任何类型的密码系统。我只是让自己隐晦地了解安全问题。

更新：使用一个合格的库，例如Python的passlib。

这些负责生成每个密码的salt，并且他们使用适当的散列算法（它不足以仅使用SHA1等加密散列;您必须以使其非常缓慢地反转例如循环1000或密码存储库可以正确执行所有操作;它们通常会生成一个分隔字符串，以便可以确定散列系统和使用的工作因子;您只需将字符串存储在需要知道这一点。

您可以将盐以'纯文本'存储在表格中。

盐不需要保密是有效的

它只需要是随机的。

盐通过使哈希值与相同或其他数据库中的相同密码无法比较，并且通过哈希查找（例如'彩虹表'）使大量预先生成的通用密码列表失效，从而加强密码。

所以盐的重要性是每个用户都是唯一的，并且是随密码一起存储的随机值; 问题中提出的替代方案（使用用户名作为盐，为整个应用程序使用单一盐值）各失败：

如果系统使用用户名或其他琐事，则可以将密码与其他系统中具有相同名称的其他用户进行比较（设想'管理员'或'root'用户帐户在不同系统中使用相同密码的频率。。）

如果系统对同一系统中的所有用户使用单个随机盐，那么偶然有相同密码的两个用户将具有相同的散列，并且猜测一个用户的密码会轻微地破坏另一个用户的密码。

试图保持盐的秘密是毫无意义的 ，因为整个盐渍和散列密码的实践仅仅是因为我们从经验中知道我们甚至不能保证我们的数据库具有完全可靠性的秘密。您最多可以单独储存盐，并希望能够访问数据库的攻击者无法找到它，但是如果您使用了良好的哈希算法和足够长的单个盐分，则无论哪种方式都应该是安全的。

盐的重点仅在于确保您无法摊销整个数据库乃至多个数据库的暴力破解成本。

首先是用每一个新版本的软件改变盐份，但这并不好，因为软件的新版本将不再能够对旧密码哈希进行测试。

我所看到的这种变化是在安装过程中产生一个随机盐（当然也包括不同版本），以便每个正在运行的实例都有一个不同的盐。当然，为每个密码添加不同的盐（也许除上述之外）还是更好。

根据定义，盐必须是随机的才能有效。不要使用任何确定性的值。这当然意味着您需要将它与散列密码一起存储在数据库中。传统上，UNIX系统甚至将哈希存储在与密码相同的字段中（salt是密码的固定长度前缀）。在数据库中，用户表中可以有其他列。

链接地址: http://www.djcxy.com/p/21581.html