In response to tomas@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/