RE: RDB-based secure data storage

["Runion Mark A FGA DOIM WEBMASTER(ctr)" <mark.runion () us army mil>]

On a server, not the webserver and behind the firewall in a secured DMZ
(meaning no contact with the inside or outside world) place an arbitrary key
to encrypt/decrypt the data passing through.  Secure the dataline between
the servers using dedicated tunnels, or SSH.

Webserver, sends data via controlled secure path to the DB.  Enroute an
interface translates the passing data to encrypted form.  The DB operates
normally.  And make sure you keep a copy of the keys in use for key recovery
purpose.

If you ever change your keys, and you should at least once a month, though
even highly secure environments are rarely that specific.  And this far
exceeds HIPPA.  However it is cheap, easy, and secure.  Use 4096bit keys,
give the NSA a headache.

-
Mark Runion

/*
"So far beyond cutting edge the blade is null event horizon."
*/
 
<snip>


> Calum Power wrote:
> > G'day webappsec,
> >
> > I have been asked by my employer to design a system for storing
> > sensative
> > private data collected from the company's clients. They tell me that
> > this
> > data MUST be very secure, yet clients must be able to update the
> > information themselves via a Web-based interface.
> >
> > My immediate reaction was to use something like GPG/PGP to encrypt the
> > data before storing it in a RDBMS like MySQL. However this then has the
> > additional problem of needing the user to edit the data.
> >
> > My next thought would be to have each clients 'username' be a public GPG
> > key, and their 'password' be the passphrase to this private key. This of
> > course would not be overly secure, and the 'administrator' of this would
> > not be able to update the information without using the users' password.
> >
> > So, I was just wondering if anyone had come across the same problem.
> > Perhaps there's a method of encryption that I'm overlooking.
>
>    You can combine encryption methods to achieve the goal:
>
>    1. Generate a private-public key pair for every user.
>
>    2. For each piece of information you store, generate a new secret and
>       use it to encrypt information (using symmetrical encryption for
>       better performance).
>
>    3. Never store the secret in plain text. Instead, create a copy of
>       the secret for every user that has the right to access the
>       information, and store the secret encrypting it with their
>       public key. When a user want to access a piece of information,
>       their private key will be used to decrypt the secret, and then
>       the secret will be used to decrypt the actual data.
>
>    4. It would be a good idea to have a special public-private
>       key pair, to use it to encrypt all secrets that are generated,
>       for backup purposes.
>
> --
> ModSecurity (http://www.modsecurity.org)
> [ Open source IDS for Web applications ]