Re: Encrypted storage

[Erik Kangas <kangas () luxsci com>]

* Another good trick, if this is for session data, is to:

1. Generate 1 symmetric key per session
2. Store the data in the database, encrypted based on that key
3. Send the symmetric key back to the user via a cookie (over SSL if you can).

This way:

- Different keys are used for each session
- The keys are not stored on the web server
- If the user doesn't come back, his session-based key is gone and there is 
no way to decrypt the data w/o breaking the algorithm / brute force.
- This is much more secure that that other solution.

* For another scenario, if the data is not session data, but needs to be 
accessible to a specific program, you can require entering of the key by 
hand when the program is run.  This way, a break of the application server 
is much less likely to compromise the key and thus the data.

* A particularly useful variant occurs when, for example, a non-privileged 
web server needs to add lots of encrypted data to the database (i.e. credit 
card info), but does not need to read it - a special "billing program" or 
other application can read it later or periodically.  Instead of symmetric 
key encryption, you can use public key encryption so that the web server 
can encrypt anything it wants for storage w/o needing to know the password 
to the private key and without being able to decrypt that which it 
encrypts.  Then the "billing program", or what have you, can be started and 
supplied the private key password *by hand* so it can read, decrypt and 
process the data and the password is never stored physically on any server. 
 This "billing program" can even be made a daemon so that you start it, 
give it the password, and it just runs continuously without further 
intervention, though this is a little less secure as someone with root 
access may be able to access the variable storage of this running program 
and glean the password.


-Erik Kangas

Ido Rosen wrote:
> I encrypt session data on disk/database with a symmetric key (shared
> secret) stored on the web server (hard coded into the web app usually),
> that way a database breach doesn't put session data at risk.  As for
> other database data, it really depends on the use you are searching for:
> do you want to do full text searches on the data?  Can your indices be
> unencrypted?  There are many variables to consider when weighing the
> option, not just the straightforward CPU overhead of encryption.
>
> Ido
>
> On 8 Sep 2004 20:38:53 -0000
> Jeffrey Koniszewski <jkoniszewski () kronos com> wrote:
>
>
> > I was wondering (because customers have asked me) whether anyone is
> > configuring their database to store all information encrypted.
> > Databases have this capability but the overhead can be so heavy that
> > vendors don't recommend using it generically. Also, if most of the
> > data is not sensitive it is a lot of work to protect small amounts of
> > data. Is anyone aware of someone using this capability? Under what
> > circumstances? What's the performance hit? What other gotchas? How
> > about encrypted communication to the DB from the app server?
--

Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated

Lux Scientiae:       1-800-441-6612        P.O. Box 326
FAX:                 1-413-332-0598        Westwood, Massachusetts
Cell:                1-617-596-9558        02090, USA
AIM Chat:            Screen Name "luxsci"

kangas () luxsci com  ---  http://luxsci.com