SHA 加密 - 真的需要盐吗？
我正在使用 Jquery SHA512.js 发送加密并将用户名和密码发送到服务器。 在服务器上，我正在执行以下操作来创建数据库存储的哈希：
$dbhash = = hash('sha256',(hash('sha512',$user) .hash('sha256',$extremesalt)));
这一切都很好。
我的问题是盐有什么价值？ 当将盐应用于密码时，密码已经在服务器上，并且不会通过 Internet 传输。此外，Salt 还存储在密码哈希旁边。
因此，似乎有人需要获取我的带有哈希值的表，如果他们这样做了，他们也可以获得盐和我的其余代码，并在我的网站上做他们想做的事情。
我可以看到应用盐是好的，我会这样做，但由于它只发生在服务器上，而不是从浏览器到服务器，我质疑它的价值。我错过了什么吗？
另一个问题 - 是否可以将盐从浏览器应用到服务器。我假设没有，或者至少如果你这样做了，如果有人检查源代码，它就会是可见的（例如：在我的原因中，jquery 中可见）。因此没有实际价值。
谢谢
I'm using Jquery SHA512.js to sent encrypt and send a username and password to the server.
At the server I'm doing the following to create my DB stored HASH:
$dbhash = = hash('sha256',(hash('sha512',$user) . hash('sha256',$extremesalt)));
This all works fine.
My Question is what value is the Salt?
At the point the Salt is applied to the password, the password is already on the server and not in transit across the Internet. Also the Salt is stored next to the password hash.
Therefore it appears someone would need to get my table with hash's and if they did they could also get the salt and the rest of my code and do what they wanted with my site in general.
I can see its good to apply a salt and I will do so but as it only occurs on the server and not from the browser to the server I question its value. Am I missing something?
One other question - is it possible to apply a salt from the browser to the server. I assume not or at least if you did it would be visible if one checked the source (eg: in my cause visible in jquery). Thus of no real value.
thx
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
加盐的目的是让我们更难看出两个人的密码是否相同。 SHA 的一件事是它不容易逆转。大多数攻击涉及为常见密码生成哈希值，因此对于相当复杂的密码，尤其是使用盐时，它会变得更加困难（有些人使用用户名作为盐，其他人使用随机生成的数字）。通常您想在服务器端代码上执行此操作（我认为在浏览器代码上执行此操作不安全）。你也不应该在服务器上存储实际的密码，你只存储哈希值（如果你还不知道的话，也许还有盐）
再一看，我发现你使用了 2 个哈希值，一个在另一个 256 之后，然后a 512。这是一个坏主意，使用一个并坚持下去。您浪费时间计算多个哈希值。
The point of the salt is to make it harder to see if 2 people's passwords are the same. One thing about SHA is that it's not easily reversible. Most attacks involve generating hashes for common passwords so for reasonably complicated passwords it becomes harder especially with salts (some people use usernames as salts, others use randomly generated numbers). Usually you want to do this on the server side code (I don't think it's safe to do on browser code). You should also never store the actual password on the server you only store the hash (and maybe the salt if you don't already know it)
Upon a second look I see that you're using 2 hashes one after the other 256 and then a 512. This is a bad idea, use one and stick with it. You waste time computing multiple hashes.
像这样混合哈希是毫无意义的。获取 sha512 哈希值并通过 sha256 运行它必然会将密钥空间削减一半，因此您所做的只是浪费 CPU 时间并使冲突的几率增加一倍。可能性仍然很小/微观，但这仍然是需要考虑的事情。
盐是作为屁股覆盖机制而存在的。如果由于某种原因您的数据库发生泄漏（例如转储文件“丢失”），则生成常用密码的 sha256/512 彩虹表并查看表中是否有任何命中将是微不足道的。散列的存在使得生成彩虹表的成本要高得多。例如，“密码”很容易散列和检查。 “password#^$@#%#^Y#@#$@#^%$^Y%%$”出现彩虹的可能性要小得多。
Mixing hashes like that is rather pointless. Taking an sha512 hash and running it through sha256 necessarily cuts the keyspace in half, so all you've done is waste cpu time and double the odds of a collision. The odds will still be vanishingly small/microscopic, but it's still something to consider.
The salt is there as a butt-covering mechanism. If for some reason your database were to leak (e.g. a dump file got "lost"), it would be trivial to generate an sha256/512 rainbow table of common passwords and see if there's any hits on your table. The hash is there to make it far more expensive to generate a rainbow table. e.g. "password" is easy to hash and check for. "password#^$@#%#^Y#@#$@#^%$^Y%%$" is far less likely to be rainbowed.
我不知道你的应用程序，但你不想使用 SSL 将用户名/密码发送到服务器，并让 SSL 的公钥加密为你处理加密吗？然后，服务器可以生成适当的散列来存储散列密码或与先前存储的散列进行比较以进行验证。
I don't know your app, but wouldn't you want to just send the username/pwd to the server using SSL and let the public key encryption of SSL take care of the encryption for you. The server can then generate an appropriate hash to either store the hashed password or to compare to a previously stored hash for verification.
应该是（不需要双重哈希），
其中 pass 是密码，salt 是用户的唯一信息（例如 userid）。如果您选择随机值，则需要将其与哈希值一起存储。
Should be (no need for double hashing)
Where pass is the password and salt is something unique about the user (userid for example). If you opt for random value you need to store it with the hash.