How secure is a PostgreSQL database if my server is stolen?

Question

If I have a server with a database of top secret data in PostgreSQL and my password is practically impossible to guess (128 character string of all sorts of weird chars, generated by hand). The server password is also practically unguessable.

Aside from a password guessing, how easy is it to get the data out of this database?

Assumptions:

1. Only the DB exists on the server. There is no password in a PHP script or anything like that
2. The person who stole the server is a server / DB / hard-drive recovery expert
3. I'm not using any hard-drive encryption or anything out of the norm for protection
4. I'm using Ubuntu Hardy (latest stable version)

I'm trying to understand the risks involved with somebody gaining physical access to my server's hard-drives.

Answer 1

"The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis."

Ditto.

Once an attacker has permanent physical access (i.e., he walked out of the building with your hard drive in his briefcase), the jig is up - assume that in time the data will be compromised. From there, the scenario is the cost of the delaying tactic vs. the ability to slow down the attacker.

It's a little different if the attacker is an insider, or had only temporary access. In those cases, you might be able to slow him down enough, or force accountability such that the attack becomes infeasible.

Hard drive encryption is a delaying tactic - it will give protection that matches the strength of the algorithm, strength of the key, and strength of the password locking access to the key (or the ability to insert hardware with the key stored separately). Even with encryption the assumption is that it's a delaying tactic. Sooner or later, the attacker will get through the key space and figure out what key decrypts the system.

Tamperproofing is another option - finding a way to electronically erase the hard drive under certain conditions (like physically removing it from the case).

Figure that once physical access is granted, the attacker can work around your passwords - however strong they are - without resorting to brute force. The first one that comes to mind is using the "fix the password" techniques that most systems have built in to help sys admins that have locked out & lost passwords.

Any and all protections come with a price - tamperproofing is expensive, since you need speciality hardware. Encryption can be cheaper, but it affects boot time. Also, I've seen some nasty surprises with how encryption plays with applications - you never really know until you try to use it.

Answer 2

The standard thought is when someone sits down at the server, it's compromised, end of story. Things only get worse if they grab the hard drive and take it to a lab for opening up and analysis.

I would begin with whole-drive encryption, as well as per-field encryption in the database. You might look around to see if there is a way to have a biometric-based access to the hard drive hardware installed on the server. Also, you want to dig up a physical security contractor and get their recommendations for configuration; also hire guards.

I mean, if this is a scenario that might reasonably happen...

edit:

If I had a Postgres DB file I wanted to get into and I had the resources (ie, spending 4K for some cheap Dells), I would use a Beowulf configuration and perform parallel brute-force cracking. Things get worse if I start to have more money and can configure, say, several of those sweet NVidia supercomputer-on-desktop machines plugged in to really start brute-forcing a password.

If the thief is serious about getting into it and you don't have security already planned from Day 0, your DB file is going to be opened like a sardine can.