Re[2]: security against dbaŽs

[Adam Pal <pal_adam () gmx net>]

Hello Ansgar,

Certainly you can have the key stored on the same system without
loosing security, lets use for instance a FIPS 140-2 certified device.
Then lets load the "super key" into the machines protected memory,
so once loaded is functionaly and kills itself in case of intrusion.
So you have to do "dirty work" again and load the whole stuff from
scratch.

-- 
Best regards,
 Adam Pal   

Friday, February 13, 2009, 12:24:20 AM, you wrote:

<==============Original message text===============
AW> On 2009-02-12 rohnskii () gmail com wrote:
> > Yes, I agree with the others that sensitive data should be encrypted
> > in the DB.

AW> I don't. Encryption is not really suitable to protect data on a live
AW> system. At least not as long as you store the key on the same system.
AW> If anything, I'd place the tablespaces containing sensitive data on
AW> encrypted partitions or disks, but I fail to see what good encryption in
AW> the database would do.

> > But generally the idea behind that type of encryption (I think) is
> > that data at rest (sitting on the Hard drive) in the DB should be
> > unreadable to "the bad guys".  But the DB would have the key and
> > decrypt it when an authorized person (presumably our DBA in this
> > example) reads it. 

AW> If the database has the key, the bad guys may get hold of it as well,
AW> which would render the encryption useless.

AW> Regards
AW> Ansgar Wiechers

<===========End of original message text===========

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature