I'm trying to store encrypted credit card data in my database. I need to get some of these notes down just in case.

Some basic concepts: Digest Authentication is a process that takes a body of text and turns it into a number. The number, referred to as a hash, cannot be turned back into the text, but the text will always return the same number when run through the digest authentication algorithm. This is basically a type of one-way encryption, and it's typically used for authenticating users with passwords: The password you type in is turned into a hash, and stored with a saved hash value. Doing things this way, the password isn't stored anywhere, so nobody can find your password. There are some weaknesses to this (particularly so-called "Dictionary Attacks" and using very weak hashing algorithms like the original Windows NT LANMAN hashes). Examples of digest authentication are things like MD5 and SHA.

In order to get two-way encryption, basically to encrypt a body of text, you need to have reversability. Digest authentication isn't reversible, you can't get the input text from the output hash. So you need some reversible scheme. One way would be to use XOR, the Exclusive OR function. It's reversible, but you need something to XOR your text with. You could use the password hash, but since you store that it would be avaialble to anyone with access to that storage, and you don't necessarily want that. So what you can do is take the password hash, concatenate the cleartext password onto it, and create a hash from that. Since the password isn't stored, the hash can't be derived from anything on the server. So you can take that hash, feed it and the text to be encrypted into XOR somehow and come out with a reversibly-encrypted value. Reasonably secure, tre spiff. XOR is so fast it's pretty much free, so you're not even chewing up a lot of CPU.

The problem is that if you use this to do credit card numbers, you've got a problem. Specifically, if you have a backorder situation, you'll need to be able to charge the credit card at a later time (you don't want to charge until you ship, just in case the manufacturer can't get the item to you). So this isn't really a good idea for credit card storage. The problem is that what IS a good idea for credit card storage is using a master hash for all the credit card numbers. That's effective, you can pull stuff on demand….but where do you put the master key? I mean, if you store it in the database and somebody makes off with a backup, they've got all your credit card numbers. Or if somebody manages to get an admin account on your system (these are windows systems we're talking about) then they've got instant access to all of your credit card numbers.

More research pending…