Why We Don’t Use CSC Codes
September 8, 2005 on 9:59 am | In Insider View, Rants by Josh Jones |
When buying things with a credit card online, you may have noticed on a lot of websites an area to enter the CVV2 value on your credit card. Officially, they’re known as “CSC” values (Card Security Code), but Visa calls them CVV2 codes, Mastercard calls them CVC2, and Discover and Amex call them CIDs. For the fun and simplicity of all involved, I’ll just use “CSC” the rest of this post. CSC codes are supposed to help fight fraud because in theory somebody would have to physically have the card in order to know the CSC code.
You may have noticed that DreamHost doesn’t ask for CSC codes.
There are two reasons for this. I’ll tell you reason number two first.
Reason number two is CSC codes don’t do a thing to help fight fraud.
The problem is, about 99.9% of all stolen credit cards used for purchasing things (like say, Web Hosting!) online are gleaned through the use of “phishing” scams. Those spams you get that claim to be from Paypal or Ebay or Wells Fargo or Bank of America. And, the Nigerians and Vietnamese not being total buffoons, they ask for the CSC code for your credit card too! So basically, anybody signing up for stuff online with a stolen credit card is either going to have the physical card (and therefore the CSC code), or will have the CSC code (and therefore have the CSC code).
In theory, using the CSC codes will stop that oh-so-popular case of credit card fraud where somebody goes searching through a trash can for receipts with people’s credit card numbers on it. Except, in practice these days just about all stores mark out the first 12 digits of your credit card number on their receipts.
In theory, using the CSC codes will stop that even-more-so-popular case of credit card fraud where somebody “hacks” into a merchant’s database of stored credit card numbers and compromises a bajillion cards all at once. Despite this being a very infrequent event compared to phishing scams, even when this doesCSC codes don’t help at all.
Why not? Well, think about it. Why is a merchant keeping all these bajillion cards in the first place? The only good reason is to be able to automatically rebill your credit card without you re-entering it every time. And that implies that they either don’t need to use your CSC code to charge your card (which is true.. they’re optional), or else they also have to store your CSC code… so it’ll get stolen too!
Either way, if the crooks get access to that database, you’re still cooked!
And now, the real reason DreamHost doesn’t ask for your CSC code.
Credit card processing online is a convoluted world. Every time you make a payment online with a credit card, there are four separate institutions making things happen. First, the website you enter your credit card at uses an online Point-of-Sale service like VeriSign’s Payflow Pro to pass your information electronically to a Merchant Bank (also know as an Acquirer) such as Cardservice International, who in turn uses a Processor such as FDMS Nashville to handle the actual credit card network and finally deposit the money into your Bank Account at a place like Bank of America.
All of this makes it an absolute pain in the bung to get anything changed in your credit card processing. So once you’ve got a system up and working, I whole-heartedly advice you to never touch it again.
WE haven’t!
We’ve gotten Cardservice to lower our rates a few times as we’ve grown, but other than that, our credit card system has been pretty much untouched since the late 90s… a simpler time when there were no CSC codes!
We originally got our merchant account through a place called WebOrder or something like that. I can’t really remember anymore.. they were an all-in-one place which also provided a secure site for ordering and all that. They were good for us back then because they didn’t have a set-up fee or any set monthly fees, and yet they also didn’t have horrible per-transaction rates. Before them we didn’t even need a merchant account because we were using some place that handled everything and just sent you a check every month, minus 15%. How generous of them!
Unbeknownst to us at the time, WebOrder (or whatever) set us up with a merchant account at Cardservice International, who used FDMS Nashville as our processor. This was all hidden from us, and we sure didn’t care! Things were fine for a while, until they were bought by Cybercash (or maybe we just switched to them?), another Internet Payment Gateway, and we had to change our stuff to start connecting to them. This was okay though, because it was a lot more professional to use our own SSL certificate instead of linking over to “https://secure.weborder.net/” or whatever it was.
Then, a year or so later, Cybercash got bought by VeriSign (for sure), and our hidden Cardservice International account came with us. This actually didn’t change a thing, as VeriSign kept supporting the old Cybercash MDK.. we’ve been using it ever since! Of course, it means that we can’t use all the advanced features of Payflow Pro.. features such as CSC support! And that’s it!
(One semi-funny aside.. when signing up for WebOrder, I used where I was living at the time as the phone number.. my parent’s home phone. Little did I know six years later it would still be showing up on people’s credit card bills! We were never able to figure out who could change it.. VeriSign passed us to Cardservice, Cardservice to FDMS Nashville, FDMS to VeriSign.. oh well.)
But, it’s time for a change.
Recently Bank of America came to us offering to be our Merchant Account (they’re already our Bank Account)… with much lower rates than Cardservice had ever been willing to give us. So we decided to make the switch! Which is why I’m suddenly so knowledgeable about all this stuff.
You see, when trying to switch VeriSign to use our new Merchant Account, we were informed that since our account was originally set up through Cardservice International, we are unable to switch our Merchant Account away from them. Instead, we just have to sign up for an entirely new Payflow Pro account with VeriSign directly.
And, to use a new account we have to use the new Payflow Pro SDK
Which I guess means Goodbye, Cybercash.
Hello CSC codes!
27 Responses to “Why We Don’t Use CSC Codes”
Leave a Reply
Categories:
Archives:
- June 2008 (3)
- May 2008 (6)
- April 2008 (2)
- March 2008 (3)
- February 2008 (5)
- January 2008 (7)
- December 2007 (3)
- November 2007 (3)
- October 2007 (5)
- September 2007 (3)
- August 2007 (4)
- July 2007 (4)
- June 2007 (7)
- May 2007 (3)
- April 2007 (3)
- March 2007 (8)
- February 2007 (4)
- January 2007 (6)
- December 2006 (5)
- November 2006 (2)
- October 2006 (4)
- September 2006 (4)
- August 2006 (5)
- July 2006 (3)
- June 2006 (3)
- May 2006 (5)
- April 2006 (6)
- March 2006 (7)
- February 2006 (6)
- January 2006 (8)
- December 2005 (7)
- November 2005 (5)
- October 2005 (8)
- September 2005 (19)
- August 2005 (11)
- July 2005 (4)
Other Sites
- DreamHost Status - An off-network page for all DreamHost Announcements! (Not as silly as this blog.)
- DreamHost! - The host behind the blog.
- Forum - Discuss DreamHost and web hosting!
- Web Control Panel - Manage your account.
- Wiki - On DreamHost and web hosting.
Powered by WordPress. Pool theme by Borja Fernandez, modified by DreamHost.
Entries and comments feeds.
^Top^
September 8th, 2005 at 10:19 am
as someone who’s involved in getting an e-commerce backend built into our website at work, after reading all of that i’m glad that someone else is handling the financial side of things.
September 8th, 2005 at 12:18 pm
What a fun read! Your talent for distilling these complex processes into simple stories remains unmatched.
However: “CSC codes”? Isn’t that like saying “PIN number” (i.e., “Customer Service Code codes”)? :-P
September 8th, 2005 at 12:27 pm
What’s weird to me is when you purchase something online, and then you’re asked to email/fax a scan of the card or a picture ID.Is that their way of preventing phished cards?
(Also, FYI - the RSS feed for the blog has your edits in it.)
September 8th, 2005 at 2:00 pm
Call me a smartass, but: really? What is your source for this information?
Because if it’s not 99.9% but instead 98% or 90%, and the remaining fraud involves cases of not having the CSC, then it’s still very worthwhile to verify CSC codes… which leads me to my next comment:
I’m pretty sure that most (all?) payment processing services allow for the merchant to verify a credit card before putting an order through. What this means is verifying that the number, expiration, CSC, name, and billing address all match up, and sometimes (always?) checking for actual credit being available.
So therefore, it would make sense for the merchant to ask for and verify the CSC at the time of purchase, but then store only the credit card number in their databases. So in this scenario, it is the merchant’s responsibility to use the payment processor’s tools to maximize security.
That’s my current understanding of payment processing… but my experience is very limited.
September 8th, 2005 at 2:54 pm
So, instead of using http://php.net/cybercash you’ll just use http://php.net/pfpro
Presuming you use PHP. It could be a lot worse.
I’d concur though. Use the CSC for initial purchase, changing credit card info, and new services, but don’t store the CSC or require it for recurring charges.
September 8th, 2005 at 7:01 pm
Yeah well merchants can store the CSC codes anyway so it doesn’t really protect you. ::cough cough DSW::
Maybe the next thing would be CSC codes that could be generated by a device that has a specific algorithm for a specific time or something and returns a CSC code.
September 8th, 2005 at 8:43 pm
Might I ask what rate Bank of America is offering you? I’ve been looking for better rates too and would love to know what you’re getting!
September 8th, 2005 at 10:24 pm
[...] Credit Cards and Jabber: My hosting company’s blog has an article on credit card processing and how useless CSC/CSV codes really are for credit card security. On the same blog is a prediction involving the future of Instant Messaging technology based on Google’s choice to adopt the Jabber protocol for Google Talk. The VoIP standard SIP makes an appearance also. [...]
September 10th, 2005 at 2:17 am
So those funny numbers are meant to be a telephone number?
Using the word ‘gotten’ is hillarious to me :P
September 12th, 2005 at 5:41 pm
I see you all took down the previous post. I’m trying to contact someone, because my site was down as well, and I can’t get into my panel to send you all an email. I also can’t get into my site email. You can feel free to delete this after contacting me. Thank you!
September 12th, 2005 at 5:48 pm
I cant believe you deleted the post! Whats up with our sites?
September 12th, 2005 at 5:54 pm
Good God, tell me you guys didn’t delete that post because of the comlaints…
Your customers deserve some explanation of what’s going on.
September 12th, 2005 at 5:55 pm
The post about the generators is gone ;( Only one of my sites is still up.
September 12th, 2005 at 5:58 pm
That’s f*cking unbelievable. As if we were in China. Censor everything that makes us look bad. You have just lost one customer - hopefully there are more to follow.
September 12th, 2005 at 6:02 pm
read http://status.dreamhost.com
September 12th, 2005 at 6:07 pm
what’s wrong with dreamhost? Site is down…
September 12th, 2005 at 6:12 pm
Read the comment above!
September 12th, 2005 at 6:14 pm
Cool, tnx!
September 12th, 2005 at 6:17 pm
Someone should post about this on the blog cuz not everyone got that link…
September 12th, 2005 at 6:19 pm
LOL, yea maybe use that useless DreamHost Information menu?
September 12th, 2005 at 7:37 pm
False. Merchants are not allowed to store the CSC code, not even in an encrypted form.
The Payment Card Industry (PCI) data security standard prohibits the storage of the card-validation code. See section 3.2.2 of the PCI standard. Visa’s Card Information Security Program (CISP) and Mastercard’s equivalent program use the PCI standard and forbid the storage of CSC codes.
Storing the CSC code in any manner may result in large fines from Visa, Mastercard, and others, and is probably a violation of your merchant account agreement.
See the PCI standard and Visa’s CISP for more information.
September 13th, 2005 at 9:41 pm
Well, most of this story was fairly accurate. But I have to say, I really disagree with many of the conclusions. Having worked on many ends of the online credit card processing systems (from developing a recurring billing system for another web hosting company, to developing the fraud detection systems of an online CC processing company, to now working in an Info Sec group researching fraud detection and prevention for a large financial institution), I think the PROPER use of the CVV2 (whatever you wanna call them) helps reduce fraud. Prevent? No… reduce!
There is no absolute protection against fraud. But there are ways to mitigate and reduce the chances and impact. Sure, if a company stores the CC number (which is required to be stored encrypted, by the way, by VISA regulations… I would recommend AES 128bit, and secure your keys) they may need to do recurring billing. They don’t NEED to use the CVV2. In fact, it is a direct violation of regulations to store the CVV2, encrypted or not. However, when they first collect the credit card from the customer, they can verify with added ensurance that the card collected is more likely the actual person. Once verified the first time (after which you throw away the CVV2), you know the card HAD a valid CVV2 when collected. This greatly reduces the pool of stolen cards that you may end up enabling fraud with.
Perfect? No. But it cuts down the amount of fraud by a lot. Sure, phishing attacks are collecting CVV2s as well. Those people are more likely to be victims. But at least if you properly use the CVV2 you can do YOUR part at protecting a large portion of people who have had their CC number stolen.
Do merhcants violate regulations? Yes. If YOU violate the regulations, I hope you fix things before you’re caught. There are more efforts being put in motion that can put business violating the regs out of business. So… CVV2 use is not useless. Nor does it “not work”. It doesn’t work absolutely, but it DOES work, and for a large portion. There is no absolute solution.
I mean… does wearing a seat belt or having air bags ALWAYS protect you from being seriously injurred or killed in an accident? No. But most of us use them because more often it WILL.
For REAL information about good secure development practices, keep an eye on sites like OWASP (http://www.owasp.org/) and Threats&Countermeasures (http://www.threatsandcountermeasures.com/).
So, in my opinion, I’m not feeling safer with the comments of this blog entry. It just says that DreamHost (if these are the practices in place) is enabling a higher potential of fraud through their systems by not recognizing the proper reasoning for security implementations of CC use and processing. I mean really… I’m all for challenging the “security recommendations” of regulatory groups, but only to a point of recognizing the flaw and actually identifying an improvement layer that can be applied to minimize the risk of their own flaws… not for rejecting the ideas entirely.
Defense in depth!
Alex
September 13th, 2005 at 9:59 pm
Oh, and for some humor…
Verisign and SSL certs:
Up until a month ago, going to http://www.verisign.net resulted in an warning with the cert, saying that the cert was for the wrong domain (verisign.com). It wasn’t until shortly after someone well respected in the info security world embarrassed a Verisign rep at my group’s strategy meeting with his demo of the failure, that Verisign finally fixed the problem. It was just a perfect example of how even those supposedly acting as an authority isn’t even doing things right.
And as for dealing with SSL certs… don’t forget that they’re more than just for encryption. Most implementations, I’ve found, don’t even do the verification that a cert is valid according to a trusted CA, or that the data matches the request.
*sigh* Working in the info security industry really makes me sad about the state of the industry. Makes me feel good about my career and job security though.
Alex
September 14th, 2005 at 2:55 pm
My bad. Verisign STILL has not fixed their certificate problem. https://www.verisign.net/
You may say “so what,” we know it’s them. But DO you? Man in the middle attack, phishing attacks, etc… it’s crazy stuff. But what’s sad is that it just adds to “training” people to ignore such messages, reducing the effective security it can provide. In other words, Verisign is contributing to training people to ignore the validity of their own products and decreasing the value of their own business. And NO ONE at Verisign seems to care enough to make this SIMPLE fix.
December 19th, 2005 at 2:04 am
It is very interesting!
April 6th, 2006 at 10:19 pm
[...] What a difference six months makes! [...]
July 13th, 2006 at 2:48 pm
[...] DreamHost Blog ” Why We Don’t Use CSC Codes [...]