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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
