我正在使用 Jquery SHA512.js 发送加密并将用户名和密码发送到服务器。在服务器上，我正在执行以下操作来创建我的数据库存储 HASH：
$dbhash = = hash('sha256',(hash('sha512',$user) . hash('sha256',$extremesalt)));
这一切都很好。
我的问题是盐的价值是什么？在将 Salt 应用于密码的那一刻，密码已经在服务器上，而不是在 Internet 上传输。Salt也存储在密码哈希旁边。
因此，似乎有人需要使用哈希表来获取我的表，如果他们这样做了，他们还可以获得盐和我的其余代码，并在我的网站上做他们想做的事情。
我可以看到应用盐的好处，我会这样做，但因为它只发生在服务器上，而不是从浏览器到服务器，我质疑它的价值。我错过了什么吗？
另一个问题 - 是否可以将盐从浏览器应用到服务器。我假设不是，或者至少如果你这样做了，如果有人检查了源代码（例如：在我的原因中在 jquery 中可见），它会是可见的。因此没有实际价值。
谢谢
加盐的目的是更难看出两个人的密码是否相同。关于 SHA 的一件事是它不容易逆转。大多数攻击涉及为常见密码生成哈希，因此对于相当复杂的密码，尤其是使用盐（有些人使用用户名作为盐，其他人使用随机生成的数字）变得更加困难。通常您想在服务器端代码上执行此操作（我认为在浏览器代码上执行此操作不安全）。您也不应该将实际密码存储在只存储哈希的服务器上（如果您还不知道，可能还有盐）
再看一遍，我发现您在另一个 256 之后使用 2 个哈希，然后是 512。这是一个坏主意，使用一个并坚持下去。您浪费时间计算多个哈希。
像这样混合哈希是毫无意义的。采用 sha512 哈希并通过 sha256 运行它必然会将密钥空间减半，因此您所做的只是浪费 cpu 时间并使发生冲突的几率加倍。可能性仍然很小/很小，但仍然需要考虑。
盐是作为一种覆盖屁股的机制。如果由于某种原因您的数据库泄漏（例如，转储文件“丢失”），生成一个常见密码的 sha256/512 彩虹表并查看您的表上是否有任何命中将是微不足道的。散列的存在使得生成彩虹表的成本要高得多。例如“密码”很容易散列和检查。"password#^$@#%#^Y#@#$@#^%$^Y%%$" 被彩虹化的可能性要小得多。
$dbhash = = hash('sha256',(hash('sha512',$user) . hash('sha256',$extremesalt)));
应该是（不需要双重哈希）
$dbhash = = hash('sha512',$pass + $salt);
其中 pass 是密码，而 salt 是用户独有的东西（例如用户 ID）。如果您选择随机值，则需要将其与哈希一起存储。
我不知道您的应用程序，但您不想使用 SSL 将用户名/密码发送到服务器，并让 SSL 的公钥加密为您处理加密。然后，服务器可以生成适当的散列来存储散列密码或与先前存储的散列进行比较以进行验证。