java - PasswordHash.java 未生成匹配的 PBKDF2-HMAC-SHA1 哈希

Question

我正在编写一个需要与现有 Java Play 框架应用程序配合使用的 Django 应用程序。 Play 应用程序使用 PasswordHash.java存储密码。它以冒号分隔的格式存储密码。每个散列存储为 iterations:salt:pbkdf2_hash。

例如，这是密码“test”的条目:1000:f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39:b69139f51bc4098afc36b4ff804291b0bc697f87be9​​c1ced

这里我们可以通过:拆分字符串，然后找到:

迭代次数:1000

盐:f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39

PBKDF2 哈希:b69139f51bc4098afc36b4ff804291b0bc697f87be9​​c1ced。

我修改了Django的check_password机制来兼容这种格式，但是发现它并不认为密码是正确的。我使用 Django 的 crypto.py 使用 Play 使用的相同盐为“测试”重新生成哈希，并提出了这个:

hash = crypto.pbkdf2('test', 'f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39', 1000, 24)
base64.b16encode(hash)
'9A8725BA1025803028ED5B92748DD61DFC2625CC39E45B91'

游戏中的 PBKDF2 散列与此散列不匹配。 (对于那些想知道的人，我使用 24 作为第四个参数，因为这是在 PasswordHash.java 中使用的)。

在我无法使 Django 生成的哈希与 Java 匹配后，我在 website that does it for you. 上尝试了它

我插入了相同的盐，使用了具有 1000 次迭代和 24 位 key 大小的 SHA-1，发现该网站与 Django 创建的网站相匹配!

我不确定 PasswordHash.java 发生了什么，但我迫切需要让 Django 和 Play 能够“很好地玩”(忍不住哈哈)。有人知道这里发生了什么吗？

Answer 1

尝试salt = base64.b16decode(salt.upper())。

我做到了，我在你最初的例子中得到了散列，尽管是大写的 B69139F5...

解释:

在您的初始示例中，散列和盐都存储在 Base16(十六进制)中。因此，您对盐进行解码以使用它，然后对生成的哈希进行编码以将其与存储的哈希进行比较。

upper()是因为python的b16decode对大写Base16比较严格。如果你给它小写的，它会出错。