我正在开发一个内部验证用户身份的小型Web应用程序。一旦用户通过身份验证,我的Web应用程序就会将一些信息(如userID和Person的名称)传递给第三方Web应用程序。第三方开发人员建议我们对值进行散列和加盐。
原谅我的无知,但究竟是什么意思呢?
我正在用Java编写应用程序。所以我打算做的是将userID,Person的名称和一些Math.random()值作为Apache Commons Digest Utils SHA512的哈希值并将该哈希字符串与userID和person的名称一起传递。
这是标准做法吗? 我应该通过第三方盐也是正确的吗?
答案 0 :(得分:14)
盐通常用于安全存储密码哈希值。哈希用于存储或通信的密码(以便其他人无法读取)很容易使用rainbow tables进行解码。现在,当您向密码添加随机字符串,但使用散列存储字符串时,这变得更加困难。计算这个新哈希看起来像:
hash(password + salt)
甚至
hash(hash(password) + salt)
要安全登录第三方网站,可以发送UserID,盐渍哈希(从上面)和您使用的盐(如果没有给出)。根据网站存储密码的方式,您可以为自己生成盐,也可以向其索取盐。
一种选择是首先将UserID发送到网站,然后让它回复盐,然后将hash(password+salt))
发送回网站。
答案 1 :(得分:8)
在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)));
}
然后密码不可读,即使黑客窃取您的数据库。
答案 2 :(得分:3)
只是抬头,有关于如何处理Salt的一些错误信息。存储盐是正常的,也是正常的。每个密码都应该有自己的盐,并以纯文本形式存储。这意味着让已经窃取了您的哈希密码数据库的人使用预先计算的哈希表对其进行解密来使其变得更加困难。
如果您要向第三方发送盐,我必须获得更多信息。无论是谁在身份验证期间获取客户端提供的密码,对其进行散列并将其与预先散列版本进行比较,都需要使用salt,以便客户端提供的用于身份验证的密码可以与之前的密码完全相同。
答案 3 :(得分:1)
用户通过我的网站验证后 应用然后传递一些信息 as userID和Person的名字为第三个 派对Web应用程序。第三方开发人员建议我们对值进行散列和加盐。
这听起来不对。哈希是单向操作。您无法获取哈希的结果并从中获取纯文本
我打算做的是哈希 userID,Person的名字和一些 Math.random()值为盐
对于任何给定的纯文本,您需要使用相同的salt,否则生成的哈希值将不同。因此,如果您要使用随机或生成的盐,则需要将其与密码哈希一起存储。
使用SHA-256或SHA-512很好,是NIST recommends
答案 4 :(得分:1)
我会看到您是否找不到您正在使用的第三方应用中的更多信息或示例。您所描述的内容似乎并不常见,而且根据您所说的内容,实际上甚至没有那么多意义。
您在程序中对用户进行身份验证(几个答案似乎正在解决此问题,是的,您应该将用户密码存储为盐渍哈希,但这是一个整体'其他问题),然后,在对其进行身份验证时,将一些信息传递给第三方应用程序。现在,这取决于这个应用程序应该做什么/知道什么。例如,如果它需要知道userID,那么在提交之前你不能散列/加盐它,因为应用程序将永远无法获得原始用户ID。另一方面,如果应用程序只需要某种标识符来识别请求,并且哈希userID + userName只是一个建议,那么这确实有意义,你基本上生成了一个用户唯一的但是第三方应用程序使用的不可解码字符串,基本上作为会话密钥。
如果第二条路线是他们想要做的,那么处理请求的方式有点奇怪(而且不是非常安全),但对我来说似乎没问题。
就像我说的那样,看看你是否能找到一些例子,或者即使你想在这里发布有关应用程序的更多信息,我们也可以自己看看。
答案 5 :(得分:0)
盐的全部意义在于使用所谓的“彩虹表”进行攻击不可行(从概率的角度来看:如果你采用足够大的哈希,那么它实际上变得不可能预先计算彩虹表。)
http://en.wikipedia.org/wiki/Rainbow_table
而不是仅仅执行哈希( a )并存储哈希:
:460526e74fd6a25b525e642db2f756a4:
你做哈希(a + salt)并存储哈希和盐(盐可以随机挑选):
:cdd5bc3f05f6a76f6c82af728b2c555c:346884e6e35be: