Silvana Di Martino wrote:
> And this one shows a feasible solution for PostgreSQL (using pgcrypto):
>
> "Oracle has one of the best solutions for in-database encryption-decryption
> keys. It stores the keys, encrypted, in a table. For users with access
> rights, it decrypts the keys, which in turn decrypt the desired data. The
> downside, of course, is that you have unencrypted data on the network, but
> the benefit is making access to encrypted data secure. Not even the database
> administrator can see the unencrypted data--even the keys to get at the data
> are encrypted. This solution can be implemented in any of the major
> databases, and Oracle provides a secure key generator as well as other tools
> to get you started."
Interesting. I can see how the client decrypts the stored password, but
I don't see how the server works with that decrypted password.
I can see how the client could use it to decrypt data on their end, or
send the password as part of the query as an argument to a pg_crypto
function.
The user could decrypt it and store it in a temporary table, and join to
that table in queries, and pass that decrypted password column to
pg_crypto functions, but do we guarantee that that temp table would not
be on the disk if the server crashes and is then stolen? Seems
server-side variables would be a natural, secure use for this that temp
tables don't supply.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073