Re: Cryptology in the database

[sundialsvc4]

When you're dealing with crypto, you should be using a public key system, and you should not be implementing any part of that encryption yourself. “It's already been done,” and done well, by systems such as OpenSSL, or by the Crypto-API of Windows. There are copious CPAN interfaces to those systems. You want to be certain that you have left as little as possible to chance.

You will need to have rigorously-defined access control and change control for your systems and all source-code associated therewith.

The first thing you should decide is whether or not you actually need to store credit-card information. PayPal™ and other similar vendors now provide schemes that may make it possible for you to have to handle the confidential information at all.

Next, you need to use public-key encryption, so that the process that's entering new records or handling them in any “outward-facing” way provably-cannot recover the information. If you need to identify a card to yourself, use a SHA1 hash with salt (also a service provided by OpenSSL). If you need to identify it to the user, provide an acceptably very-short fragment or allow the user to enter a nickname.

Decryption of the data should be a task performed by the card-processing engine ... which should be entirely separate from anything “outward-facing” and completely beyond its control.

• Naturally, the private-key can only be reached from the card-processing computer, and naturally, it is stored in a password-protected file with the tightest security that your operating-system can provide.
• If you have to send information to it through an RPC-call mechanism, design it so that the entire request-envelope must be encrypted using its public-key (OpenSSL again). Any requests not so encrypted will be rejected in the most bland fashion possible (and logged to the heavens above!).
• The response to indicate an approved request should once-again be uninformative... such as returning a random integer supplied as part of the encrypted request; or maybe, one of two... one for "yes" and the other for "no." Get creative.

Some credit-processors are now providing their business customers (that would be “you” ...) with SSL public-keys that they require you to use when sending requests to them, so that every request they accept is both secure and traceable (to you). This is a good feature.

The weakest link in any crypto system is always located between two ears. Plan accordingly.

[patspam]

Thanks for the really detailed reply sundialsvc4, much appreciated. I'm actually dealing with medical data which needs to be stored AND retrieved by the webapp, so sadly I can't implement that scheme :(