Modify

Opened 17 years ago

Closed 17 years ago

Last modified 16 years ago

#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)

htpasswd (150 bytes) - added by anonymous 17 years ago.
Htpasswd on FreeBSD Sparc

Download all attachments as: .zip

Change History (8)

Changed 17 years ago by anonymous

Attachment: htpasswd added

Htpasswd on FreeBSD Sparc

comment:1 Changed 17 years ago by anonymous

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 17 years ago by Matt Good

Keywords: needinfo added
Summary: HtPasswdStore doesn't workHtPasswdStore 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 17 years ago by anonymous

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 17 years ago by Matt Good

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 Changed 17 years ago by anonymous

It prints True! Thanks for putting up with me,anyhow.

comment:6 in reply to:  5 Changed 17 years ago by Matt Good

Keywords: needinfo removed
Status: newassigned

Replying to anonymous:

It prints True! Thanks for putting up with me,anyhow.

Thanks for helping debug this.

comment:7 Changed 17 years ago by Matt Good

Resolution: fixed
Status: assignedclosed

(In [1844]) use the full hash when checking crypt-ed passwords since some implementations differ in salt values (fixes #1059)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Matt Good.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.