Re: So we're in agreement.... - Mailing list pgsql-hackers

From Tom Lane
Subject Re: So we're in agreement....
Date
Msg-id 19075.957728049@sss.pgh.pa.us
Whole thread Raw
In response to Re: So we're in agreement....  (Vince Vielhaber <vev@michvhf.com>)
Responses Re: So we're in agreement....  (Vince Vielhaber <vev@michvhf.com>)
Re: So we're in agreement....  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
Vince Vielhaber <vev@michvhf.com> writes:
> You're right, it wouldn't work.  It should've been like this:

> CLIENT: md5(salt_from_server + md5(username + password)))

> SERVER: md5(salt_from_server + stored_password) 

> The "salt_from_server" is your random salt.  The fixed salt is the
> username.

You're still not getting the point.  I refer you to Ben Adida's
original, correct description of the way to do this:

> - client requests login
> - server sends stored salt c1, and random salt c2.
> - client performs hash_c2(hash_c1(password)) and sends result to server.
> - server performs hash_c2(stored_pg_shadow) and compares with client
>   submission.
> - if there's a match, there's successful login.

There have to be *two* random salts involved, one chosen when the
password was set (and used to cloak the stored password against people
with access to pg_shadow) and one chosen for the duration of this
password challenge (and used to cloak the challenge transaction against
people sniffing the packet traffic).  If you give up either one of those
bits of randomness then you lose a great deal.

Using the username instead of an independent random value to salt the
stored password is not a small change, it is a fundamental weakening of
the security system.  If you don't see that this is so then you don't
understand anything about cryptography.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: So we're in agreement....
Next
From: Hannu Krosing
Date:
Subject: Re: You're on SecurityFocus.com for the cleartext passwords.