* Stephen Frost (sfrost@snowman.net) wrote:
> * Bruce Momjian (bruce@momjian.us) wrote:
> > 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
> > ----- here is 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?
>
> The best part of the existing authentication method we call "md5" is
> that the user's password is never sent over the network in the clear.
>
> The challenge/response implementation we have only provides for 4 bytes
> of hash (or around four billion possible permutations) which is not very
> secure today (as compared to the 16-character base64 salt used in SCRAM,
> which is 16^64 or 2^96 instead of 2^32).
Err, 64^16 or 2^96, that is. 16^64 is not the same and would be way
larger. :)
Thanks!
Stephen