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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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