Re: md5 again

On Tue, 11 Jul 2000, Tom Lane wrote:

> Vince Vielhaber <vev(at)michvhf(dot)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(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
==========================================================================