Michael, * Michael Samuel (m...@miknet.net) wrote: > On 4 March 2015 at 12:33, Stephen Frost <sfr...@snowman.net> wrote: > > To be clear, I *am* from the PostgreSQL community and I'd be happy to > > discuss any useful suggestions about providing an alternative that > > doesn't break the wireline protocol, because as far as I'm aware that's > > not possible to do. The wireline protocol is quite clear about what it > > requires and we have quite a few client-side implementations to > > consider. > > The way I'd do this is to store a strong hash (eg. bcrypt, scrypt) of > the password pre-digested for the challenge-response protocol with a > fixed challenge. > > The server sends the same challenge every time - this allows replays > of the challenge-response protocol, but means that the stored hash is > reasonably secured and disables pass-the-hash.
That really just changes it back to the 'password' case though, doesn't
it? An attacker who can sniff the network would get the response from
the client and be able to use it in a replay attack just as if it was
the password.
Sure, we could store multiple responses, but given that we don't have
any auto-lockout mechanism after X bad attempts or anything like that,
an attacker could simply continue retrying until we pick the one which
they sniffed.
I realize that's what you were getting at with your replay comment above
but I wanted to re-state it to make sure I understood your suggestion
correctly. While the PG community might be willing to pursue this
approach, I doubt they'd want to seriously increase the size of
pg_authid and, really, to make this work well, how many different stored
hashes would be required for this to be effective at preventing an
attacker who can sniff the network from getting in? We are clearly not
going to store 4 billion entries and I doubt most people would even want
to store more than, say, *10*. Perhaps if we also added an auto-lockout
feature (something I've wanted for quite a while anyway...) this would
work out well.
One advantage of this approach over password is that the attacker
wouldn't be able to get the actual password very easily and so the
sniffed response would only be usable for the given system, but this
definitely reduces the effectivness of the challenge/response aspect, to
a point where I'm not really sure it's still useful.
Thoughts appreciated.
Thanks!
Stephen
signature.asc
Description: Digital signature
