FWIW:

pgcrypto is a module with cryptographic functions that comes with postgres (it is one of the many useful contrib/ modules).

(also interesting: (dws)Re: Encrypting Credit card numbers)

Thanks to everyone who responded - the credit card quandry in particular has already proven to be useful.

I think that when the enemy has root access you are severely violated. One step back would be fisical access of a enemy to hardware, but I think that there are no step forward. The root access is the deepest violation possible in a energized system.

Your thoughts are possible to be deployed, but are useless because the information to be protected could be intercepted before it be encrypted.

Maybe the backups would be protected that way, but almost useless too because, with the backup copies, an attacker may have enough information to prepare a more sofisticated attack.

The assimetrical keys are useful to try avoid changes in the message thru the network. I heard about the possibility of a man in the middle be able to decrypt a message, so there are high risks in a encrypted transmition if the internal network are compromised.

IHO, security is about the weakest link in a chain, there are no shortcuts at all. You must, first at all, to protect your permission system and the backups, these are the natural weakest links.

Security is a big issue. There really are no short-cuts that can be taken with it at all. No magic bullet, no "if we focus on protecting x, then we're safe". The real idea is to balance the effort / reward ratio such that the business down the block is a more tempting target for miscreants.

In order to do this, you need to restrict the storage of user / client data to the absolute minimum amount essential to the running of your business. If this means customers have to enter credit card details more often, or have to setup direct debits for regular payments, so be it.

Once you've identified the bare minimum of information required, you need to ensure that you have done the basics to protect it. Things like multiple layers between your web gateway and your backend servers, using restricted accounts for everything (other than the very few individuals requiring root to maintain your systems and having company policies that very clearly state how and when those individuals should be using root access), firewalling the f**** out of your network (not just external interfaces, but internal (possibly departmental) segregation as well). Logging the heck out of anything and everything relating to security and access to sensitive infrastructure.

When you have everything locked down and logged, then you need to regularly review it. This might just mean internal reviews by appropriate staff, however if you are a large organisation, or hold particularly sensitive information, then you probably want to get external security specialists in to perform penetration testing and otherwise review your policies and procedures on a regular basis (we do this once a year, in addition to internal monitoring and reviews).

Beyond that, keep your eyes and ears open and try to learn from others mistakes.

EDIT: In response to your specific question about SQL, yes encrypting particularly sensitive data with an appropriate scheme is an absolute must (as it prevents attackers from simply copying out your DB and going their merry way - They have to take the time to figure out what you're doing, where keys are stored, etc). Designing security systems that take a long time to work out / hack into is a delaying tactic designed to give your monitoring team time to detect the intrusion.

During my trial implementation with DBIx::Class::EncodedColumn::Crypt::OpenPGP i've hit on a notion regarding key storage which I'm wary of being security theatre and/or reinventing a wheel and would appreciate some guidance.

Context wise I'm working towards a VPS in a 3rd part data center installation where security is more important than uptime. It's based in Switzerland but that's no reason to be complacent.

Since shared secrets can be stored in a .pm, is there any particular reason said .pm should not be stored on some seperate machine and downloaded, loaded and deleted at initial run time when the system resides in a persistent execution environment e.g. Catalyst? If the key host is switched on solely when the system is manually started I don't see how it would be possible to access the secrets barring physical access to the server and data recovery tools. Furthermore, if this is a good idea someone more experienced than I has surely done it already.

Thoughts?

If this is run within a VPS, you must also trust the VPS provider and the supervisor OS not to have backdoors/faults like Xen and others had discovered recently.

If your attacker can become root on your VPS, they can also "simply" extract the key by reading the memory of your process:

open my $process, '<', "/proc/$apache/mem";
binmode $process;
binmode STDOUT;
print $_ while <$process>;
[download]

But unless you can store the key on a hardened USB encryption/decryption device and perform decryption on that device, having the key only in memory reduces the attack surface a lot. Your attacker has to attack the live machine(s) instead of for example attacking a backup tape.

I agree with Corion's comments.

I would lean more towards using a tokenisation system (especially if dealing with CC details). I also would not download, load and delete a pm file in the manner you suggest. What I would do is make a fast API interface available on that separate machine. This allows you to tightly restrict access and upgrade your secrets easily (or even implement a completely different system, maybe even to provide one-time secrets), along with giving you some additional logging abilities that loading a pm wouldn't necessarily allow.

Imagine if you know that when someone does x on your website that it causes a, b and c to happen, which generates 2 requests to your secrets API. Now if your logging detects that someone doing x has actually generated 4 requests to your secrets API, you've just identified a possible intrusion and you can do something about it before too many customers are potentially compromised.

I think what you're getting at is key exchange... secure methods to exchange secret keys. There are well defined solutions but they may fall into your "wary of being security theatre".

In general, look at Internet Key Exchange

Key exchange works using a key management server. To your need, an authorized consumer of the encrypted data would need to establish a security association with the key management server to gain access to the secret key needed to decrypt the data.

You might want to look at Cyrpt::DH or Cyrpt::PK::DH. On CPAN, search for "diffie-hellman".

I think one thing that would help the discussion is for you to describe your normal data flow a bit more, such as: (1) manual or automated scripting or both, (2) local or remote access or both, and (3) local or remote network?