Bugtraq mailing list archives
Re: passwd hashing algorithm
From: jfh () rpp386 cactus org (John F. Haugh II)
Date: Fri, 21 Apr 95 12:00:02 CDT
Yes, but your original message was not specific as to the resulting hash output. Both David Wagner and I understood you to mean that the resulting hash was still only 8 bytes. This was the cause of the potential security hole that he outlined that made an attack significantly easier than searching a single 8 byte hash space. The resulting exchange of messages strongly implied that SecureWare's products contained such a security hole. I was merely stating that our product does not contain this specific security hole (or any other of which I am aware :-)). Our implementation is equivalent to serially searching N 8 byte password hash spaces where N is the number of 8 byte blocks (not limited to two) in the password (except, perhaps for the final block). Of course, it would be even better if they had to crack a single 8*N byte password hash space, but as has been pointed out several times to this list, this should best be done using a real hash function.
My replies have always been in the context of what Shadow does for long passwords. Yes, there has been some confusion in this thread. I was, uh, quite shocked to see what David Wagner was really talking about because it is pretty obvious that it has security problems. Essentially, it removes the 1:1 cleartext to ciphertext relationship that some of us feel crypt() has. I don't know what the new relationship is, but its probably GodAwfulLarge to 1. Once you assume that there are GodAwfulMany passwords which yield the same result, the 2^56 brute force attack is much easier. I am very familiar with how SecureWare implements extended passwords and the strength of them. (Would you like to see a re-implemented version of the source code? ;-) I do think it is a very nice way of chaining crypt blocks together, but it is subject to suffix attacks the same as Shadow and it is at most only 10 times more difficult to crack than straight crypt() (and circa 5 times harder than DOUBLESIZE Shadow). With English words as the alphabet, each block is subject to common word suffix and prefix attacks. crypt() is seriously deficient, sad to say. In the case of Shadow, I never intended longer passwords to do anything but allow for people to use 8 to 10 (or 12 or so) character passwords with all characters being significant, instead of lopping things off at 8 bytes. MD5 is definitely looking to be a much better hash and there will be MD5 support imbedded in the next version of Shadow. -- John F. Haugh II [ NRA-ILA ] [ Kill Barney ] !'s: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 251-2151 [GOP][DoF #17][PADI][ENTJ] @'s: jfh () rpp386 cactus org
Current thread:
- virus, (continued)
- virus Erich W. Gunther (Apr 20)
- Re: virus Leo Bicknell (Apr 22)
- no virus, only a rumor Albert Lunde (Apr 22)
- Re: no virus, only a rumor [good times, xxx-1] Matthew Hannigan (Apr 23)
- Good Times Paul Robinson (Apr 24)
- Re: virus Joshua Hosseinoff (Apr 23)
- Re: virus eli (Apr 23)
- The list Jon Green (Apr 23)
- Re: passwd hashing algorithm John F. Haugh II (Apr 20)
- Re: passwd hashing algorithm Charlie Watt (Apr 21)
- Re: passwd hashing algorithm John F. Haugh II (Apr 21)
- Re: passwd hashing algorithm Timothy Newsham (Apr 21)
- Re: passwd hashing algorithm John F. Haugh II (Apr 23)
- RE: virus Erich W. Gunther (Apr 23)
- Re: passwd hashing algorithm David Miller (Apr 19)
- Re: passwd hashing algorithm David A. Wagner (Apr 19)
- Re: passwd hashing algorithm John F. Haugh II (Apr 21)
- AntiFlash talkd Richard Allen (Apr 19)
- Re: AntiFlash talkd James M. Golovich (Apr 19)
- Password Storage as Environment Variable Bill Bradley (Apr 19)