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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +