* Bruce Momjian (br...@momjian.us) wrote: > On Wed, Mar 4, 2015 at 11:36:23AM -0500, Stephen Frost wrote: > > * 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 > ----- 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
signature.asc
Description: Digital signature
