* Stephen Frost (sfr...@snowman.net) wrote: > * 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).
Err, 64^16 or 2^96, that is. 16^64 is not the same and would be way
larger. :)
Thanks!
Stephen
signature.asc
Description: Digital signature
