* Andres Freund (andres@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