Thread: md5 again
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.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 ==========================================================================
> 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, Pennsylvania19026
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.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 ==========================================================================
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 ==========================================================================
> 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, Pennsylvania19026
> 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
> > > 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, Pennsylvania19026
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.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 ==========================================================================
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
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
> > > 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, Pennsylvania19026
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.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 ==========================================================================
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, Pennsylvania19026
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.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 ==========================================================================
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.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 ==========================================================================