search

openwall / john

John the Ripper jumbo - advanced offline password cracker, which supports hundreds of hash and cipher types, and runs on many operating systems, CPUs, GPUs, and even some FPGAs
https://www.openwall.com/john/
Other
10.14k stars 2.08k forks source link

Add support for crypt(md5($p)) hashes #1884

Open kholia opened 8 years ago

kholia commented 8 years ago

http://developer.sugarcrm.com/2012/05/16/new-for-sugar-6-5-stronger-password-storage-encryption/

@jfoug is this something that can be handled (in the future) with the dynamic format?

I don't want to write yet another format for this :-)

magnumripper commented 8 years ago

"Crypted passwords will be stored in the database prefixed by a dollar sign ($)."

Does PHP crypt() always, or sometimes, mean descrypt? Or could it be anything the host supports? If it's descrypt, it's a pretty bad decision as it will imply 7-bit and truncation at length 8...

magnumripper commented 8 years ago

crypt() will return a hashed string using the standard Unix DES-based algorithm or alternative algorithms that may be available on the system.

kholia commented 8 years ago

https://hashcat.net/trac/ticket/674 has more details.

Sample HASH : $1$3fq2tzVK$7mN43lNuweG9oJ/QxRq471 = hashcat

magnumripper commented 8 years ago

Sample HASH : $1$3fq2tzVK$7mN43lNuweG9oJ/QxRq471 = hashcat

If that sample is correct it implies that there's actually no $ added by SugarCRM, it comes from crypt(3). So it won't be there for DES?

_We upgraded from SugarCRM Enterprise 6.4.1 to 6.5.10 and discovered that newly entered or reset passwords did not work. After much head-scratching we realized that the new crypt() passwords exceed the old MD5 32-character length and were being truncated by the database. Changing the users.userhash column from varchar(32) to varchar(64) fixed it.

I guess this implies that the actual hash used will depend on what the host OS' crypt(3) defaults to (and in this case it was md5crypt). So for modern Linux, it will probably be sha512crypt.

kholia commented 8 years ago

Seems that way! It's weird to choose "crypt(3)" in modern age :)

jfoug commented 8 years ago

Not really weird. This is often done to quickly 'fix' a terrible prior choice in password hashing (like the raw md5 which this appears to be hiding).

if you have 1000's of users in a DB (or more), and your 'expert' doing the password code chose raw-md5, and later during an audit this is found, it is much easier to simply wrap the original hash in a better algorithm and be able to actually convert the entire DB of passwords into the 'better' hash. The other alternative, is to scrub the DB of all prior hashes, and have 1000's of users calling the help desk to get password resets or to help them log in.

This type 'fix' is done more often than you think.

crypt(3) if is is md5crypt or better, is perfectly fine as a current password hash. The new sha(512)|(256)crypt are also plenty good descrypt would suck for this, especially if the hash is des(md5_base16($p)) (I am not sure if it is raw or base-16) since in that case the entire 'dictionary' would be 16^8 (which is only 4 billion!!!)

magnumripper commented 8 years ago

That's why it is a terrible choice: crypt(3) doesn't really guarantee anything but DEScrypt - and DEScrypt in this case would be even worse than the original raw md5: We would exhaust the entire keyspace in five seconds on a Titan X.

They should have picked PBKDF2-HMAC-SHA1 or better.