Re: Article on DB encryption
От | Bruce Momjian |
---|---|
Тема | Re: Article on DB encryption |
Дата | |
Msg-id | 200403081919.i28JJNn18271@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Article on DB encryption (Silvana Di Martino <silvanadimartino@tin.it>) |
Ответы |
Re: Article on DB encryption
|
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: