|We don't bite newbies here... much|
Re: Cryptology in the databaseby sundialsvc4 (Abbot)
|on Mar 31, 2008 at 14:37 UTC||Need Help??|
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.
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.