我的理解是，盐并不需要保密，它只需要与任何中央标准不同即可，以便无法开发彩虹表或类似攻击来破解使用该算法的所有哈希值，因为盐可以破坏彩虹表。不过如果我有所错误，请指正。
在广泛使用的开源软件中，盐可能会被广为人知，这会使你面临攻击的风险，因为现在攻击者可以简单地攻击加过盐的哈希值，并创建包括盐数据的彩虹表。
我认为，有两种方法可以解决这个问题。第一种是在每个新版本的软件中更改盐，但这样做并不好，因为新版本的软件将不能再对旧密码哈希进行测试。
我想到的第二个解决方案是为每个密码存储一个盐；换句话说，每个密码都有一个不同的盐。缺点是必须以某种方式将盐与密码哈希关联起来，可能只需将其直接附在数据库中的密码旁边即可。也许使用用户名也可以（但这可能不行，因为用户名可能太短）。
我的问题是，这可行吗？将盐直接存储在其哈希密码旁边是否会有任何额外风险？在我看来，将盐存储在源代码中并没有什么不同，因此通过与密码一起存储盐并不会导致安全损失。
免责声明：我没有使用这个方案设计任何真实的安全系统。事实上，我从未设计过任何类型的密码系统。我只是让自己对安全问题保持模糊的了解。
这些库会生成一个每个密码独有的盐(salt)，它们使用适当的哈希算法(仅使用SHA1等密码哈希算法不足以确保安全；必须以使其难以反转的方式应用，例如重复1000次以上循环等.)。这就是像bcrypt这样的密码哈希函数的工作原理。密码存储库会正确地完成所有这些步骤; 它们通常会产生一个包含分隔符的字符串，以便确定所使用的哈希系统和工作因子。你只需要存储该字符串，而不需要知道更多信息。
你可以将salt以明文形式存储在表格中。
盐并不需要保密才能发挥作用。
它只需要是随机的即可。
盐通过使哈希值与同一数据库中或其他数据库中的相同密码无法比较以及使大型预先生成的常见密码哈希查找列表(如“彩虹表”)失效来加强密码。
因此，关键在于盐对于每个用户都是唯一的、随机的值，应该与密码一起存储。问题中概述的替代方法(使用用户名作为盐，对整个应用程序使用单个盐值)都会失败:
如果系统使用用户名或其他琐事作为盐，则密码可以与其他具有相同名称的用户在其他系统中进行比较(想象一下“管理员”或“root”用户帐户在不同系统中使用相同的密码的频率......)
如果系统为同一系统中的所有用户使用单个随机盐，则两个偶然使用相同密码的用户将具有相同的哈希值，猜测一个用户的密码将轻松地破解另一个用户的密码。
为每个密码生成唯一的盐是完全正常的。盐可以是现有材料（如UserID等）的产物，也可以是随机生成的。优点是，随着盐的强度增加，针对加密信息的攻击变得更加不切实际。
记住：每种加密算法都是可破解的。只有在破解保护（通过彩虹表或其他方式）比信息本身更有价值时，才能认为信息是“安全的”。
编辑：
假设您对密码学非常陌生，这里有一些提示：
你的第二个解决方案“每个密码存储一个盐”是正确的，通常被使用。
“盐”主要是为了使检测到两个用户有相同密码变得困难 - 因此您需要将已知的“盐”混合到密码中。在密码检查时需要获取盐。
因此，通常要么生成一个随机盐并将其与密码一起存储，要么使用其他标识符（用户ID、用户名等）作为盐。
在数据库中为所有密码使用单个盐值是有帮助的，但比为每个用户提供唯一盐值要不安全得多。
基本上：一个更长（以字节计）的密码+盐值会增加搜索空间，从而使使用“标准”彩虹表变得更加困难。
然而，如果所有条目都使用相同的盐，则可以创建一个彩虹表，专门用于攻击您的软件。如果您的用户群很大，那么有人可能会决定制作这样的彩虹表。
例如，如果您只是在每个密码后面添加“和大量盐”，然后进行哈希处理，攻击者可以构建一个由许多字符串生成的哈希值表，所有这些字符串都以“和大量盐”结尾。
因此，每个用户一个盐是最好的选择。但是，请记住，您还希望密码+盐值“长”一些。
如果您想使用主键，最好的方法可能是对主键进行哈希处理，而不是直接使用主键本身。因为如果用户43的密码+盐值看起来像“myPassword00000000043”，那么攻击者可以建立一个具有许多零的表格。创建时间戳和随机字符串可能更好，因为PKeys有时很容易被找到或猜测。实际上，您已经在用户表中存储了一个盐值：表的pkey。
您不必发明一个新列来存储盐。只需使用pkey即可。当然，这个想法假定您确实有与用户名关联的pkey。例如，用户名不是表中的pkey。
这是一个近似的重复 wtb: 密码哈希、盐和哈希值的存储
