Re: md5 again - Mailing list pgsql-hackers

From Vince Vielhaber
Subject Re: md5 again
Date
Msg-id Pine.BSF.4.21.0007111244340.97059-100000@paprika.michvhf.com
Whole thread Raw
In response to Re: md5 again  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: md5 again  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: md5 again  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 11 Jul 2000, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.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@michvhf.com    http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from
$16.00/moat Pop4 Networking       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================





pgsql-hackers by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: md5 again
Next
From: Bruce Momjian
Date:
Subject: Re: md5 again