* Robert Haas (robertmh...@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
Description: Digital signature