Re: RFE: Transparent encryption on all fields

From: Bill Moran <wmoran(at)potentialtech(dot)com>
To: tomas(at)tuxteam(dot)de
Cc: Sam Halliday <sam(dot)halliday(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFE: Transparent encryption on all fields
Date: 2009-04-24 19:45:16
Message-ID: 20090424154516.5bd90b6c.wmoran@potentialtech.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

In response to tomas(at)tuxteam(dot)de:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote:
> [...]
>
> > It's possible that this could be accomplished by something like Veil,
> > or the built-in implementation that's coming in some future version of
> > PG (is it scheduled for 8.5 at this point?)
> >
> > Anyway, if a Veil rule required the user to enter a password that would
> > decrypt their key then store it in the session [...]
>
> Still, I don't see much advantage in doing the decryption server-side --
> and one disadvantage: if someone hijacks the "live" server, they have
> your key.
>
> (The only possible addvantage would be indexing, but you would have to
> solve tougher problems: how do you keep the index key protected?

Someone hijacking your live server does not automatically give anyone
the key, unless you implement this wrong (which is, of course, possible).

Each _user_ gets their own key, encrypted with their password. Thus,
even if an attack gets an offline dump of the database, it does them
no good unless they already have the user's password. If they have
that, they they've been given license to bypass your security
restrictions _without_ doing anything funky.

But it's still protected. If an attacker manages to get an offline
copy of the database (let's imagine a horrific scenario where they
steal an unencrypted backup tape, or they find a huge SQL injection
hole that allows them access to the entire database ...) they still
only have access to the data for users that they know the password
for. Even if they have a certain user's password, it only unlocks a
single key, which only unlocks that user's data.

Sure, there are challenges, but there are methods to work through all
of those challenges.

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tomas 2009-04-24 19:45:26 Re: RFE: Transparent encryption on all fields
Previous Message Tom Lane 2009-04-24 16:15:40 Re: GCC 4.4 compiler warnings