Hi, On 4 March 2015 at 12:33, Stephen Frost <sfr...@snowman.net> wrote: > * Michael Samuel (m...@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... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
