Re: OT: password encryption (salt theory)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tim Ellis <Tim(dot)Ellis(at)gamet(dot)com>
Cc: "David F(dot) Skoll" <dfs(at)roaringpenguin(dot)com>, fstefan(at)cable(dot)vol(dot)at, pgsql-admin(at)postgresql(dot)org
Subject: Re: OT: password encryption (salt theory)
Date: 2002-08-22 02:21:44
Message-ID: 200208220221.g7M2LiZ23553@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin


We use salt in our MD5 implementation. One is random and prevents
playback of packets. The second is salt used for storage in pg_shadow.
As long as the salt is visible to the user just like the MD5 version of
the password, we don't see any advantage to a random salt. We use the
username as our salt for storage just so that two people with the same
password don't show the same MD5 output in pg_shadow.

---------------------------------------------------------------------------

Tim Ellis wrote:
> > But a straight md5sum leaves you open to a dictionary attack.
>
> Of course. I argue everything does.
>
> > You want
> > to add some salt by doing something like this:
> >
> > salt = random_4_char_string;
> > encrypted_password = salt + md5sum(salt + cleartext_password);
>
> I've always wondered about this. It just means for a dictionary attack,
> instead of:
>
> if (encpass == md5sum (dictionaryword))
>
> you do
>
> if (encpass == substr(encpass,4)+md5sum(substr(encpass,4)+dictionaryword))
>
> Which obviously is just linearly slower than the normal dictionary attack.
>
> What is the purpose of the salt in this case? I can only assume the
> standard documented of using a salt is wrong, because I've never seen an
> implementation that I could see increased the security over plain
> hashing.
>
> The only way I could see a salt increasing security is thusly:
>
> salt = SomeSuperSlowAlgorithm (password)
> encpass = md5sum (salt + password)
>
> But you'd achieve as much by saying encpass=SuperSlowAlgo(password).
>
> No matter how you obfuscate it, unless you can somehow turn it into a
> O(x^n) problem, you're prone to dictionary attacks.
>
> This is why most modern password-prompting algorithms do a "dictionary
> attack" on your password and worn you. Witness:
>
> Changing password for user postgres.
> New UNIX password: (I enter "greatone")
> BAD PASSWORD: it is based on a dictionary word
>
> So basically, your only hope is to either obfuscate the argument you pass
> to md5sum (or whatever hash algorithm), somehow protect your md5sum list
> of passwords(note that the shadow password file on Unix systems isn't
> world readable), or ensure that all passwords entered by all users are not
> attackable by a dictionary attack.
>
> Can anyone explain to me why a salt is really a good idea or if, as I
> suspect, it was an idea with good intentions that really doesn't help
> anything?
>
> --
> Tim Ellis
> Senior Database Architect
> Gamet, Inc.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message David F. Skoll 2002-08-22 02:25:52 Re: OT: password encryption (salt theory)
Previous Message Mark Stosberg 2002-08-22 02:20:54 Re: Event recurrence - in database or in application code ????