Vince Vielhaber <vev@michvhf.com> writes:
> My intent was not to send the username, but let the server figure it
> out by the response.
That would be a neat trick. How will you do it? MD5 is not reversible.
Actually you could do it, but *not* by folding the username into the
password. Instead try this:
1. Client chooses random saltC, sends saltC and MD5(username, saltC)
to server in initial request.
2. Server runs through all available usernames, computing
MD5(thisusername, saltC) for each one and looking for a match.
3. Server chooses random saltS, sends it to client along with saltP
stored in pg_shadow entry for user.
4. Client computes MD5(MD5(password, saltP), saltS) and sends to server.
Server compares this against MD5(stored hashed password, saltS).
This would prevent a sniffer from finding out anything about the valid
usernames, which'd be a useful improvement, but I'm not convinced that
it's worth breaking the initial protocol for. (Not to mention the
additional postmaster CPU time --- step 2 above is not cheap if there
are lots of usernames.) So far we have just been talking about adding
a different type of authentication challenge to the set we already
support; that doesn't break old clients as long as they aren't
challenged that way. Modifying the initial connection request packet
is a different story.
I'm still of the opinion that anyone who is really concerned about
sniffing attacks ought to be using SSL, because protecting just their
password and not the data that will be exchanged later in the session is
unwise. So I'm not really excited about adding anti-sniffing frammishes
like this one. We've got a good scheme for the password; let's be
careful about adding "improvements" that won't carry their weight in
the real world. There's no such thing as a single security scheme that
addresses every possible vulnerability. Extending one part of your
security arsenal to partially solve problems that are better solved
by a different tool is just wasting time.
regards, tom lane
