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

[Michael Samuel]

Hi,

On 4 March 2015 at 12:33, Stephen Frost <sfrost at snowman.net> wrote:
> * Michael Samuel (mik at miknet.net) wrote:
>> - I don't recommend storing the password in cleartext
>> - I *do* recommend exchanging the password in cleartext over the network
>
> And I will continue to argue that it's far worse these days to send the
> password in cleartext across the wire.

For Unix and server-authenticated TLS sockets, this is a clear loss.
For cleartext sockets, you're going to have a very bad day if there's
a network attacker, regardless of authentication protocol.


> Where would they get the pg_authid entry from?  It's not directly
> visible in the network traffic because PG using a challenge/response
> system with md5.

>From an old backup tape, a stolen hard drive, SQL injection (or is
this no longer viable?).  This is the reason why the stored password
is hashed in the first place :)

But a fair point - it would be much easier to go from sniffing
challenge-response to cleartext than it would to get the intermediate
hash.

> No, it isn't a great challenge/response, but it's certainly better than
> just forgoing all of that and sending the password in cleartext.

See above...

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

> Note that this is specifically why other authentication methods are
> available and encouraged with PG.

No disagreement with that approach either.  But defaults are easier
than non-defaults, and there's a hell of a lot that can go wrong with
Kerberos, PKIX, etc too...