encryption and credit cards

[M_Graff]

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

[Philip_Hallstrom1 (Philip Hallstrom)]

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 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