Re: MD5 authentication needs help

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote:
> > * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> > > On 2015-03-04 11:06:33 -0500, Stephen Frost wrote:
> > > > * Andres Freund (andres(at)2ndquadrant(dot)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).

Thanks,

Stephen