In response to Thomas Kellerer <spam_eater@xxxxxxx>: > 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. Not really. You're making an assumption that a pg_dump can only be run on the server itself. Let's chalk this up to miscommunication and allow me to rephrase: The data needs to be encrypted in such a way that if an attacker can get an offline copy of the data by any means, they have no greater access to the data that they would if they used the application to access it. I already have that using PKI. Again, it seems that I left too many details out of my description of the problem. See my post in response to Steve Atkins for a more detailed description of the problem, and I apologize for being too vague the first go-round. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
