我对整个密码哈希业务还很陌生，所以我可能会遗漏一些明显的东西。
我正在查看 bcrypt 算法，特别是BCrypt.Net，我想知道为每个用户计算唯一的盐而不是随机盐是否更安全？
目前，盐和工作量（# 轮）暴露在散列密码字符串中。（$2a$ + 2 位数的工作量 + $ + 22 个字符的盐 + 31 个字符的散列密码）我们不是通过给潜在的黑客提供盐来帮助他们（例如，如果他们想暴力破解管理员的密码）？
我们不能通过散列（例如使用 MD5 或 SHA1）他们的电子邮件地址来计算每个用户的盐吗？
如果我们只保存 bcrypt 散列密码的最后 31 个字符，而忽略标识符、工作量（如果我们保持不变），最重要的是盐。这不会让试图找到密码的人更难吗？
（从好的方面来说，我们将为大型用户数据库获得一些数据库空间，因为密码只有 31 个字符而不是 60 个字符）
我可能遗漏了一些明显的东西，因为我不能成为第一个做出这种反思的人。
马克
您不想为给定用户使用固定盐，因为它可能导致盐重用，这是不好的（这是盐的大罪，因为盐的整个想法是不被重用的；它们没有其他功能） . 实际上，由于以下两个原因，盐重用可能会发生：
如果用户更改密码，新密码将使用与旧密码相同的盐。这很糟糕，因为旧密码仍然有价值（由于用户重复使用密码，旧密码可以是用户下个月设置的密码；也可以是同一用户在另一个站点的密码），并且重复使用将允许攻击者以一次暴力破解为代价攻击旧密码和新密码。
如果盐是从用户名派生的，那么在不同服务器上的另一个服务器软件实例可能会以相同的盐结束，因为“管理员”往往总是被称为“管理员”。攻击者可以为“管理员”预先计算一个大表（例如彩虹表），适用于许多站点（这将使建表值得付出努力）。
我通常通过说明盐必须在时间上是唯一的（不重用旧的盐值）和全球性的（在任何地方都不能重用盐，即使在不同的服务器上）来总结这一点。这种唯一性很难获得，但仍然有一种相当简单的方法，即随机生成足够大的盐（例如，bcrypt 使用的 128 位盐）。
总结：不随机生成 bcrypt 盐不会更安全；充其量，这将是同样安全的，但更可能的是，不太安全。
使用盐的原因是为了防止使用预先计算的彩虹表进行攻击。攻击者必须为每个密码建立一个彩虹表，这是没有意义的（在找到匹配之前，暴力破解更容易）。所以盐的工作已经完成，即使它在哈希值中是可见的明文。
如果您想在计算中添加一个秘密，那么您可以添加一个额外的辣椒。与盐相比，胡椒不会存储在数据库中。这将有助于抵御字典攻击，只要攻击者只能访问您的数据（例如 SQL 注入）而不能访问您的代码。
我不会把盐和胡椒混在一起，因为它们有不同的用途。要回答您的问题，请使用随机盐，如果您想添加隐藏的东西，请添加胡椒粉。
bcrypt 中的盐是 128 位长并且是随机生成的，因此您需要 2^127 个用户才能有 50% 的碰撞机会。让我们换个角度来看：地球上的每个人都可以为他们身体中的每个原子创建一个用户帐户，而我们仍然只有大约 1/3。
使用随机盐。涉及计算盐的解决方案引入了一些微妙的问题，最终可能导致麻烦和灾难之间的差异。