* Andres Freund (and...@2ndquadrant.com) wrote: > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote: > > * Andres Freund (and...@2ndquadrant.com) wrote: > > > On 2015-03-04 10:52:30 -0500, Stephen Frost wrote: > > > > 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. > > An increase in "network data sensitivity" also increases the need for > encryption.
Ok, I see what you're getting at there, though our existing md5 implementation with no lock-out mechanism or ability to deal with hijacking isn't exactly making us all that safe when it comes to network based attacks. The best part about md5 is that we don't send the user's password over the wire in the clear, the actual challenge/response piece is not considered terribly secure today, nor is the salt+password we use for pg_authid for that matter. :/ SCRAM won't fix network connection hijacking but it does address replay attacks better than our current challenge/response system (at least the example in the RFC uses a 16-byte base64-encoded salt)) and the on-disk storage risk (multiple iterations are supported), and multiple hashing algorithms can be supported including ones much better than what we support today (eg: SHA256) which applies to both network and on-disk vectors. Thanks, Stephen
Description: Digital signature