Bugtraq mailing list archives
Re: passwd hashing algorithm
From: pcl () foo oucs ox ac uk (Paul C Leyland)
Date: Fri, 21 Apr 1995 14:56:15 +0100
SecureWare uses a mechanism similar to this and it is part of one of their security offerings. I've used a slightly different, but similar, approach for several yearsWe do not. See below.I think the confusion lies in "similar". Otherwise, I stand by my remarks, source code samples from you not withstanding.This is most certainly NOT SecureWare's password implementation, although I can understand why there might be some confusion. SecureWare has modified the behavior of password hashing not to increase the strength of the underlying crypt(), but to increase the size of the possible password space and the resulting hash value. The algorithm breaks a password into crypt- sized blocks, running crypt() across each block. The salt for each block is derived from the ciphertext of the previous block to provide linkage between the individual blocks. The resulting hash is the concatenation of the various ciphertext blocks, prefixed with the initial salt.Yes. You use crypt() once for each block of 8 characters. This is what was described. 25 rounds of DES (one crypt()) with the first crypt()-sized block followed by 25 rounds of DES (one crypt()) with the second crypt()-sized block. As I understand the algorithm, the salt is the last 2 ciphertext characters of the previous encrypted result.
A sudden attack of deja vu strikes! Remember I said that I'd lost the code for re-implementing OSF/1's bigcrypt() routine? The above paragraph describes it exactly. My re-discovery was by changing my password to known values and then running exhaustive search on all salts to see what had been used for the second block. Earlier experiments had shown that the password was hashed in units of 8 characters, any one block being independent of later blocks.
This strong mechanism, combined with shadow password files and configurable password controls (random pronounceable password generator, password aging, minimum allowable lengths, attack detection and account lockout, etc...) allow a system security officer to be as paranoid as they choose -- e.g., passwords can be configured to look like standard Unix, they can be configured to be 128 byte random passwords, or they can be configured somewhere in between. As an example, my password is between 8 and 16 bytes long. Its entry in the shadow password database looks like:
Agreed, it permits long passwords. It also permits the length of the password to be determined to within 8 characters by inspection of the hashed password, and it enables the suffix attack to be employed. A better implementation would have had the hash size independent of the password length, and all bits of the hash depending on all bits of the password. At least it's better than crypt16() Paul
Current thread:
- Re: passwd hashing algorithm, (continued)
- 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)
- Re: passwd hashing algorithm John Adams (Apr 17)
- Re: passwd hashing algorithm Paul C Leyland (Apr 19)
- Re: passwd hashing algorithm Paul C Leyland (Apr 20)
- Re: passwd hashing algorithm John F. Haugh II (Apr 23)
- Re: passwd hashing algorithm Marek Michalkiewicz (Apr 24)
- Re: passwd hashing algorithm Paul C Leyland (Apr 21)
- Re: passwd hashing algorithm Pete Hartman (Apr 24)