On Thu, April 16, 2009 13:20, Bill Moran wrote:
> In response to Thomas Kellerer <spam_eater@gmx.net>:
>
>> Bill Moran wrote on 16.04.2009 21:40:
>> > The goal here is that if we're going to encrypt the data, it should
>> > be encrypted in such a way that if an attacker gets ahold of a dump
>> > of the database, they still can't access the data without the
>> > passphrases of the individuals who entered the data.
>>
>> I'm by far not an expert, but my naive attempt would be to store the the
>> database files in an encrypted filesystem.
>
> That was the first suggestion when we started brainstorming ideas.
> Unfortunately, it fails to protect us from the most likely attack
> vector: SQL Injection/application layer bugs. In an SQL Injection
> (for example) the fact that the filesystem is encrypted does zero
> to protect the sensitive data.
>
> --
> Bill Moran
> http://www.potentialtech.com
> http://people.collaborativefusion.com/~wmoran/
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
I'll chime in here, even though I probably shouldn't. A lot is dependent
on what standard you're trying to meet. General Security (and Common
Sense) vs PCI/DSS vs NSA/DoD vs some other standard.
Do you need to decrypt the values once they're in the system?
Do you need the items in an index?
Do the values need to be part of a constraint / foreign key relationship
(because a hashed value may cause you a lot of headaches!)?
Look at these different scenarios and think about the data (both in
encrypted format and unencrypted format) before you decide HOW you want to
do it.
Tim
--
Timothy J. Bruce
