* 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
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
