On Thu, May 20, 2010 at 8:03 PM, Richard Walker <richard@softimp.com.au> wrote:
> Peter Hunsberger wrote:
>>
>> If you really need security of some form at the physical database
>> level then don't screw around with convoluted hacks. Encrypt the
>> critical data in the database and be done with it.
>
> If the hacker gets root access so they can read
> the raw database files, they most likely also
> have access to the means to decrypt any
> encrypted data. This is particularly so if
> the database updates are being done by stored
> procedures.
Only if they also get at the keys.
>
> If encryption/decryption happens
> on a separate (not-also-compromised) client,
> then OK. Do you know of a way to deal with
> this if the application is on the same computer
> as the database?
Can you use an external key store? If not, I can't see this as being
a serious attempt at security, but playing along, you could try
something like the following:
1) Symmetrically encrypt a randomly generated string with something
based on the users credentials (user name and password);
2) If the user can authenticate (many ways of checking this) then you
decrypt the string from 1) and it becomes the basis for the encryption
and decryption of the users data.
You can have the same string encrypted by multiple users as needed for
shared access and you can have a single user manage multiple strings
as needed.
If I recall correctly, there's a version of DB2 with this already
baked into the product. No idea on where it sits on the free to
expensive scale....
