Re: Hashed PW's more secure than encrypted PW's?

From: Juha Laiho (Juha.Laiho@iki.fi)
Date: 06/18/02 

From: Juha Laiho <Juha.Laiho@iki.fi>
Date: Tue, 18 Jun 2002 19:07:01 GMT

"sakky" <sakhalinrf@hotmail.com> said:
>"Matti Juhani Kurkela" <Matti.Kurkela@hut.fi> wrote in message
>> The salt is used in the algorithm to keep people from noticing that
>> user A and user B have the same password. (Remember, the Unix
>> passwords used to be stored in a file readable by anyone.)
>> If the salt is different, the encryption result is completely
>> different even if the actual plain-text password is the same.

>So then this salt must be in plain text somewhere. Where would it be?
>Can I see it?

>> The salt and the encrypted string are then stored in the password
>> file. The (hopefully only) place the encryption key is stored is
>> inside joeblogg's head.

So, as Matti said, the salt is stored in the password file. On the
traditional systems without shadow passwords, this would be /etc/passwd,
readable by any user on the system. The salt is the two first
characters in the password field. On more modern systems, this same
information would be tucked away in /etc/shadow, which tends to be
readable only by root. As a corollary to this, only processes with
root privileges can verify user passwords. This was a problem for
a while, until someone came up with the idea of calling a root-
privileged helper process. The helper process checks the user id
of the calling process, and allows verification of password for
that account (so f.ex. screen saver processes could be run with
user privileges instead of root, and still be able to access system
passwords - but in a limited fashion).

>> Some modern Unix password systems allow the MD5 algorithm used in
>> stead of the old DES. MD5 is a message-digest algorithm, i.e. it
>> produces a fixed-length, cryptographically secure "digest" from any
>> input. There should be no easy way to go backwards through the
>> algorithm and recover the original input from the digest. MD5 does not
>> need any "encryption key" as such.
>
>Would you happen to know some examples of some Unix flavors that do it
>this way as opposed to DES?

At least many Linux distributions have this option. I seem to recall
that AIX can also use MD5-hashed passwords. Solaris does not, and
neither HP-UX (feel free to correct). Also the open-soure BSD variants
(all? some?) are able to use MD5-hashed passwords.

I think there's also been talk about moving on to SHA1-hashes.

>> As far as I know, when using MD5 for Unix password storage, a salt
>> string is also used.
>
>Which field is the salt?

At least it looks like it would be part of the md5 shadow password
field:

jlaiho:$1$WQzZs59t$ZZ5EUjeKTt.Ih6msFRB8h.:11856:0:99999:7:::

So, the second field is the md5 hash; I think the '$1$' is just some kind
of constant tag to signify that this is md5 hash entry (so you could
have traditional DES entries and md5 entries mixed in a single password
file). Then the 'WQzZs59t' would be my guess for the salt, which would
leave the 'ZZ5EUjeKTt.Ih6msFRB8h.' as the md5 result. My guess for the
encoding used here would be base64.

>> The advantage of MD5 is that it allows using passwords of any length
>> with no complications in the algorithm. With DES, there is no obvious
>> standard way to use a longer password. (Would you use a longer string
>> of zeroes, and if so, how the length is chosen? Or would you split the
>> password in 8-character parts and use different parts as the
>> encryption key in different rounds of the DES algorithm? Or any
>> combination of these? Or something else entirely?)

Actually I think there was a slight security issue wrt the old "shadow
password suite"; there long passwords were implemented by splitting the
password into a maximum of two 8-character parts, then using a single
salt to run DES on both of these parts. Now, as it was a good guess that
the long passwords might be 10-11 characters long (more probably than
16), it was attempted that the latter part was cracked first -- just
brute-force through all 1-3 -character combinations to see what you
get. Then start the dictionary/brute force attack on the initial
8 characters, but dropping all the candidates that didn't fit into the
already cracked pattern. As I understand, this did somewhat help the
dictionary attack side - but naturally didn't help much the brute
force attack (except by providing the fact that the key length for
the first part is exactly 8 characters). 

-- 
Wolf  a.k.a.  Juha Laiho     Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Relevant Pages

  • Re: Hashed PWs more secure than encrypted PWs?
    ... How does MD5 work for this? ... > DES is not a public/private-key algorithm. ... > system encrypts a string of zeroes using a random salt ... The place the encryption key is stored is ...
    (comp.security.unix)
  • Re: Hashed PWs more secure than encrypted PWs?
    ... How does MD5 work for this? ... > DES is not a public/private-key algorithm. ... > system encrypts a string of zeroes using a random salt ... The place the encryption key is stored is ...
    (comp.security.unix)
  • Re: MD5 and DES with SALT
    ... ]Are there any free .dll files that can encrypt strings with a SALT for ... ]MD5 and DES (just like passwords in the passwd file for linux, ...
    (sci.crypt)
  • MD5 and DES with SALT
    ... Are there any free .dll files that can encrypt strings with a SALT for ... MD5 and DES (just like passwords in the passwd file for linux, ...
    (sci.crypt)
  • Re: Hashed PWs more secure than encrypted PWs?
    ... >> If the salt is different, ... MD5 is a message-digest algorithm, ... >this way as opposed to DES? ...
    (comp.security.unix)