On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > * Andres Freund (andres@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 -----
hereis where I was lost
> is not considered terribly secure today, nor is the salt+password we use
> for pg_authid for that matter. :/
Can you please rephrase the last sentence as it doesn't make sense to
me?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +