From: | Vince Vielhaber <vev(at)michvhf(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: md5 again |
Date: | 2000-07-11 16:49:32 |
Message-ID: | Pine.BSF.4.21.0007111244340.97059-100000@paprika.michvhf.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 11 Jul 2000, Tom Lane wrote:
> Vince Vielhaber <vev(at)michvhf(dot)com> writes:
> > When PG receives the password, it doesn't know if the password is
> > encrypted or not.
>
> What do you mean it doesn't know if the password is encrypted or not?
> The protocol should tell it. You can't do this without a protocol
> extension...
I was shooting for automatic detection.
>
> > Is there a preference to the method used?
>
> I believe there was a very specific agreement about what the challenge
> and response should be, and none of this looks like it. See the
> discussion about how to have both wire security and encrypted-on-disk
> passwords --- doing both is trickier than it sounds.
>
> As far as the specific mechanics of applying MD5 go, I'd suggest
> concatenating whatever strings need to go into a particular iteration
> with appropriate separators (a null byte would probably do) and applying
> MD5 just once. I can't see any reason to do things like
> MD5(MD5(string1)+MD5(string2)). (IIRC there were places in the proposed
> protocol where you'd be hashing a string previously hashed by the other
> side, but that's not what I'm talking about here. Given particular
> inputs to be combined, it seems sufficient to just concatenate them and
> do one round of MD5.)
>
> > If CL sends the MD5 of the username rather than the plaintext username,
> > only CL and PG will know what the username is. PG will know it by
> > comparing it with the MD5 of every username in pg_shadow. So even if the
> > wire is being sniffed the unhashed username can be used in the password's
> > encryption along with the salt sent by PG. This method will take longer
> > for a user to log in, but the login process is only per session, not per
> > SQL call.
>
> A linear search of pg_shadow to log in is not acceptable; we don't want
> to make login any slower than we have to. I see no real gain in security
> from doing this anyway...
By knowing what PG will do with the username and random salt, sniffing
the wire can make guessing the password trivial. If the username was
never sent over the wire in the clear the unhashed username is an unknown
salt to he who is sniffing. But it's true that it would introduce a
slower than necessary login.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev(at)michvhf(dot)com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2000-07-11 16:49:58 | Re: AW: update on TOAST status' |
Previous Message | Vince Vielhaber | 2000-07-11 16:44:18 | Re: md5 again |