Bill Moran wrote on 16.04.2009 22:20:
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.
Which is something different than your statement
>> 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.
which only talks about someone getting hold of the contents of the server's
harddisk.
As you have to ultimately decrypt the data to display it to the user, he can
always take a screenshot (or copy & paste the text from the web front end) and
walk away. He doesn't even need to use some SQL injection.
To prevent SQL injection there are pretty robust solutions for this (prepared
statements, sanitizing and cleaning any user input, maybe even control the
access to the data by stored procedures which can add an additional layer of
security)
I agree with Kenneth: you need to be more precise on which scenario you have to
deal with.
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
