我在考虑使用两个不同的盐字符串对用户密码进行哈希处理，一个存储在代码中，对所有用户都相同，另一个存储在数据库中，每个用户都有自己唯一的值。
与仅将值存储在数据库中相比，这种方法是否更有效？
欢迎任何建议和意见。
谢谢
1个回答
21
如果有的话，效果微不足道。可以将静态、硬编码的盐视为散列算法的改变 - 每次都以完全相同的方式进行，因此它可以被视为算法的一部分。
但是盐的目的是创建一些随机性，这类似于扩展（最小）强度密码的作用，目的是使离线破解（包括彩虹表）更加耗费资源（非彩虹表破解将需要更多的 CPU 时间，并且彩虹表将需要所有字符串的盐）。
唯一能从中获得价值的方法是当静态盐是未知的 - 相当于算法是未知的。如果攻击者可以访问您的二进制文件或源代码，则逆向工程将演示算法和硬编码的盐。
而且，如果这个问题公开了，你可能要面对许多安全爱好者的抨击，他们认为任何不完美的东西都是完全错误的，尽管你的产品已经做了正确的事情，而额外的步骤只是无用的。
当然，你还必须处理使用静态盐的维护问题 - 向后兼容性和散列代码围绕错误修复可能很麻烦。
静态密钥（或盐）的微小好处根本不值得代价。始终使密钥和盐动态化。
但是盐的目的是创建一些随机性，这类似于扩展（最小）强度密码的作用，目的是使离线破解（包括彩虹表）更加耗费资源（非彩虹表破解将需要更多的 CPU 时间，并且彩虹表将需要所有字符串的盐）。
唯一能从中获得价值的方法是当静态盐是未知的 - 相当于算法是未知的。如果攻击者可以访问您的二进制文件或源代码，则逆向工程将演示算法和硬编码的盐。
而且，如果这个问题公开了，你可能要面对许多安全爱好者的抨击，他们认为任何不完美的东西都是完全错误的，尽管你的产品已经做了正确的事情，而额外的步骤只是无用的。
当然，你还必须处理使用静态盐的维护问题 - 向后兼容性和散列代码围绕错误修复可能很麻烦。
静态密钥（或盐）的微小好处根本不值得代价。始终使密钥和盐动态化。
- atk
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接