
Since I broke my table on hub and am awaiting assistance I'm shifting
away from the website temporarily and back to the md5 stuff.  In going
over the previous conversations I've come up with the following:


The client can be sending the password in either plain text or in 
hashed form with one of the two scenarios for a login process:

direction	what
----------------------------------------------
CL -> PG	username
PG -> CL	random salt
CL -> PG	plaintext passwd


CL -> PG	username
PG -> CL	random salt
CL -> PG	encrypted passwd


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

When PG receives the password, it doesn't know if the password is
encrypted or not.  It checks first plaintext matching, then encrypted
matching using the random salt it sent to CL.

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

Possible encryption methods:

MD5(password+salt)

MD5(MD5(password) + MD5(salt))

MD5(password+salt)

MD5(MD5(username+password)+salt)

MD5(MD5(username+password)+MD5(salt))

MD5(MD5(username+password+salt))

and many others.

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

Is there a preference to the method used?

Also while thinking about this and the vulnerability of the wire itself, 
I've also come up with something that may enhance the login security.

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.  

Comments?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 10:50:20 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
md5 again
> direction	what
> ----------------------------------------------
> CL -> PG	username
> PG -> CL	random salt
> CL -> PG	plaintext passwd
> 
> 
> CL -> PG	username
> PG -> CL	user salt 
^^^^^^^^^^^^^^^^^^^^^^^^^
> PG -> CL	random salt
> CL -> PG	encrypted passwd
> 


MD5(MD5(username+user_salt)+random_salt)

Postmaster takes its pg_shadow MD5(username+user_salt) and does another
MD5 with the random salt and compares it with what was sent from the
client.

If the connection is defined as requiring crypt or password, only this
MD5 method can be used.  If trusted is defined, cleartext passwords can
be accepted.

Don't bother encrypting the username.  No security is gained.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 11 Jul 2000 11:00:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: md5 again
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...

> 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...

			regards, tom lane

Tue, 11 Jul 2000 12:32:16 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: md5 again 
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> MD5(MD5(username+user_salt)+random_salt)

> Postmaster takes its pg_shadow MD5(username+user_salt) and does another
> MD5 with the random salt and compares it with what was sent from the
> client.

Doesn't seem quite right ... where's the password?

			regards, tom lane

Tue, 11 Jul 2000 12:33:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: md5 again 
On Tue, 11 Jul 2000, Tom Lane wrote:

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > MD5(MD5(username+user_salt)+random_salt)
> 
> > Postmaster takes its pg_shadow MD5(username+user_salt) and does another
> > MD5 with the random salt and compares it with what was sent from the
> > client.
> 
> Doesn't seem quite right ... where's the password?

I had assumed Bruce was referring to the password with user_salt. 

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 12:44:18 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again 
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.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
==========================================================================




Tue, 11 Jul 2000 12:49:32 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > MD5(MD5(username+user_salt)+random_salt)

Sorry, it is:

	MD5(MD5(password+user_salt)+random_salt)

> 
> > Postmaster takes its pg_shadow MD5(username+user_salt) and does another
> > MD5 with the random salt and compares it with what was sent from the
> > client.
> 
> Doesn't seem quite right ... where's the password?
> 
> 			regards, tom lane
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 11 Jul 2000 12:49:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: md5 again
> > > 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.
> 

Does it?  I thought it was the password being run through MD5 that made
it secure.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 11 Jul 2000 12:51:28 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: md5 again
> 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.  

 But don't forget that some web application need fast log. And if is not
possible use persisten connection is necessary log for each access to web
page. (...etc.).

 The log speed is keep tracked feature too. 

						Karel					


Tue, 11 Jul 2000 18:51:46 +0200 (CEST)
Karel Zak <zakkr@zf.jcu.cz>
Re: md5 again
On Tue, 11 Jul 2000, Bruce Momjian wrote:

> > > > 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.
> > 
> 
> Does it?  I thought it was the password being run through MD5 that made
> it secure.

Simple dictionary passwords.  Run them thru a script and compare the 
output.  

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 12:56:29 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again
Vince Vielhaber <vev@michvhf.com> writes:
> By knowing what PG will do with the username and random salt, sniffing 
> the wire can make guessing the password trivial.

Not if the wire protocol is done correctly, ie, passwords are only
sent in hashed form.

			regards, tom lane

Tue, 11 Jul 2000 13:01:26 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: md5 again 
> > > 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.
> > > 
> > 
> > Does it?  I thought it was the password being run through MD5 that made
> > it secure.
> 
> Simple dictionary passwords.  Run them thru a script and compare the 
> output.  

I see.  In the past, they couldn't see the password salt.  Now they can
see both salts, both random and password.  Seems they can't use a
dictionary for the random salt to figure out the MD5 version of the
password, can they, because they have to crack that before doing the
password part.  We are are really double-encrypting it, like
tripple-DES.


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 11 Jul 2000 13:07:21 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: md5 again
Vince Vielhaber <vev@michvhf.com> writes:
> Simple dictionary passwords.  Run them thru a script and compare the 
> output.  

I was under the impression we'd prevented that by use of a random salt
chosen on-the-fly for each login attempt ... have to go reread the
thread to be sure though.

In any case, if your threat model is a dictionary attack, what's to
stop the attacker from using a dictionary of likely usernames as well?
I still don't see much security gain from hashing the username.

			regards, tom lane

Tue, 11 Jul 2000 13:07:59 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: md5 again 
On Tue, 11 Jul 2000, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > Simple dictionary passwords.  Run them thru a script and compare the 
> > output.  
> 
> I was under the impression we'd prevented that by use of a random salt
> chosen on-the-fly for each login attempt ... have to go reread the
> thread to be sure though.

