encryption and credit cards

rubyonrails-talk
1

Most things will use OpenSSL. This is because OpenSSL is the lowest level anyone should be going to for this. Anyone who re-implements an encryption algorithm is doing the bad thing.

From whom are you trying to hide the credit cards, though? From anyone who has full access to the machine? From someone who might get a database dump? What about getting your application code as well? Do you want one-way encryption and want to only decrypt if the data is removed from the machine?

Encryption comes in two flavors: shared key and private key. The shared key version uses the same key to encrypt as it does to decrypt, while public key uses a different (but related) key for each step.

If you are wanting to store the credit card so that your application can later decrypt it, anyone who gets that key can also decrypt anything you are trying to hide. Thus, if you host your application and someone gets the source code for your application and the database dump, game over. If you are not worried about this, you should be.

If on the other hand you are only decrypting in "emergency cases" such as when someone contests a charge and you need their actual number, you can choose public key. The server encrypts the data, Base64 encodes it, and stores it in the database. If you need to get it, you get that encrypted value and copy it to your desktop, where you run the Ruby script to decrypt it. This is probably the most secure you can get without adding in hardware. You just never, ever store your private (decrypt) key on the web server.

Often I use a very, very simplistic "encryption" just to mask the contents of data, such that my debugging won't reveal it. For example, I've stored passwords in the clear for a whole set of automated API scripts, none of which needed to be 100% secure, but used ROT-13. Why? So "select * from..." did not reveal the contents.

So, it comes down to, who are you trying to hide the CC numbers from, and what is the threat model?

--Michael

2

So, it comes down to, who are you trying to hide the CC numbers from, and what is the threat model?

--Michael

We would be trying to hide the CC numbers from everyone basically. My app is used to create a user profile which would include collecting credit card info, which would be used to make a hotel reservation, for example. The plan as of now is to store these CC numbers in their encrpted form in a database. Right now I am thinking about having an asymetric encryption method so that if the database gets hacked and the app gets hacked they know how to encrypt the CC numbers but not decrypt them and then, also, they will only have the encrypted credit cards numbers. Not really having ever written anything that involved encryption, I need to make sure that I am doing this correctly, especially with such sensitive information as a Credit Card number.

Google for "PCI Compliance". There are some serious rules you need to follow if you're going to store credit card data.

If you can avoid having to store the data you'll sleep a lot better at night :slight_smile: You may want to talk to braintree (or similar) about their offerings. http://www.braintreepaymentsolutions.com/

In a nutshell, you get a cc card in a form and before saving it, give it to braintree. Braintree gives you back a token. You save the token. And from that point on you simply say things like "bill this token $10". You never have to touch the credit card again -- nor can you get it back via the API either.

-philip