On 15/06/11 14:07, Manuel Gysin wrote:
> - For the password field I just used a hash algorithm with some loops to
> protect the passwords ("Password Storage Encryption" with bcrypt).
Make sure you use a salt value and store the salt as well as the
password. If not salted, your passwords will be easily cracked with a
rainbow table if someone manages to dump them.
> 1. There is a frontend (webserver) and a backend (database)
> - backend must be configured to not allow to much queries in a given time,
> else there is a possibility to get around the whole security stuff
You won't have much luck with that. It only takes one "SELECT * FROM
..." to bypass your query rate limiting. You could force everything
through stored procedures, but that'll be slow and clumsy.
Good intrusion detection and system monitoring so that you detect
unusual events is probably a safter bet than trying to make your system
fail when load spikes.
> - frontend needs too some protection against brute force
Yep. There you can do per-IP or per-range rate limiting, among other
things, which will help. I'd probably want to do this using an intrusion
detection/prevention system probably running as a reverse http proxy.
> 2. When encrypting some columns I need to save somewhere the key.
> - Frontend (very bad idea, first point of failure)
> - Backend (when someone can dump the database, he got the key too,
> encryption is in this use case useless)
> - Remote database (when someone can hack to the first db, it's not far
> away to the second db I think, but there is more time to register an attack
> and force shutdown everything)
> - Write an dedicated application (when someone hacked this server, it's
> only a matter of time before he can find out where the key is stored in the
> RAM)
>
> So it seems there is no protection when someone gained access to the database
> server. Or is there a way? I can't see any.
Not much, no. The main benefit to encrypting some data in the database
is to make it harder to use a stolen dump or extracted content. It can't
make it impossible so long as your system can use the content too.
I'd certainly avoid keeping the key in the database.
If you don't need the capability for unattended web front-end re-start,
you can have your web frontend store the key encrypted on disk and
require interactive password entry to decrypt the key before it can
start. It can then keep the key in RAM and forget the password. If your
frontend is utterly compromised and someone has the time to do the
analysis you're still busted, but it'll slow them down a bunch. If you
want to be viewed as a frothing paranoid you can even store the
encrypted key on the web frontend's HDD but on a separate SD card or
thumb drive that requires physical insertion. I wouldn't.
Personally, I'd probably just keep the key on the web frontend machine
either unencrypted or encrypted with a passphrase coded into the
frontend app. At least that way someone who manages to dump some of your
tables or steal a database dump will need to steal - and know they need
to steal - something completely different as well before they can use
the stolen information.
> I'm not fit enough in attack a database server, but I think when someone has
> access to the database, he can simply dump the whole tables, while the key is
> stored in the table, he has full access to everything in the database. At the
> end the question is, where and how I should store the key to decrypt the
> columns?
It depends a lot on what the trade-off between convenience/performance
and security is. How often is the data you want to encrypt accessed? Is
it acceptable to require interactive authorization or input before
encrypted data can be decrypted? Are the people who add sensitive data
the same ones who need to be able to read it back out again, or can you
restrict the group who can read it to a smaller group of users?
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
