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

[Michael Samuel]

Hi,

On 5 March 2015 at 01:25, Stephen Frost <sfrost at snowman.net> wrote:
> I was hoping for an option which would actually improve it, not make it
> the same as another mechanism that already exists..

Ok, so my general advice would definitely still be to use "password"
authentication for unix and TLS sockets.  When people move to stronger
password hashing (what's there now is definitely not acceptable by
modern standards), md5 would have to disappear.

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

So you have to consider how many users they can try against too.
Also, locking out a user might be what the attacker wanted.  This is a
dead-end.


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

They may have had access to a staging database, or a backup of the
database (but they want to write to it).  Or another database where
somebody used the same username and password.

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

If you can solve the problem of generating and signing client-side
certificates and making them easy to use in all current clients I'd be
very impressed :)

Unfortunately, the LAMP era has lumped us with passwords and anything
else would cause confusion and delay.

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

I think that'd be a wise move.  The only problem is that your password
hashes are not compatible with SCRAM.  This may be fixable with a
mechanism similar to what I suggested earlier.

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

I recommend reading
http://openwall.info/wiki/people/solar/algorithms/challenge-response-authentication

Regards,
  Michael