I went looking for BCrypt + Django + Python3 today and this is what I found:

The current recommended solution to bcrypt + Django is using py-bcrypt which is 
not compatible with Python3. 

Someone else has taken py-bcrypt and created py3k-bcrypt however they made the 
decision to enforce having str instances sent in for password/salt instead of 
bytes which makes it incompatible with Django's encode function on the BCrypt 
password hashers[1].

So I created a library simply called `bcrypt`[2] which has the same API as 
py-bcrypt but it functions on Python 2.6+ and 3.x (as well as PyPy 2.0 since 
it's implemented via CFFI). When testing this against Python3 + Django I 
discovered that Django isn't properly encoding/decoding when talking to the 
external library so I made a patch that causes it to always send bytes to the 
external library, and str's to other pats of Django. That can be found here: 
https://github.com/django/django/pull/1052

My bcrypt library is obviously new code but it's a small wrapper over 
crypt_blowfish from OpenWall[3] and I'm wondering (assuming no one objects to 
me merging my Patch) if it would make sense to switch the documentation away 
from suggesting py-bcrypt and have it suggest bcrypt instead since it will 
allow BCrypt to function on Python3 as well.

Thoughts?

[1] I believe this is inheriently wrong as bcrypt operates on bytes not on 
unicode characters, and in order for this to work py3k-bcrypt must be assuming 
a character set it can encode().
[2] Found at https://crate.io/packages/bcrypt/ or 
https://github.com/dstufft/bcrypt
[2] Found at http://www.openwall.com/crypt/

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to