When I went back and reread the thread, it was PG sending the random
salt.  The username, password and random salt were hashed and sent 
back.  Therefore the username and random salt have both been on the
wire in the clear.

> In any case, if your threat model is a dictionary attack, what's to
> stop the attacker from using a dictionary of likely usernames as well?
> I still don't see much security gain from hashing the username.

dictionary of likely usernames: tgl, vev, buzz, wood_tick, ...  Now
that'd be a dictionary!  If only the random salt were on the wire, the
attacker would need to guess both the username and the password.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 13:23:51 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again 
Vince Vielhaber <vev@michvhf.com> writes:
>>>> Simple dictionary passwords.  Run them thru a script and compare the 
>>>> output.  

> When I went back and reread the thread, it was PG sending the random
> salt.  The username, password and random salt were hashed and sent 
> back.  Therefore the username and random salt have both been on the
> wire in the clear.

Hmm.  So if you sniffed the transaction you'd have all the info needed
to verify a guess at a password.  It would be nice to improve on that.

However, I thought we'd settled on a protocol that involved multiple
random salts being chosen on-the-fly, so the above doesn't sound like
the right thing...

>> In any case, if your threat model is a dictionary attack, what's to
>> stop the attacker from using a dictionary of likely usernames as well?

> dictionary of likely usernames: tgl, vev, buzz, wood_tick, ...  Now
> that'd be a dictionary!

No bigger than a dictionary of likely passwords, and furthermore you
may have good reason to guess a username based on outside info (eg,
where the connection is coming from).  A sniffer who's attacking a
particular database probably has some idea who its users are, and
usernames are not customarily hidden carefully.

> If only the random salt were on the wire, the
> attacker would need to guess both the username and the password.

And so would the postmaster ;-).  The problem here is that the hashed
username has to be sent, and there can be no hidden salt involved
since it's the first step of the protocol.  So the attacker knows
exactly what the hashed username is, and if he can guess the username
then he can verify it.  Then he moves on to guessing/verifying the
password.  I still don't see a material gain in security here, given
that I believe usernames are likely to be pretty easy to guess.

			regards, tom lane

Tue, 11 Jul 2000 13:52:23 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: md5 again 
> And so would the postmaster ;-).  The problem here is that the hashed
> username has to be sent, and there can be no hidden salt involved
> since it's the first step of the protocol.  So the attacker knows
> exactly what the hashed username is, and if he can guess the username
> then he can verify it.  Then he moves on to guessing/verifying the
> password.  I still don't see a material gain in security here, given
> that I believe usernames are likely to be pretty easy to guess.

Just do a 'ps' and you have the username for each connection.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 11 Jul 2000 13:58:56 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: md5 again
On Tue, 11 Jul 2000, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> >>>> Simple dictionary passwords.  Run them thru a script and compare the 
> >>>> output.  
> 
> > When I went back and reread the thread, it was PG sending the random
> > salt.  The username, password and random salt were hashed and sent 
> > back.  Therefore the username and random salt have both been on the
> > wire in the clear.
> 
> Hmm.  So if you sniffed the transaction you'd have all the info needed
> to verify a guess at a password.  It would be nice to improve on that.
> 
> However, I thought we'd settled on a protocol that involved multiple
> random salts being chosen on-the-fly, so the above doesn't sound like
> the right thing...

The salts have to go over the wire.  If the user chooses a salt, adds it
to his password and MD5's it with the salt we send, how do we get the
user's salt?  I guess we can already have it stored but that doesn't
seem right.  The only scenario from the previous thread involved a
reversible (or at least somewhat reversible) encryption method, not md5
which is a hash.

> 
> >> In any case, if your threat model is a dictionary attack, what's to
> >> stop the attacker from using a dictionary of likely usernames as well?
> 
> > dictionary of likely usernames: tgl, vev, buzz, wood_tick, ...  Now
> > that'd be a dictionary!
> 
> No bigger than a dictionary of likely passwords, and furthermore you
> may have good reason to guess a username based on outside info (eg,
> where the connection is coming from).  A sniffer who's attacking a
> particular database probably has some idea who its users are, and
> usernames are not customarily hidden carefully.
> 
> > If only the random salt were on the wire, the
> > attacker would need to guess both the username and the password.
> 
> And so would the postmaster ;-).  The problem here is that the hashed
> username has to be sent, and there can be no hidden salt involved
> since it's the first step of the protocol.  So the attacker knows
> exactly what the hashed username is, and if he can guess the username
> then he can verify it.  Then he moves on to guessing/verifying the
> password.  I still don't see a material gain in security here, given
> that I believe usernames are likely to be pretty easy to guess.

The postmaster would have a pretty good idea, the username could even
be hashed with the same salt we send for the password, but this part
is rather moot since it would undoubtedly increase the login time beyond
an acceptable delay.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 15:27:11 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again 
On Tue, 11 Jul 2000, Bruce Momjian wrote:

> > And so would the postmaster ;-).  The problem here is that the hashed
> > username has to be sent, and there can be no hidden salt involved
> > since it's the first step of the protocol.  So the attacker knows
> > exactly what the hashed username is, and if he can guess the username
> > then he can verify it.  Then he moves on to guessing/verifying the
> > password.  I still don't see a material gain in security here, given
> > that I believe usernames are likely to be pretty easy to guess.
> 
> Just do a 'ps' and you have the username for each connection.

True, but I was more concerned with remote sniffing.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.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
==========================================================================




Tue, 11 Jul 2000 15:28:49 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: md5 again