How secure is a PostgreSQL database if my server is stolen?
Asked Answered
R

6

8

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.

Rozele answered 12/5, 2010 at 16:32 Comment(5)
Do you really mean "Top Secret?" Top Secret is a characterization used by the US Government that would preclude you from using this kind of security to protect the database.Hedonic
I don't know about postgreSQL, but I doubt it encrypts the data files - but rest assured, as with most things in the security sector: once an intruder has physical access, there's little that can be effectivly protected.Abbe
Store some strings in the DB, open up the Postgre database file in a hex editor and look around for those strings.Educative
@Robert For me, 5,000,000 credit card numbers are worth more than the nuclear codes. On the brown market that'll go for just about 1 billion US dollars (the credit card #s that is).Rozele
I'd suggest armed guards. :-)Educative
P
6

"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.

Prothrombin answered 12/5, 2010 at 19:5 Comment(1)
this is a generic answer and does not address the specific question of accessing/recovering/reconstructing data in a postgresql database without password guessing.Walloon
E
4

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.

Educative answered 12/5, 2010 at 17:2 Comment(1)
I don't have experience in that area at this point in time. You should review your service agreement if this was being held by a third-party server company. I advise consulting a lawyer specializing in intellectual property for the specific legal actions.Educative
A
2

If you're not encrypting the hard drive/file system, you're pretty much out of luck, as Postgres doesn't offer native encryption. And encrypting the hard drive is the only real method of protection for a stolen server.

Basically, what you would need to do is encrypt the hard drive or filesystem, AND you would have to enter the password when you mount the drive, by hand, each time the machine starts, before Postgres fires up.

Anthiathia answered 12/5, 2010 at 17:5 Comment(0)
S
1

I don't think this is a problem PostgreSQL, or any other database addresses. Even if the database its self is password protected all of the data is in plain text and thats what really matters. Nothing is stopping the attacker from cat'ing the raw database file and piping it though strings. The best solution for this type of attack is to use an encrypted file system. This would require you to type in a password to mount the partition. This also increases overhead.

Supposititious answered 12/5, 2010 at 17:2 Comment(1)
I can think of 2 DBs that do support on-disk table encryption off the top of my head: Lotus Notes & Sybase Advantage Data Server (ADS). I'm sure there must be others.Corporeal
W
1

For the specific question posted (and the one I came searching for an answer to), Postgresql by default stores table data unencrypted. Looking around in files in .../pgsql/9.2/data/base/* I would guess that these store tables in 1.1 gigabyte chunks, and I can successfully find ASCII strings in those files with grep. From inspection of the files it appears that the data is stored in columns.

From this information I believe that I could experiment and write code to reverse-engineer the tables to create a copy on a server which I do not have the password for.

Therefore relying on a strong database password alone does not meet your duty of care if you need to protect against the risk of the physical media being stolen.

PostgreSQL online docs provide some options for encrypting data at various levels, which for this problem seem to be limited to a module for encrypting specific columns or encrypting the underlying media in some way as other respondents have suggested.

Walloon answered 20/5, 2015 at 8:37 Comment(0)
Y
1

A good start is to enable full disk encryption. You can also encrypt at the application layer. (e.g. encrypt data before you send it to the database, store the key not accessible from the database server)

Yeorgi answered 7/10, 2015 at 0:48 Comment(1)
Great idea (store key elsewhere and access via environment in app server)Rozele

© 2022 - 2024 — McMap. All rights reserved.