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

我正在编写一个Django应用程序，它需要与现有的Java Play framework应用程序配合使用。Play应用程序用于存储密码。它以冒号分隔的格式存储密码。每个散列存储为

迭代

：

salt

：

pbkdf2_散列

例如，下面是密码“test”的条目：

1000:f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39:b69139f51bc4098afc36b4ff804291b0bc697f87be9c1ced

在这里，我们可以通过

：

拆分字符串并找到：

迭代次数：

1000

盐：

f7fe4d511bcd33321747a778dd21097f4c0ff98f1e0eba39

PBKDF2哈希：

b69139f51bc4098afc36b4ff804291b0bc697f87be9c1ced

我修改了Django的check_密码机制以与此格式兼容，但发现它认为密码不正确。我使用Django的crypto.py为“测试”重新生成了一个哈希，并使用了与Play相同的salt，得出了以下结论：

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

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

在我无法使Django生成的哈希值与Java的哈希值匹配之后，我在一台计算机上进行了尝试

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

---

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

试试

salt=base64.b16decode（salt.upper（））

我这样做了，并且在您最初的示例中得到了哈希值，尽管大写

B69139F5…

说明：

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

---

之所以使用

upper（）

，是因为python的

b16decode

对大写Base16有严格要求。如果使用小写字母，则会出错。

效果非常好！有趣的是，你能解释一下为什么解码盐是必要的吗？我绝对不是密码专家。