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

Question

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

例如，下面是密码“test”的条目： 1000:f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39:b69139f51bc4098afc36b4ff804291b0bc697f87be9c1ced

这里我们可以通过:分割字符串并找到：

迭代次数：1000

盐：f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39

PBKDF2 哈希：b69139f51bc4098afc36b4ff804291b0bc697f87be9c1ced。

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

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

play 中的 PBKDF2 哈希与此哈希不匹配。 （对于那些想知道的人，我使用 24 作为第四个参数，因为这是 PasswordHash.java 中使用的）。

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

我插入相同的盐，使用 SHA-1 迭代 1000 次，密钥大小为 24 位，发现该网站与 Django 创建的相匹配！

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

Answer 1

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

我做到了，并且在您的初始示例中得到了哈希值，尽管是大写的 B69139F5...

解释：

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

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