静态盐与随机盐 - 安全 PHP
如果我使用随机盐
$hash=sha1($key.$staticSalt);
，
$hash=sha1($key.$randomSalt);
我需要将随机盐存储在数据库中，另一方面，如果我使用固定盐，则不需要使用数据库！
如果代码可以被黑客攻击以查看盐（静态），那么黑客将能够通过哈希和随机盐查看数据库：D
那么值得吗？
如果我使用像 @#kiss~89+.&&^me 这样的盐会怎么样？
Is there any working difference between
$hash=sha1($key.$staticSalt);
and
$hash=sha1($key.$randomSalt);
If i use random salt i need to store the random salt in the database, on the other side if i use a fixed salt then no need to use DB !
And if the code can be hacked to see the salt (static) then the hacker will be able to see the database also with the hash and random salt :D
So does it worth it ?
What if i use a salt like @#kiss~89+.&&^me ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
随机盐有巨大的好处。如果系统中的所有帐户都使用相同的盐，则攻击者可以暴力计算该盐的哈希值，并仅通过一次计算运行即可侵入所有帐户。如果他们对每个账户使用不同的盐，那么暴力破解只能让你进入一个账户。
Random salts have a tremendous benefit. If all accounts in the system use the same salt, an attacker can brute-force calculate hashes for that salt and break into all accounts with just one computational run. If they use different salts per account, brute-force only gets you into one account.
虽然密码存储的最佳实践规定它们应该以具有唯一盐的散列格式存储，但最初的问题实际上提出了一个相当好的观点：如果将盐存储在与散列不同的位置，那么这些散列的影响披露的情况有所降低。
1) 如果密码仅经过哈希处理并存储在数据库中，并且站点遭受 SQL 注入，那么攻击者可以“破解”哈希值
2) 如果密码使用盐进行哈希处理，并且哈希值和盐都在数据库，并且该站点具有 SQL 注入，那么攻击者可以“破解”哈希值，但需要更多的计算工作（因为预先计算的表没有性能提升）
3) 如果密码是带有盐的哈希值，并且盐存储在其他地方，那么 SQL 注入几乎无法为攻击者提供确定实际密码的手段。
场景 1 显然是最弱的，但 2 和 3 之间的安全性差异不太明显，并且取决于 SQL 注入与服务器端代码泄露（以及相关漏洞类别）的相对概率。
您更信任什么 - 您防止 SQL 注入的能力，还是 Apache/PHP/Whatever 保护服务器端内容的能力。
事情从来都不简单，我实际上认为OP中的想法比其他答案所认为的更有意义。
（在生成密码时，您可以同时使用存储在数据库中的盐和存储在 Web 应用程序源中的“密钥”）。
While best practice for password storage dictates that they should be stored in a hashed format with a unique salt, the original question actually raises a reasonably good point: if you store the salt in a different location to the hashes, the impact of those hashes being disclosed is lowered.
1) If the passwords were only hashed, and stored in a database, and the site suffered from SQL Injection then an attacker could "crack" the hashes
2) If the passwords were hashed with a salt, and the both hash and salt were in the database, and the site had SQL Injection then an attacker could "crack" the hashes, but would require more computational effort (as there is no performance boost from pre-computed tables)
3) If the passwords were hashes with a salt, and the salt was stored elsewhere, then SQL Injection would afford an attacker little leverage to ascertain the actual password.
Scenario 1 is obviously weakest, but the difference in security between 2 and 3 is less clear-cut, and depends on the relative probabilities of SQL Injection vs server-side code disclosure (and associated classes of vulnerability).
What do you trust more - your ability to protect against SQL Injection, or the ability of Apache/PHP/Whatever to protect your server-side content.
Things are never simple and I actually think the idea in the OP makes more sense than other answers give credit for.
(You could use both, a salt stored in database and a "key" if you like stored in the web app source, when generating passwords).
根据定义，盐是随机的；不存在“静态盐”这样的东西。如果它不是随机的，那么它就不是盐而是密钥。
加盐的目的是确保攻击者必须为他/她想要破解的每个密码发起单独的攻击。换句话说，对哈希加盐的目的是防止预计算攻击（彩虹表）。
正确解决问题的简单解决方案是使用标准库< /a> 而不是偷工减料
A salt is be random by definition; there is no such thing as a 'static salt'. If it is not random, it's not a salt but a key.
The point of the salt is to make sure the attacker has to mount a separate attack for each password he/she wants to crack. In other words, the point of salting a hash is to prevent precomputation attacks (rainbow tables).
The easy solution for getting it right is to use a standard library instead of cutting corners
始终对每个密码使用随机盐。
如果你不这样做，那么吃盐的好处就失去了。如果您使用相同的盐，那么在网站受到威胁的情况下，黑客可以使用相同的哈希表来破解您的用户列表中的所有密码。如果盐是随机的，那么他们必须为每个用户使用不同的哈希表。
Always use random salt for each password.
If you don't then the benefit of having the salt is lost. If you use the same salt, then in the case when website gets compromised, the hacker can use same hash table for hacking all the passwords in your userlist. If salt is random, then they have to use different hash table for each user.
我不确定您是否正确加盐 - 加盐的目的是在您的数据库受到损害时阻止预先计算的字典攻击。因此，您一开始就使用数据库，那么您的“不需要使用数据库”评论是什么意思？
如果您没有使用随机盐，那么即使攻击者拿到了盐，也不会增加攻击您的哈希值的难度。使用随机盐会更好——您不需要为了安全性而隐藏它。
盐也不需要太长或不寻常。 “rK”是一种很好的盐。 “1q”也不错。其目的只是改变哈希函数的输出。
I 'm not sure if you are salting correctly -- the purpose of a salt is to foil precomputed dictionary attacks if your database is compromised. Therefore you are using a database to begin with, so what does your "no need to use the DB" comment mean?
If you are not using a random salt, then you don't make it more difficult for the attacker to attack your hashes if they get their hand on the salt. You will be better off using a random salt -- you won't need to keep it hidden for your security to work.
The salt also does not need to be long or unusual. "rK" is a good salt. "1q" is also good. Its purpose is simply to vary the output of the hash function.