In response to to...@tuxteam.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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers