syscomments

RocketScientist's Miscellaneous Ramblings
posts - 76, comments - 354, trackbacks - 3

Encryption

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

Print | posted on Friday, January 23, 2004 1:37 PM |

Feedback

Gravatar

# re: Encryption

You could use the DPAPI library (there are examples of how to wrap this with .NET) to use a low-privileged user's credentials to create your encryption key, store the key in the registry (setting the correct access permission with this user's credentials), and then let the DPAPI use the key underneath based on its knowledge of the users's signature. This is a rough summary, but essentially how it works. The only downside is if you remove the user from the machine, you can't decrypt the key.
1/23/2004 2:51 PM | Robert Hurlbut
Gravatar

# re: Encryption

What I did in a consulting job, was use a public/private key implementation (remembering to store the last 4 digits of the card number un-encrypted.) The servers had the public key to encrypt the number, while the private key was burned to two CD's (one for off-site storage) and access was ruthlessly controlled.

When we processed the orders (which only happened once a month) we shipped the encrypted date to a disconnected machine, put the cd in, and generated the bills.

If you can run your orders at scheduled times (and rather infrequently at that), then you can use physical media to store your key and control access to it, while never providing access to it on a network enabled machine.

Just never, ever, ever, store your key with your data, and certainly try to keep your key from being exposed on a machine that's accessible to the outside world.

Something else comes to mind, but how are you charging the cards? Are you charging them right away, and therefore just need to keep the number for the customer to use again a-la one-click? How do you handle sessions, and not sending the password back and forth across the network when the user confirms their order? (Big reason not to use the password as your encryption mechanism, if an unscrupulous developer can inject some code to find out a user's password, his number is gone.) What about re-play attacks? Have you looked at any cryptoanalysis of your XOR scheme to find out if it is really secure? credit card numbers tend to have some well defined properties (see Luhn algorithms) that might be used to attack a XOR encryption. (but then again, considering how short the data is, the typical approaches of bit shifting the XOR'd data might not work.) With all that said, I'm strictly an amateur on cryptography and security, but an expert worry-wort.
1/26/2004 8:43 PM | Lavos
Gravatar

# re: Encryption

Currently we store credit card information and need to be able to search, find, encrypt and decrypt the numbers at any moment.

To be able to search for a specific card, we store a SHA hash.

We choose to implement the AES/Rijindal for encryption. To prevent attacks based on repetion in the card data use an initialization vector.

Base64 encode all the binary data for easy storage as a string in the database. And don't forget to lay out a solid key rotation strategy.

Key storage can go in several different places, the easiest being in a compiled component and the most secure(but a pain to deploy) being in the OS keystore.

I like the idea of the public/private key setup very much, but does anyone know if it protects from attacks based on the repetion in card numbers?

mike


1/31/2004 1:58 AM | mike
Gravatar

# re: Encryption

I recently read a great book on .net encryption titled "C# Data Security Handbook" by Wrox Press. I recommend it for an introduction to practical encryption. It elaborates on all the above examples as well as highlighting some non-code security issues such as Lavos noted, which I think is well warranted and worth the effort.
6/21/2004 4:15 PM | chacha
Gravatar

# re: Encryption

i want to encrypt and decrypt the number
9/3/2005 12:48 AM | Gaurang
Gravatar

# re: Encryption

sArasd
9/23/2005 2:53 AM | dfg
Gravatar

# re: Encryption

I'm looking for validates credit card numbers generators and encryption credit card numbers in order to use the credit cards i took on the net.Thinks
2/9/2006 6:24 AM | gba herve
Gravatar

# re: Encryption

fdsf
3/7/2006 6:30 AM | fsdfds
Gravatar

# re: Encryption

HOW DO I GET STARTED WHERE DO I START? HELP REALY WHANT 2 ORDER ON LINE .
4/22/2006 5:51 PM | silentgrim
Gravatar

# card

i need a good and valid credit card to pay for on line job so pls help i have try my best but is always abortive
5/20/2006 8:19 AM | julius sunday
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET