Modify

Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#1059 closed defect (fixed)

HtPasswdStore doesn't recognize Blowfish hashes

Reported by: anonymous Owned by: mgood
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 8 years ago.
Htpasswd on FreeBSD Sparc

Download all attachments as: .zip

Change History (8)

Changed 8 years ago by anonymous

Htpasswd on FreeBSD Sparc

comment:1 Changed 8 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 8 years ago by mgood

  • Keywords needinfo added
  • Summary changed from HtPasswdStore doesn't work to 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 8 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 8 years ago by mgood

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

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

comment:6 in reply to: ↑ 5 Changed 8 years ago by mgood

  • Keywords needinfo removed
  • Status changed from new to assigned

Replying to anonymous:

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

Thanks for helping debug this.

comment:7 Changed 8 years ago by mgood

  • Resolution set to fixed
  • Status changed from assigned to closed

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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.