* Robert Haas (robertmhaas@gmail.com) wrote:
> So, the server can only authenticate the user with the salts it has
> stored, because those are the only salts for which it knows what the
> response should be?
That's correct- except that it doesn't directly know what the response
is, it only knows what the result of hashing the response with the
information provided by the client is.
> But then if somebody steels pg_authid, they'll
> have the answers to the exact same set of questions that the server
> knows how to ask.
Not quite. They can't provide what's in pg_authid as an authentication
token in this case; that's the main thrust of this change from what is
in pg_authid today. They would know which of the challenges are able to
be sent to the client and the result of hashing that with what they
actually need to send as an auth token to the server, but that's no
easier than today's unix password-based /etc/shadow approach where even
if you know the "answer" (in the form of the salt and the resulting
hash), you can't trivially provide the token needed to authenticate (the
password).
> And on top of that, replay attacks become massively
> easier. Any value you pick for X is going to be many orders of
> magnitude smaller than 4 billion, and if it's not entirely trivial
> you'll also have a huge expansion of the size of a pg_authid row.
This is correct, as I was discussing with Bruce, replay attacks would
certainly require fewer attempts, though it's not like it'd take long to
do ~16k connection attempts today (how many you'd actually need to
attempt to have a high probability of getting in successfully with our
existing 4-byte salt).
Thanks!
Stephen