"Pavel Stehule" <pavel.stehule@gmail.com> writes:
> On 21/12/2007, Merlin Moncure <mmoncure@gmail.com> wrote:
>> ... The real issue as I see it is where to
>> keep the key. How did you handle that?
> Simply. I use for password some random plpgsql message text and
> compile it. I though about GUC, and about storing password in
> postgresql.conf. It's equal to protection level. We cannot protect
> code on 100%. If you have admin or superuser account and if you know
> some internal, you can simply get code.
Yeah. There is no defense against someone who is prepared to go in
there with a debugger and pull the post-decryption code out of memory.
So what we need to think about is what sorts of threats we *can* or
should defend against. A couple of goals that seem like they might
be reasonable are:
* Even a superuser can't get the code at the SQL level, ie, it's
secure if you rule out debugger-level attacks. (For example, this
might prevent someone who had remotely breached the superuser account
from getting the code.)
* Code not available if you just look at what's on-disk, ie, you can't
get it by stealing a backup tape.
Any other threats we could consider defending against?
BTW, this thread definitely doesn't belong on -performance anymore.
regards, tom lane
