哈希和腌制价值观
我正在开发一个内部validation用户的小型Web应用程序。 一旦用户通过身份validation，我的Web应用程序就会将一些信息（如userID和Person的名称）传递给第三方Web应用程序。 第三方开发人员建议我们对值进行散列和加盐。
原谅我的无知，但究竟是什么意思呢？
我正在用Java编写应用程序。 所以我打算做的是将userID，Person的名称和一些Math.random（）值作为Apache Commons Digest Utils SHA512的哈希值并将该哈希字符串与userID和person的名称一起传递。
这是标准做法吗？ 我应该通过第三方盐也是正确的？
盐通常用于安全地存储密码的哈希值。 散列用于存储或通信的密码（以便其他人无法读取）很容易通过使用彩虹表进行解码。 现在，当您向密码添加随机字符串，但使用散列存储字符串时，这变得更加困难。 计算这个新哈希看起来像：
hash(password + salt) 甚至
hash(hash(password) + salt)
要安全地登录第三方网站，可以发送UserID，盐渍哈希（从上面）和您使用的盐（如果没有给出）。 根据网站存储密码的方式，您可以为自己生成盐，也可以从中获取盐。
一种选择是首先将UserID发送到网站，然后让它以salt响应，然后将hash(password+salt))回网站。
在Java中，您可以执行以下操作：
import org.apache.commons.codec.digest.DigestUtils; import org.apache.commons.lang.RandomStringUtils; /** * SHA1-hash the password with the user's salt. * * @param password */ public void setPassword(String password) { if (password.equals(this.password)) { return; } if (passwordSalt == null || passwordSalt.equals("")) { passwordSalt = RandomStringUtils.randomAscii(20); } this.password = DigestUtils.shaHex(password + passwordSalt); } /** * Check if a given password is correct. * * @param givenPassword * @return True is correct, else false. */ public boolean checkPassword(String givenPassword) { return (password.equals(DigestUtils.shaHex(givenPassword + passwordSalt))); }
然后密码是不可读的，即使黑客窃取您的数据库。
只是抬头，有关于如何处理Salt的一些错误信息。 储存盐是正常的，也是正常的。 每个密码都应该有自己的盐，它与它一起以纯文本forms存储。 这意味着对于已经窃取了您的散列密码数据库的人来说，使用预先计算的哈希表对其进行解密会更加困难。
至于你应该向第三方发送盐，我必须得到更多的信息。 无论是谁在身份validation期间获取客户端提供的密码，对其进行散列并将其与预先散列版本进行比较，都需要使用salt，以便客户端提供的用于身份validation的密码可以与之前完全相同。
一旦用户通过身份validation，我的Web应用程序就会将一些信息（如userID和Person的名称）传递给第三方Web应用程序。 第三方开发人员建议我们对值进行散列和加盐。
这听起来不对。 哈希是单向操作。 您无法获取哈希的结果并从中获取纯文本
我计划做的是散列userID，Person的名字和一些Math.random（）值作为salt
对于任何给定的纯文本，您需要使用相同的salt，否则生成的哈希值将不同。 因此，如果您要使用随机或生成的盐，则需要将其与密码哈希一起存储。
使用SHA-256或SHA-512很好，是NIST推荐的
我会看到你是否找不到更多信息或你正在使用的第三方应用程序的一些例子。 您所描述的内容似乎并不常见，而且根据您所说的内容，老实说甚至没有那么多意义。
您在程序中对用户进行身份validation（几个答案似乎正在解决此问题，是的，您应该将用户密码存储为盐渍哈希，但这是一个整体’其他问题）然后，在validation它们时，传递一些信息到这个第三方应用程序。 现在，这取决于这个应用程序应该做什么/知道什么。 例如，如果它需要知道userID，那么在提交之前你不能哈希/加盐它，因为应用程序将永远无法获得原始用户ID。 另一方面，如果应用程序只需要某种标识符来识别请求，并且哈希userID + userName只是一个建议 ，那么这确实有意义，你基本上生成一个用户唯一但不可解码的字符串要使用的第三方应用程序，基本上作为会话密钥。
如果第二条路线是他们想要做的，那么处理请求的方式有点奇怪（而且不是非常安全），但对我来说似乎没问题。
就像我说的那样，看看你是否能找到一些例子，或者即使你想在这里发布有关该应用程序的更多信息，我们也可以自己看看。
盐的全部意义在于使用所谓的“彩虹表”进行攻击是不可行的（从概率的角度来看：如果你采用足够大的哈希值，则实际上不可能预先计算彩虹表）。
http://en.wikipedia.org/wiki/Rainbow_table
而不是仅仅执行哈希（ a ）并存储哈希：
:460526e74fd6a25b525e642db2f756a4:
你做哈希（a + salt）并存储哈希和盐（盐可以随机选取）：
:cdd5bc3f05f6a76f6c82af728b2c555c:346884e6e35be: