我正在开发我的第一个需要登录的web应用程序，并且它已经到了我必须决定如何存储密码的时候了。我一直在大量阅读正确的方式来散列密码和添加盐。我想到，推荐的大多数方法都依赖于存储在数据库中的密码散列信息的一些变化，无论是使用全部或部分用户名作为盐或其他随机值的一些变化。用密码提供密码
相反，我想使用用户自己的密码作为盐的密码。使用一种算法来混合密码并以某种方式将其添加到自身中作为盐。当然，如果攻击者可以访问存储的哈希和算法的源代码，那么这将会受到影响，但是在这种情况下任何盐都会受到影响。我的应用程序实际上可能不需要这种安全级别，但这只是我在阅读时开始考虑的事情。
我只是想从一些更有经验的开发人员那里得到一些反馈。任何反馈意见。
“我的应用程序确实可能并不需要这种级别的安全性” - 直到那个时间点就被黑了。使用盐，几乎不需要额外的努力。现在做。
“根本不需要存储密码盐”：盐可以很小（6字节）。它几乎不会影响性能。
如果你从密码本身汲取盐分，你将失去盐析的全部好处。然后，您可以构建一个单一的彩虹表来获取所有密码，并且相同的密码将导致相同的散列值。
使用盐的主要原因是，攻击者不能构建一个单独的彩虹表，并获取存储在数据库中的所有密码。这就是为什么你应该为每个密码添加一个随机独特的盐，然后攻击者将不得不为每个密码分别建立一个彩虹表。建立一个单一密码的彩虹表是没有意义的，因为暴力破解更快（为什么不只是在发现密码时停止）。
不要害怕做正确的事情，编程环境常常支持创建安全哈希并处理您的腌制（例如，用于PHP的password_hash()）。盐通常与散列结合用于存储，这使得它可以很容易地将其存储在单个数据库字段中。
我写了一个关于securely storing passwords的小教程，也许你想看看它。
我只是想从一些更有经验的开发人员那里得到一些反馈。任何反馈意见。
OWASP的John Steven对密码存储系统进行了分析，包括威胁模式。它解释了组件及其用途，如散列，迭代计数，salt，HMAC，HSM等。请参阅Secure Password Storage Cheat Sheet和Secure Password Storage paper。
破裂不是这里唯一的威胁。尝试闯入你的组织的人很可能会使用来自Adobe违规，LinkedIn违规，Last.fm违规，eHarmony违规，<最喜欢收集的数百万密码中的顶级密码之一这里>违反....例如：
何苦暴力破解，当你有几千列表评分最高的密码使用？
所以你的FIRST最好的防御措施是使用一个单词列表来过滤用户的错误密码选择。也就是说，不要让用户首先选择弱或已知的密码。
如果有人忘记了您的密码数据库，那么他或她将使用这些相同的密码列表来尝试猜测您的用户密码。他或她可能甚至不会打扰暴力强制，因为他或她会使用密码列表恢复如此多的密码。
据我所知，这些单词列表实现为Bloom Filter时非常小。即使有数百万个密码，它们的大小也只有KB。请参阅Peter Gutmann的Engineering Security进行深入讨论。
为什么改变什么可行？ – Gabs00
如果你使用（混乱）密码作为盐，那么黑客将不再需要找到一个字符串哈希到相同的值，以获得密码，他们只需要解开密码。盐通常以密码哈希存储在纯文本中，因此获得盐很容易。那么保护你的密码的唯一方法就是你混淆它的程度，除非你真的知道你在做什么，否则可能会有一些可以利用的弱点...... – twalberg
@twalberg我认为这个概念背后想法是根本消除存储密码盐的需要。 –