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

[Stephen Frost]

Michael,

* Michael Samuel (mik at miknet.net) wrote:
> 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.

I was hoping for an option which would actually improve it, not make it
the same as another mechanism that already exists..

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

To make it better than password and effective *with* a lockout we'd
still have to store quite a few random options, no?  Even with a
3-strike lockout (which is a bit agressive, imv..), wouldn't you need to
store 27 or more variations to keep the probability of success inside of
those 3 attempts acceptably low?

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

I agree that there isn't much we can do for the active connection but
that's at least more likely to be noticed.  If this approach isn't
effective to deter a network attacker, then what are we protecting with
this?  If they have access to pg_authid, it's highly likely they have
access to all of the data in the database also.

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

PG supports client-side certificate based authentication which would be
far better than any kind of password-based authentication.  If password
based auth is insisted upon then TLS to verify the server-side and
protect the network connection would be good and remove the need for the
challenge/response protocol and lead to 'password' being an acceptable
option there, but that doesn't mean it'd be a good default for Debian,
imv, because we *don't* require server-authenticated TLS, or TLS at all,
currently.  Further, I'm not convined that 'password' there would really
be all that much better than 'md5' as, as has been discussed, if you
have access to pg_authid then you have access to the PG data directory.
Further, at that point, you've probably got access to the backend and
with password-based auth the postmaster process will see the user's
actual password.

In the end, I think we might move to support SCRAM and simply deprecate
md5 in favor of that rather than try to fix the current mechanism
without breaking things because any such fix wouldn't be a serious
improvement and would just mislead users into thinking it's safe.

We're currently looking at getting SCRAM support by implementing SASL,
but I'm worried that we'll then create a dependency on SASL that people
won't be happy with and therefore I'm very curious about how difficult
it'd be to implement proper SCRAM directly.  Do you know if there is
BSD-licensed code (PG is entirely BSD licensed) that implements SCRAM?

	Thanks!

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/attachments/20150304/042f8786/attachment.sig>