On Wed, Mar 4, 2015 at 12:43:54PM -0500, Stephen Frost wrote: > > What does storing multiple hash(password || stoarage_salt) values do for > > us that session_salt doesn't already do? > > By storing a hash of the result of the challenge/response, we wouldn't > be susceptible to attacks where the user has gained access to the > contents of pg_authid because the values there would not be (directly) > useful for authentication. Today, an attacker can take what's in > pg_authid and directly use it to authenticate (which is what the > interwebs are complaining about). > > We wouldn't want to do that for just a single value though because then > there wouldn't be any value to the challenge/response system (which is > intended to prevent replay attacks where the attacker has sniffed a > value from the network and then uses that value to authenticate > themselves).
So you are storing the password + storage-salt + session-saltX, where X is greater than the maximum number of login attempts? How do you know the attacker will not be given a salt that was already seen before? > The only way we can keep the session salt random without breaking the > wireline protocol is to keep the raw data necessary for authentication > in pg_authid (as we do now) since we'd need that information to recreate > the results of the random session salt+user-hash for comparison. > > This is essentially a middle ground which maintains the existing > wireline protocol while changing what is in pg_authid to be something > that an attacker can't trivially use to authenticate. It is not a I don't understand how this works. -- 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
