我的理解是，盐并非是秘密的，它仅仅是打算从任何集中的标准不同，所以，你不能开发一个彩虹表或类似的攻击，以破坏使用算法所有哈希，因为盐休息彩虹表。 在这里，我的理解可能不完全正确的，所以纠正我，如果我错了。
在开源软件广泛使用的片，盐就会广为人知，这可能让你被攻击，因为现在他们可以直接攻击你的哈希的盐渍版本，并创建彩虹表，其中包括盐的数据。
在我看来，有两个办法来处理这个。 首先是与软件的每个新版本改变了盐，但是这是没有好，因为该软件的新版本将不再能够测试旧密码哈希值。
我想的第二解决方案是具有每存储的密码盐; 换句话说，每个密码得到一个不同的盐。 缺点是，盐必须可能只是通过坚持他们旁边在数据库中的密码以某种方式的密码哈希值相关。 这可能是甚至好于使用的用户名（它可能没有，但是，很可能用户名是太短）。
我的问题是，这是可以接受的？ 有没有直接与它哈希密码存储盐相关的任何额外的风险？ 在我看来，该存储盐在源代码中并没有什么不同，所以有通过存储盐与密码没有安全损失。
免责声明：我不使用这个任何现实生活保障制度。 事实上，我从来没有设计任何类型的密码系统。 我只是保持自己的教育隐约安全问题。
更新 ：使用一个称职的库如passlib为Python。
这些照顾生成每个密码盐，他们使用合适的散列算法（它不够的，只是使用的加密哈希如SHA1，你必须在一定程度上使得扭转它很慢，应用它如循环1000多次在这等等，这是密码散列函数怎么样bcrypt工作密码存储库做这一切正常;他们通常会产生被分隔，使他们能够确定哈希系统和使用工作因子的字符串;你只是存储的字符串，不需要知道这一点。
您可以将盐存储在表中“纯文本”。
盐并不需要是秘密是有效的
它只是需要是随机的。
所述盐通过使哈希值无法比拟的在相同或其他数据库中的相同的密码，无效通用密码的大预生成的列表，以哈希查询（例如，“彩虹表”）加强的口令。
因此，它是至关重要的盐是每个用户唯一的，存储的密码一些随机值; 在问题中概述的替代方案（使用用户名作为盐，使用为整个应用程序的单个盐值），每个失败：
如果系统使用的用户名或其他琐事，那么密码可以与其他用户与其他系统（想象中的“管理员”或“根”用户帐户如何经常使用在不同的系统相同的密码相同的名称.. 。）
如果系统使用在同一系统中所有用户的单一随机盐，然后两个用户谁碰巧有相同的密码将具有相同的哈希值，并猜测一个用户的密码将平凡损害其他。
试图保持盐的秘密是没有意义的 ，因为腌制和散列密码的整个实践中只存在，因为我们从经验中知道，我们甚至不能让我们的数据库，秘密与完整的可靠性。 最多可以单独存储盐和希望谁得到您的DB访问攻击者没有找到，但如果你使用一个好的哈希算法和足够长的各种盐，你应该是安全的两种方式。
盐的点完全是为了确保你不能在整个数据库，甚至多个数据库摊销蛮力攻击的成本。
首先是与软件的每个新版本改变了盐，但是这是没有好，因为该软件的新版本将不再能够测试旧密码哈希值。
这是我所看到的一个变化是在安装期间生成一个随机的盐（当然还有保持这种跨版本），使每个运行实例都有不同的一个。 当然，具有不同的盐为每个密码（或许除了以上）是更好的。
该盐 ，顾名思义，必须是随机的是有效的。 不要使用这个任意的确定值。 当然，这意味着你需要将其存储在数据库中与哈希密码一起。 UNIX系统传统上，即使散列存储在同一字段作为密码（所述盐是密码的一个固定长度的前缀）。 在数据库中，你可以在用户表中附加列。
这是完全正常的生成每个密码的唯一盐。 该盐可以是现有材料的产物（如用户ID，ET-人）或随机生成的。 的优点在于，针对加密信息的攻击变得作为盐的强度变得更不实用 。
记住：每一个加密算法是可以破解的。 信息仅可认为是“安全”，如果破解保护（通过彩虹表或其他方式）更昂贵比信息是值得的。
编辑：
假设你是很新的密码系统，这里有几个技巧：
你的第二个解决方案“中每个存储的密码盐”是正确的，通常使用。
“盐”主要是有使两个用户具有相同的密码难以察觉 - 所以你混的一个已知的“盐”进入密码。 盐必须在密码检查时间gettable。
所以通常是你生成一个随机的盐，并将其与存储的密码OR使用一些其他的识别符（用户ID，用户名等）作为盐。
使用单一的盐为数据库中的所有密码是有帮助的，但不是为每个用户分配一个唯一的盐安全得多 。
基本上：一个较长的（按字节）密码+盐增大了搜索空间，并因此使得它更难使用“股票标”彩虹表。
但是，如果用于所有条目相同的盐，则有可能创建一个彩虹表专门攻击你的软件。 如果你的用户群较大，则有人可能会决定做出这样的彩虹表。
例如，如果您只需添加“和大量的盐”来散列之前每个密码年底，攻击者可以构造通过大量串产生的哈希值的表，所有那些结尾的字符串“和大量的盐” 。
出于这个原因，每个用户的盐是最好的一段路要走。 但是，请记住，您还需要密码+盐是“长”。
如果你想使用的主键，它可能是一个好主意，采取主键的哈希值 ，而不是使用主键本身，因为如果密码+盐用户43看起来像“myPassword00000000043”，那么攻击者可以建立一个与假设表中有很多在中间零的。 创建时间戳和随机字符串可能是更好的选择，虽然，作为PKeys有时可以很容易地找到或猜测。
注：我不是一个真正的加密专家，在实际系统中不使用这个建议。
实际上，你已经存储在用户表中的盐值：表的p键。
你不必去创造一个新的列存储的盐。 只需使用p键。 当然，这个想法假定你有一个用户名关联的p键。 例如，用户名是不是在表中的p键。
这是一个邻近DUP WTB： 密码散列，盐和存储散列值的
