Some people are cavalier about giving out their credit card number online. “Oh well,” they think, “it’s bound to get stolen some day….” The other end of the scale is the “better safe than sorry” people who refuse to buy anything online ever because they don’t understand it and can’t tell the safe from the scary. I hope that after reading this post you’ll be able to tell the difference.
Here are the key aspects of credit card security:
- Encryption
- Certificates
- Gateways
- PCI Compliance
- AI in the credit card companies
- Data validation
- What should be added
Encryption: The easiest thing to explain is Secure Sockets Layer (SSL) encryption over a connection that begins with https. The data is garbled using a key, so that bad people intercepting data off a wire will only get gibberish. Your browser has to know the key in order to garble your data in a way that the intended recipient can ungarble it correctly. It wouldn’t be very secure if everyone used the same key. Each website that you talk to over https provides you with its own key. Let’s say a user at a browser somewhere wants to send me some encrypted data.
User’s Browser: Hey Colleen I need to send you some encrypted data.
Me: OK. Here’s the Cap’n Crunch encoder ring I would like you to use. (followed by key)
User: data ->||key|| -> *&$@(*$#$#X 7g1 (gibberish).
At this point the astute reader will say, “yeah but what’s to stop the bad guys from capturing the key as it’s sent over the wire?” Aha! Here is the clever part. The public key that you tell people about is not what decrypts the message. That is the job of the private key that Colleen doesn’t share with ANYBODY. The public and private keys are related in ways beyond the scope of this article, but the bottom line is the bad guy can’t figure out what the private key is just from knowing the public one. Wikipedia has a more extensive discussion.
The final step in the dialog is as follows:
Me: *&$@(*$#$#X 7g1 -> ||PRIVATE KEY|| -> original data
Trust: I just described the technical end of encryption. Encryption protects your data from being intercepted by a third party. But what if your intended recipient is a bad guy? Bad guys are capable of setting up https and public/private keys. The transmission may be encrypted perfectly, but if the recipient is evil, woops, it’s open season on your credit card. How is one to know? There are two protections here: the security certificate and the gateway authorization process.
What are SSL security certificates about? Everybody who wants to be certified to do secure transmissions has to be vetted by a certificate granting entity. Your browser comes configured to recognize several top level entities (CA’s in the jargon). My CA is embedded in my security certificate. My CA is trusted by its CA to make sure people really are who they say they are. My CA’s CA is trusted by its CA and so on and so forth, until you get to one of the major kahuna CA’s that every browser trusts. Trust is transitive. So if your browser trusts big kahuna CA and big kahuna CA trusts secondary CA the trust propagates down the line until it boils down to, yes, we trust that Colleen is who she claims to be. If the trust chain is all good it is transparent to you because your browser won’t complain. But if either I let my certificate expire, or someone along the trust chain says “who?” the user’s browser will pop up a security warning.
What is a credit card processing gateway and how does it protect the buyer? SSL makes it possible for data to be encrypted. A certificate tells you the recipient is who they say they are. But there’s one more thing… they have to have access to a gateway so that they can request that funds be moved from your account to their account. A gateway is a conduit between the merchant and the credit card companies. In order to have access to a gateway the merchant has to undergo a much more rigorous vetting process where they describe their business process in detail. The merchant must also have to have a track record, and usually have two years in business. They are also required to present an extensive paper trail when they apply for a gateway account. The gateway mitigates their risk by checking out merchants before taking them onboard. Thus, the gateways are protecting both the buyer and themselves.
Use caution: The SSL certification process can be gamed pretty easily. It is much more difficult to defraud a gateway application, but seriously bad guys can create an entirely false paper trail to obtain gateway authorization for fraudulent purposes. Before doing business with any website, Google first to see a) how long they’ve been around and b) if anyone has posted up any dirt on them.
PCI: Using the data responsibly: What does it mean to use the data responsibly? For starters the merchant is only allowed to use it to charge your card for things that you authorized. That’s kind of a no-brainer. If I sucked in your credit card number and then used it to buy myself tickets to Rio, you would file a chargeback through your credit card, I would be tossed in the bad guy heap, and not be authorized to charge cards any more. A much more common problem is honest businesses that charge your card honestly but who don’t understand the implications of storing your card number. Most companies should not store the cardholder’s primary account number (PAN) anywhere in their network except just long enough to relay it to a credit card processing gateway. Why? because if their storage is ever compromised, there’s a buttload of credit card numbers ripe for abuse. What if the card numbers are one way encrypted? Not good enough. Given enough time a hacker can guess how they were got. A small to midsize company should never store PANs. Only huge companies who have passed every phase of the PCI standards should even think about storing PANs. A small company that doesn’t store PANs can be PCI compliant merely by keeping their normal security updated and making sure that all transmissions of sensitive data are SSL encrypted.
How does the credit card industry protect the buyer? Well… some credit card companies flag transactions that don’t conform to the cardholder’s normal spending patterns. And of course they’ll say no if you’re maxed. However, they could and should take security by the horns. But no, they prefer to just let it be what it is and stick merchants with the entire bill for all fraud, which, of course, gets passed down ultimately to the consumer in the form of higher prices. It doesn’t matter to the credit card companies. They have it set up so that they make obscene profits no matter what. Please join me for a moment of unmitigated disgust.
How does the credit card itself protect you? There is a two pronged protection against two distinct forms of fraud: Fraud A is where the bad guy actually stole your card. Fraud B is where the bad guy stole your data from some compromised merchant. It is extremely unlikely that a bad person can perpetrate both forms of fraud at the same time. The two forms of protection are the CVV code and the street address. The CVV code is the three digit extra code on the card. It is illegal for anyone to store the CVV code for any reason. So, if you can provide the CVV code that pretty much proves that you are holding the card in your hand. If someone steals your card, they have the CVV code, but they would not know your street address. Likewise if someone steals your card data, name and address from a hacked datastore, hopefully they would not have the actual card, and would not know your CVV code. That is why usually you are asked to provide your street address, even if ordering a product that will be delivered electronically. Some merchants don’t even ask for all this data. And some ask for it but don’t check it, fearing they might lose the sale if you have to go back and correct your address. You can’t really know what they are checking.
What should the card industry do? The card industry should get more aggressive about security. They need to make it easy for cardholders to generate single-use credit card numbers that only work once. Then the merchants would never even have to deal with the base PAN. The customer would provide the disposable number the merchant, who would forward it to the gateway. The gateway would query the credit card company’s database to resolve it to the real PAN, either approve or reject the transaction, and then mark the disposable PAN as void. If these single use numbers were stolen, they would be of no use, which, of course would take away companies’ reason for storing them to begin with.
Summary Checklist:
- sensitive data is being sent over an encrypted connection (check for https)
- certificate holder is verified by a trusted CA (browser complains if not)
- merchant has passed gateway scrutiny (yes or they wouldn’t be allowed to charge your card)
- PCI compliant (either not storing the numbers at all or storing them behind a hell of a kickass firewall) (you need to look for this!!)
- requesting and checking both the CVV code and the address (you check!!)
- you personally trust them (your call)
Even better would be a single use disposable card # generator that would be transparent to merchants, but that is really up to the credit card industry.
If you are interested in exploring ecommerce security in more depth, the following resources may be of interest to you.
Listen to this post| 3.8 (3 people) |
The credit card industry should get more aggressive about security indeed.
But until theres profit in it, they wont bother.
It would have to balance customers’ laziness against the benefit. The CC industry could advertise higher security as a benefit but if it was a lot of extra bother for the customer to generate disposable PAN’s most people would be too lazy to bite. The only thing I can think of with current technology is for cardholders to login to their credit card on the web and request a disposable number. Way too cumbersome. I’m thinking a little card sized thing that you stick your card in and it pops up the number on a screen. Years ago it was predicted that PC’s would start being made with swipers built in. That hasn’t happened yet either.
[...] explains how you can protect yourself. It is based on the author’s experience as an online merchanthttp://dorkage.net/2008/05/credit-card-security-online/Protection against unauthorised execution of a program on an IC …Protection against unauthorised [...]
[...] security analyst at Symantec. Credit card fraud is a huge and growing problem. See my article about credit card security online for a detailed discussion on how credit card security works and what the vulnerabilities are. There [...]
[...] Here goes! My first credit card security post is a very solid post that needs more reads. It is not going to make you widdle your Calvin Kleins [...]
[...] How Credit Card Security Works [...]