I said:
> I think we should try to stick to the current protocol: one salt sent
> by the server, one crypted password sent back. The costs of changing
> the protocol will probably outweigh any real-world security gain.
Actually, since libpq handles the authentication phase of connection
via a state-machine, it'd be possible for the postmaster to send two
successive authentication challenge packets with different salts, and
libpq would respond correctly to each one. This is a little bit shaky
because the current protocol document does not say that clients should
loop at the challenge point of the protocol, so there might be non-libpq
clients that wouldn't cope. But it's possible we could do it without
breaking compatibility with old clients.
However, I still fail to see what it buys us to challenge the frontend
with two salts. If the password is stored crypted, the *only* thing
we can validate is that password with the same salt it was stored
with. It doesn't sound like MD5 changes this at all.
regards, tom lane