Home page logo
/

bugtraq logo 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 years

We 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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]