Re: passwd hashing algorithm

[pcl () foo oucs ox ac uk (Paul C Leyland)]

> > > > 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