On Thu, Jun 21, 2018 at 12:12:40PM -0500, Nico Williams wrote: > On Thu, Jun 21, 2018 at 10:14:54AM -0400, Bruce Momjian wrote: > > On Wed, Jun 20, 2018 at 04:57:18PM -0500, Nico Williams wrote: > > > Client-side crypto is hard to do well and still get decent performance. > > > So on the whole I think that crypto is a poor fit for the DBAs-are-the- > > > threat threat model. It's better to reduce the number of DBAs/sysadmins > > > and audit all privileged (and, for good measure, unprivileged) access. > > > > Yeah, kind of. There is the value of preventing accidental viewing of > > the data by the DBA, and of course WAL and backup encryption are nice. > > One generally does not use crypto to prevent "accidental" viewing of > plaintext, but to provide real security relative to specific threats. > > If you stop at encrypting values with no integrity protection for the > PKs, and no binding to TX IDs and such, you will indeed protect against > accidental viewing of the plaintext, but not against a determined > malicious insider. > > Is that worthwhile? Remember: you'll have to reduce and audit sysadmin > & DBA access anyways. > > There is also the risk that users won't understand the limitations of > this sort of encryption feature and might get a false sense of security > from [mis]using it. > > I'd want documentation to make it absolutely clear that such a feature > is only meant to reduce the risk of accidental viewing of plaintext by > DBAs and not a real security feature.
Agreed. I can see from this discussion that we have a long way to go before we can produce something clearly useful, but it will be worth it. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
