Обсуждение: Article on DB encryption

For the (very few?) people interested in this topic:

"Time is Right for Database Encryption"
 Dec 9, 2003 | By Don MacVittie
Published on NetworkComputing
(www.nwc.com)

http://www.nwc.com/shared/article/printFullArticle.jhtml;jsessionid=REGYCTEZ5MNJQQSNDBGCKHY?articleID=16401578

This paragraph, in particular, deals with a most-argued topic:

"This is why client applications should decrypt the data after they receive it
from the database. That's the most secure place to handle encryption and
decryption. But changing all your client applications usually isn't
realistic. If you find that modifying your apps is not an option, look for a
solution that allows for decryption on the database and protection of your
data while on the network. Using SSL to communicate with your database will
protect your data while it traverses the LAN. It's simple to implement,
especially since you probably already use it for transmitting sensitive
information over the Internet."

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."

Have a nice reading.

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it

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

Alle 19:19, lunedì 8 marzo 2004, Bruce Momjian ha scritto:
> 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.

I agree. This "Global Server Password" should not be stored into a database,
not even into a temporary table (because of virtual memory). It should be
stored in memory as a server-wide variable. We just need a way to pass it to
the server at start-up, using a command line parameter, or even to the
running server, using a TCP/IP socket or something like that. Most likely,
this second form would better fit the needs of a server.

See you

PS: Bruce, it's a real pleasure to meet you on the web. Your book on
PostgreSQL is one of the most "chewed" of my collection.

-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it