Security 盐生成和开源软件

据我所知，生成盐的最佳实践是使用存储在源代码中的一些神秘公式（甚至魔法常数）

我正在从事一个项目，我们计划将其作为开源发布，但问题是，源代码带来了生成盐的秘密公式，因此能够在我们的站点上运行彩虹表攻击

我想很多人在我面前都考虑过这个问题，我想知道最好的做法是什么。在我看来，如果代码是开源的，那么使用salt就毫无意义，因为salt可以很容易地进行反向工程

---

想法？

每个条目都必须是唯一的。即使攻击者能够计算出盐是什么，也会使彩虹表的创建变得极其困难。这是因为salt是在对密码进行散列之前添加到密码中的，因此它有效地添加到rainbow表必须包含的条目总数中，以获得密码字段的所有可能值的列表

由于关于盐渍哈希的问题经常出现，而且这个问题似乎有点混乱，所以我扩展了这个答案

什么是盐？ salt是一组固定长度的随机字节，添加到哈希算法的输入中

为什么腌制（或播种）是有用的？ 向散列中添加随机盐可以确保相同的密码将产生许多不同的散列。salt通常与哈希函数的结果一起存储在数据库中。 用盐腌制土豆条有很多好处：

Salting大大增加了预计算攻击的难度/成本（包括）

Salting确保相同的密码不会导致相同的哈希。 这将确保您无法确定两个用户是否具有相同的密码。更重要的是，您无法确定同一个人是否在不同的系统中使用相同的密码

salt增加了密码的复杂性，从而大大降低了和的有效性。（只有当盐与散列分开存储时才是如此）

适当的盐分会大大增加预计算攻击的存储需求，直到它们不再实用为止。（带有16位salt的8个字符大小写敏感字母数字密码，散列为128位值，在不减少彩虹的情况下使用）

盐没有必要保密。 salt不是密钥，而是通过使哈希函数特定于每个实例来“工作”。对于salt散列，没有一个散列函数，而是每个可能的salt值都有一个散列函数。这可以防止攻击者攻击N个哈希密码，攻击成本不到攻击一个密码的N倍。这就是盐的要点。
“秘密盐”不是盐，它被称为“密钥”，这意味着你不再计算散列，而是（MAC）。计算MAC是一项棘手的工作（比简单地将一个键和一个值组合到一个哈希函数中要复杂得多），这是一个完全不同的主题

盐必须是随机的。这确保了攻击者必须分别攻击每个咸哈希。
如果你依赖你的盐（或盐分算法）是秘密的，你就进入了（行不通）的领域。最有可能的是，你不会从盐的秘密中得到额外的安全；你只会有一种温暖模糊的安全感。因此，它不是让你的系统更安全，而是让你从现实中分心

那么，为什么盐必须是随机的呢？ 从技术上讲，这种盐应该是独一无二的。salt的要点是每个哈希密码都是不同的。这意味着全世界。由于没有按需分配独特盐的中央组织，我们必须依靠下一个最好的方法，即使用不可预测的随机生成器进行随机选择，最好是在足够大的盐空间内进行选择，以避免碰撞（两个实例使用相同的盐值）

试图从一些“可能是唯一的”数据（如用户ID）中得出salt是很有诱惑力的，但由于一些令人讨厌的细节，此类方案往往失败：

如果您使用例如用户ID，一些坏人攻击不同的系统，可能只是集中他们的资源，为用户ID 1到50创建预计算表。用户ID在系统范围内是唯一的，但在全球范围内不是唯一的

这同样适用于用户名：每个Unix系统有一个“根”，但世界上有许多根。“根”的彩虹表是值得努力的，因为它可以应用于数百万个系统。更糟糕的是，还有很多“bob”，而且很多人没有接受系统管理员培训：他们的密码可能很弱

唯一性也是暂时的。有时，用户会更改密码。对于每个新密码，必须选择一个新密码。否则，攻击者会获得旧密码的哈希值，而新密码的哈希值可能会试图同时攻击这两个密码

使用从加密安全、不可预测的PRNG获得的随机盐可能有点过分，但至少可以证明它可以保护您免受所有这些危害。这并不是要阻止攻击者知道一个单独的盐是什么，而是不要给他们一个大而胖的目标，这个目标将用于大量的潜在目标。随机选择使目标尽可能薄

总之： 使用随机、均匀分布的高熵盐。无论何时创建新密码或更改密码，请使用新的salt。将盐与散列密码一起存储。喜欢大的盐（至少10个字节，最好16个或更多）

salt不会将错误的密码转入salt

salt = sha_constructor(str(random.random())).hexdigest()[:5]
activation_key = sha_constructor(salt+user.username).hexdigest()
return self.create(user=user,
           activation_key=activation_key)