Alex Page wrote:
> It all comes down to what you're trying to protect your data *from*. If
> you're trying to protect it from people sniffing network traffic between
> clients and the server, then SSL is sensible. If you're trying to
> protect against somebody reading passwords out of a database and using
> them to impersonate other users, use MD5 (or SHA) hashing.
Yep. And the previously-mentioned concept of encrypting identifying
data (name, contact info) per-user using their password as the key would
also be a great complement. If their password was ever lost, then you
would only have to verify their identity and have them select a new
password. I think I will implement this scheme in my next weblication
just to see how it would look and work...
> If you're trying to protect against somebody taking down your server
> room door with a sledgehammer, lifting your server out of the rack,
> driving it away and booting off an alternative medium to avoid needing
> to know your root password, then a loopback encrypted partition (or data
> encrypted in GPG where the decryption key is not stored on the database
> server) is a sensible precaution.
In my entire career, the only time I have lost a server to compromise
was just that - the physical threat. I had a development server in an
office location, and the perpetrator simply climbed over the walls
(through the ceiling tiles) to get into the office. NOTE: Their
elevator key was supposed to have been deactivated, or they would never
had access to my floor. So this was a double-whammy security failure by
both myself and the building's security. Never again!
> I expect that for most database users, it comes down to meeting the
> standards defined by law rather than realistic expectations of an attack
> - I expect that most of the situations we attempt to prevent are
> unlikely in the extreme, but we have various contractual and legal
> obligations which mean we have to defend against them anyway.
If this list could come up with a solid approach that supported these
requirements, that would be a huge win on a global scale :)
Here is my proposal, and I'd like to see if it could pass muster on this
The only identifier for the account would be the login, all other
contact data (phone, name, address etc.) would be encrypted before
storage by (blowfish, twofish, AES, your choice), using the password as
the key. Password is stored in the database hashed by MD5. You could
steal the database and all the data, but no contact information could be
decrypted, as each account has had their personal information encrypted
with a different key.
What do the rest of you think?
> Of course, this loopback encryption with a boot-time passphrase may fail
> if they take the rackmount UPS as *well*, and keep the machine powered
> at all times ;)
Two problems I see with this:
1) I've never seen a quad-xeon live on a UPS for more than 90 seconds
2) They will probably fail to get the external RAID storage unit
In response to
pgsql-admin by date
|Next:||From: Grega Bremec||Date: 2004-03-05 15:52:16|
|Subject: Re: Database Encryption (now required by law in Italy)|
|Previous:||From: Mark Gibson||Date: 2004-03-05 15:28:51|
|Subject: Re: [HACKERS] Any Gentoo users interested in a slotted PostgreSQL|