Re: passwd hashing algorithm

[watt () sware com (Charlie Watt)]

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-CLEAR
Content-Domain: RFC822
Originator-Certificate:
 MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ
 BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
 Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx
 NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T
 ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL
 Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB
 AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL
 X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF
 AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+
 8lqrLQ7YpTzyE74pKR1cl5TAUU4=
Issuer-Certificate:
 MIIBkDCCAToCEQCFP7oDPZq0SSDfetbu5nSkMA0GCSqGSIb3DQEBAgUAMEAxCzAJ
 BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl
 Y3VyZVdhcmUgUENBMB4XDTk0MDQwNTE3MDQyM1oXDTk1MDQwNTE3MDQyM1owWTEL
 MAkGA1UEBhMCVVMxGDAWBgNVBAoTD1NlY3VyZVdhcmUgSW5jLjEXMBUGA1UECxMO
 U2VjdXJlV2FyZSBQQ0ExFzAVBgNVBAsTDkVuZ2luZWVyaW5nIENBMFkwCgYEVQgB
 AQICAgADSwAwSAJBAL4Od/KxhOB6HyUbBJC2X6Ic2P0XEcGnddzJ1QEHjSFyx5qz
 n098ScMWDEJSiwrsVmQFbNvN01hkke7ZE21aG5sCAwEAATANBgkqhkiG9w0BAQIF
 AANBAIBzwWRF5SkoGAdcliVyog2caFtsPrq7lyBIp562B+ckFNderoDTc+JW+i4f
 MhnY9Q9I2KrlZV4GqcpZ+GjAeNk=
MIC-Info: RSA-MD5,RSA,
 A9VvxUJFlZ+UyrP+FQV+UauZKzzjYG0BGEwbe/QKYPiUZm6lRhHMuGIqgSacp1JR
 tjKiIpYbg/r7pgBXEehhwW0=

X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED
X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED

> > > 1. 25 iterations of DES with the first 8 bytes of the
> > >    password as key, followed by 25 iterations of DES
> > >    with the second 8 bytes of password as key.
>    [ ... better version deleted ... ]
> > > (1) can be broken on a workstation with ~ 2^32 steps (and
> > > very little in the way of memory);
> >
> > I've never seen anything resembling a convincing argument for this point.
>
> Hrmm, well, I could give you the crypto explanation...do you
> want me to?  [Keywords: meet-in-the-middle, birthday attack]

....

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

> Good lord!  Can anyone give more details?  [ The details
> tend to matter in this business: something similar but
> slightly different might be safe. :-) ]
>
> Sorry to the rest of you bugtraq folks: I would be taking
> this to personal email, except for the fact that someone
> actually uses the broken scheme -- yikes! -- that's my ObBug.

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.

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:

watt:u_name=watt:u_id#124:\
        :u_pwd=8F0Ovkj7jA9jE.ofsJ4MaIt6:\

Charles Watt
SecureWare, Inc.

-----END PRIVACY-ENHANCED MESSAGE-----