#1059 closed defect (fixed)
HtPasswdStore doesn't recognize Blowfish hashes
Reported by: | anonymous | Owned by: | Matt Good |
---|---|---|---|
Priority: | normal | Component: | AccountManagerPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.10 |
Description
On my FreeBSD Sparc box, the HtPasswdStore wouldn't work with crypt()ed htpasswd files generated by Apache's own htpasswd binary. Once I forced the passwords to be SHAsums, HtPasswdStore worked fine.
Attachments (1)
Change History (8)
Changed 18 years ago by
comment:1 Changed 18 years ago by
Actually, HtPasswdStore doesn't work at all, when it comes to things like Adding New Users in the AccountManagerAdminPage. Again, if I force Apache's htpasswd to use SHA (I've not tried MD5, I imagine it works as well) to make a new password, it works fine. I am worried that users will try to change their passwords and make it impossible to log in... Perhaps BSD does crypt(3) different than other unices?
comment:2 Changed 18 years ago by
Keywords: | needinfo added |
---|---|
Summary: | HtPasswdStore doesn't work → HtPasswdStore doesn't recognize Blowfish hashes |
Based on the hash in your htpasswd file your system is using a Blowfish-based crypt scheme.
How does the Python crypt module compare to what htpasswd is outputting? This is what I get from the standard DES-based crypt on my system:
$ python -c 'import crypt; print crypt.crypt("password", "AB")' ABRCL9ijBr2LY
Do you see the same output, or does that also produce a Blowfish-based hash?
comment:3 Changed 18 years ago by
Gah, you're completely right: I'm using Blowfish. "$2a$04$A..F9d99wOC......BtGC.qtucOVLTvYLiR2gJFuDhVbL9gb.d/lq" is what I get. Anything I can do about this? I can't change the system I'm on.
comment:4 Changed 18 years ago by
Ok, try this:
$ python -c 'import crypt; x = crypt.crypt("password", "AB"); print x == crypt.crypt("password", x)' True
The plugin is currently assuming that there are only 2 bytes of salt at the beginning of the hash. Based on the docs for the Python crypt module it appears that it should be possible to feed the whole hash and the underlying crypt implementation should handle this correctly. If the command above prints "True" this should only require a small patch to correct.
comment:5 follow-up: 6 Changed 18 years ago by
It prints True! Thanks for putting up with me,anyhow.
comment:6 Changed 18 years ago by
Keywords: | needinfo removed |
---|---|
Status: | new → assigned |
Replying to anonymous:
It prints True! Thanks for putting up with me,anyhow.
Thanks for helping debug this.
comment:7 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Htpasswd on FreeBSD Sparc