密码 +盐 +秘制酱料？有帮助，还是有点晦涩难懂？
标准密码安全性涉及为每个用户生成随机盐，以某种方式将该盐与其密码组合并将它们散列在一起，然后将散列和盐存储在数据库中。
如果您不仅添加了 hash($salt . $password)，还添加了另一个密码短语（仅存储在源代码或服务器配置文件中），结果会怎样：
$secret_sauce = 'tehB%l1yG*@t$G2uFf'; // perhaps imported from config file
$hash = hash($salt . $secret_sauce . $password);
这会增加任何额外的好处吗？或者只是在顶部应用了一层薄薄的默默无闻的安全保护？
Standard password security involves generating a random salt for each user, somehow combining that salt with their password and hashing them together, and then storing both the hash and salt in the database.
What if, instead of just hash($salt . $password), you added in another passphrase as well, stored only in your source code or in a server config file:
$secret_sauce = 'tehB%l1yG*@t$G2uFf'; // perhaps imported from config file
$hash = hash($salt . $secret_sauce . $password);
Does this add any added benefit, or is it just a thin layer of security by obscurity applied to the top?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
对于密码文件，只需在顶部添加一点模糊性即可。
但是，此方案称为“密钥哈希”，可用于对称（共享秘密）签名：如果您有这样的哈希和输入数据，那么您可以确定签名是由同时创建的人创建的知道额外的秘密。当然，与公钥签名不同，如果不知道密钥，则无法验证这一点。
For password files it would be just a little obscurity added on top.
However, this scheme is called a "keyed hash" and can be used for symmetric (shared-secret) signatures: if you have such a hash, and the input data, then you can be sure that the signature was created by someone who also knows the secret extra bit. Of course, unlike a public-key signature, you cannot verify that without also knowing the secret key.
我很难找到几年前读过的一篇论文，该论文表明通过部分计算哈希的部分可以轻松生成数千个哈希结果。 （例如，通过开始计算“foo”的哈希值，您可以更轻松地生成“foo1”、“foo2”、“foo3”、“foo4”等的哈希值，比单独生成每个哈希值便宜得多。 ）
我认为它会主张在密码之前和之后都加盐。
但请记住，如果攻击者可以读取密码数据库，他们也可能可以从您的二进制文件或配置文件中读取盐；这取决于你的设计。
I'm having trouble tracking down the paper I read a few years ago that suggested it was easy to generate thousands of hash results by partially computing portions of the hash. (As in, by beginning to compute the hash for "foo", you could more easily generate hashes for "foo1", "foo2", "foo3", "foo4", and so on, much cheaper than generating each one individually.)
I think it would argue for salting both before and after a password.
But keep in mind that if the password database can be read by an attacker, they can probably read the salt out of your binary or config file too; it depends on your design.