On Wed, Mar 4, 2015 at 01:27:32PM -0500, Stephen Frost wrote: > This further makes what is sent over the network not directly > susceptible to a replay attack because the server has multiple values > available to pick for the salt to use and sends one at random to the > client, exactly how our current challenge/response replay-prevention > system works. The downside is that the number of possible values for > the server to send to prevent replay attacke is reduced from 2^32 to N.
OK, I understand now --- by not using a random session salt, you can store a post-hash of what you receive from the client, preventing the pg_authid from being resent by a client. Nice trick, though going from 2^32 to N randomness doesn't seem like a win. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers