Thoughts on security model to store credit card details

Question

Here is the model we are using to store the CC details how secure does this look?

All our information is encrypted using public key encryption and the keypair is user dependent (its generated on the server and the private key is symmetric encrypted using the users password which is also Hashed on the database) So basically on first run the user sends in his password via a SSL connection and the password is used with the addition of salt to generate an MD5 hash, also the password is used to encrypt the private key and the private key is stored on the server. When the user wants to make a payment, he sends his password. The password decrypts the private key, and the private key decrypts the CC details and the CC details are charged.

Answer 1

This ties the credit card's security to the strength of the user's password, which varies from user to user and is generally weak. It's better to creating your own symmetric encryption key, keeping that safe, and then doing a bunch of complicated stuff that experts invented, involving initialisms like CBC, CTR, and IV.

Answer 2

If the user's password is secure enough to protect the private key, why not skip the private key and use password (via a suitable key derivation algorithm) to encrypt the credit card number? Unnecessary complications definitely do not improve security.

This scheme doesn't use the public key for anything, indicating that an asymmetric algorithm is out of place here.

Answer 3

I agree with erickson that if the public key isn't used there is no point in doing asymmetric crypto.

As always the problem here is a key-management problem. The insecurity arises from not knowing how to safely hide the key that decrypts the data.

Im not sure if it is possible, but if you can afford it buy a hardware security module and let you HSM manage the keys, or encrypt all customer (private) keys with the HSM master key.

If you cannot, you should find a suitable place to store your "master" key, a possible example is the windows store (if that is a possibility). However, I most admit that i dont really know how secure the windows store is.

Answer 4

I am not sure if you store card number and private key files together. It seems like by just using user password to encrypt private key file you are opening the door for dictionary style attack if the encrypted private key files are available.

Not sure why you want to use public key cryptography which can be pretty slow. Also the model of 1 key pair per user may not scale (how many files, can you generate parameters for public key operations). Note that you may have abusive behavior - people checking to see if their list of stolen cards are good.

You could still prevent any use of card number when user is not present by adding your own master secret and deriving key schedule from combination. In general most merchants can't follow this strict requirement as there is a valid need to use card number when user is not present.

If you just want user specific keys (and you must use a different IV every time), then you can go the openssl EVP_BytesToKey route and pass a different salt each time with the master secret from which the encryption key and iv will be derived (and they will be different for each user).

Finally use of payment instrument is protected by just user password as described. Some users choose weak passwords. So you may want to use additional proofing to ensure card belongs to user - some of this is for your own good as you can fight friendly fraud chargebacks and keep your real fraud chargebacks low.

Answer 5

You may want to take a look the Payment Card Industryies "Payment Application DSS"" https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

It may help make some decisions for you.