From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vince Vielhaber <vev(at)michvhf(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, "Sverre H(dot) Huseby" <sverrehu(at)online(dot)no>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: So we're in agreement.... |
Date: | 2000-05-07 20:11:34 |
Message-ID: | 3915CDF6.7A1E8EF8@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Tom Lane wrote:
>
> Vince Vielhaber <vev(at)michvhf(dot)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.
It allows one of the salts to never be sent, thereby strengthening that
part against _anyone_sniffing_the_traffic_ (just a little) as he sees
only one hash, different each time.
It allows _a_user_with_access_to_ pg_shadow _on_two_or_more_machines_
see the fact that a user has the same password on both of them (which
info he can then useto guess the password in two tries, as often seen
in movies ;)
> If you don't see that this is so then you don't understand anything
> about cryptography.
It is too easy to think that you do ;).
BTW, I don't claim to "understand cryptography" .
What I said above is just plain common sense ;)
And you will never get good security by cryptography only, not even
by using SSL or SSH which are the right way to go if you want to protect
against sniffing.
The current thread started from a simple the need to hide passwords
from PG superusers and system ROOT's. For that we have two schemes:
store MD5(username+passwd)
- hidden from sniffing but easily guessable salt (as most users are
called 'bob')
store MD5(random_salt+password) , or more likely
random_salt+MD5(random_salt+passord)
or we will never find out the salt again ;)
- both salts are known to sniffer who is still unable to do anything
with them
the difference between the two in mainly the fact that in first case the
user
already knows the salt and in the second case it must be transferred to
her
over fire - this makes the first one stronger, at least in case when the
username is chosen as creatively as the password ;)
otoh, in the second case three things should match username, salt and
hash
which of course makes the second case stronger.
If you understand which one is stronger you are smarter than I am ;)
--------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-05-07 20:19:04 | Re: You're on SecurityFocus.com for the cleartext passwords. |
Previous Message | Tom Lane | 2000-05-07 19:34:09 | Re: So we're in agreement.... |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2000-05-07 20:19:04 | Re: You're on SecurityFocus.com for the cleartext passwords. |
Previous Message | Tom Lane | 2000-05-07 19:34:09 | Re: So we're in agreement.... |