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