* Andres Freund (and...@2ndquadrant.com) wrote: > Hi, > > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote: > > I've been discussing this with a few folks outside of the PG community > > (Debian and Openwall people specifically) and a few interesting ideas > > have come out of that which might be useful to discuss. > > > > The first is a "don't break anything" approach which would move the > > needle between "network data sensitivity" and "on-disk data sensitivity" > > a bit back in the direction of making the network data more sensitive. > > I think that's a really bad tradeoff for pg. There's pretty good reasons > not to encrypt database connections. I don't think you really can > compare routinely encrypted stuff like imap and submission with > pg. Neither is it as harmful to end up with leaked hashes for database > users as it is for a email provider's authentication database.
I'm confused.. The paragraph you reply to here discusses an approach which doesn't include encrypting the database connection. > > A lot of discussion has been going on with SCRAM and SASL, which is all > > great, but that means we end up with a dependency on SASL or we have to > > reimplement SCRAM (which I've been thinking might not be a bad idea- > > it's actually not that hard), but another suggestion was made which may > > be worthwhile to consider- OpenSSL and GnuTLS both support TLS-SRP, the > > RFC for which is here: http://www.ietf.org/rfc/rfc5054.txt. We already > > have OpenSSL and therefore this wouldn't create any new dependencies and > > might be slightly simpler to implement. > > We don't have a hard dependency openssl, so I can't really see that > being a fully viable alternative to md5 TBH. Right, agreed, that wasn't intended to be a complete replacement for md5 but rather an additional auth mechanism we could get nearly "for free" which would provide password-based authentication with network-level encryption for users who are worried about network-based attacks (and therefore want to or are already using TLS, as Debian is configured to do by default...). Thanks! Stephen
Description: Digital signature