[Pkg-postgresql-public] Bug#779683: Bug#779683: postgresql: pg_hba scripts (mis)configures for MD5 authentication

[Michael Samuel]

Hi,

On 4 March 2015 at 15:22, Stephen Frost <sfrost at snowman.net> wrote:
> 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.

They can already do that if they reconnect 65k times (on average -
this could be fixed by choosing the challenges sequentially instead of
randomly).  But yes, the intent is to make it as secure as the
'password' case.

> 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.

You'd have to store billions for this to be effective without lockout.

> 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.

As I said, you can't make this scheme safe against a network attacker.
They'd be able to dictionary attack the response, or just mess with
the active connection.

> 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.

That is correct.  I'm personally in favour of just using 'password' -
at-least it's honest.  Server-authenticated TLS (eg. verify the server
certificate only) or SSH tunnelling are the best ways to secure the
network protocol as it stands.

Regards,
  Michael