Encrypting Credit Card NUmbers - thoughts

[kbc1]

Hi all

I am working on a project which requires the storage of credit card numbers in the database to enable automatic future repeat payments.

Don't worry about the PCI or SSL side of things, this is all sorted.

My question is to ask you all what would be your preferred method of encrytion/decrytion for such a task, and why?

Your opinions will help me make a decision on which route to take.

Many Thanks
kbc1

[laserlight]

I would prefer not to store the credit card details myself 🙂

If you do have to store them... I think that it would either be the case that encryption is not useful except for SSL/TLS, or you have to request that the user supply a passphrase that is not stored (but then the user has to keep entering it, so it is no longer automatic). Otherwise, any secret key that you store in the database could conceivably be retrieved if the database is compromised, thus rendering the encryption useless.

[Weedpacket]

Well, a lot of this is covered in the PCI spec (including a suggestion that one way to minimise risk is "not storing cardholder data unless absolutely necessary"). Minimum standards for cryptographic strength, for example, are based on NIST's publications on the subject of computer security (Special Publication 800-57 in particular is mentioned); at present, Rijndael for symmetric encryption, SHA2 for one-way hash (in both cases the longer the key the better).

Alternatively, most banks these days allow people to set up automatic payments from their accounts (possibly even their credit card accounts) or authorise direct debits by companies.

[kbc1]

Thanks for your thoughts.

I too would prefer not to store them but the system requires to take an intial deposit payment and then in X number of weeks, take another payment and so on.

For VISA and Mastercard you don't need to store the details as you can just send your unique transaction ID from the payment gateway back and this will apply a charge against the same card used in the initial payment.

The problem lies with SOLO, Diners and Maestro cards where repeat payments are not permitted. The card details need tobe resubmitted in full.

From what I have heard though it is against the card payment industry rules to store the 3 digit security code altogether this this maybe my stumbling block.

[bradgrafelman]

Is this system required to be fully automatic?

Could you not require that the users re-enter their 3 digit security code for each transaction (citing their personal/financial security and whatnot as reasons for doing this) and perhaps setup reminders that e-mail them one week prior to the due date for the next transaction?

[Weedpacket]

Can't you go to your bank and ask them about how to go about setting up direct debits with your customers?

[Pikachu2000]

Personally, I would outsource this part of it. I wouldn't want the liability of having the information in my database, encrypted or not.

[nine72]

This is not an answer, just what I and my processor are doing about card storage
I use a direct processor (skipping a gateway) and I do recurring billing. What the processor does is I submit the transaction (PCI-DSS compliance was a pain...but) and the processor stores the card data and returns me a token that has no card data included. When I need to rebill I submit the token they do what they do to match and my customer gets billed. After the new transaction is approved they send me a new token and I replace the one I have stored.

[anakadote]

I was going to suggest what nine72 did. Here's a company I've checked out before: http://www.elementps.com/software-providers/security/pass/