Trend Micro’s Rik Ferguson posted a good piece on Thursday about a major shortcoming in credit card security programs maintained by MasterCard and Visa. Although the loophole that Ferguson highlighted may be unsettling to some, fraudsters who specialize in stealing and using stolen credit cards online have been exploiting it for years.
At issue is a security protocol called “3 Domain Secure,” (3DS), a program designed to reduce card fraud and shift liability for fraud from online merchants to the card issuing banks. Visa introduced the program in 2001, branding it “Verified by Visa,” and MasterCard has a similar program in place called “SecureCode.”
Cardholders who chose to participate in the programs can register their card by entering the card number, filling in their ZIP code and birth date, and picking a passcode. When a cardholder makes a purchase at a site that uses 3DS, he enters the code, which is verified by the issuing bank and is never shared with the merchant site.
But as Ferguson notes, people are human and tend to forget things, especially passcodes and passwords, and it is the password reset function that eliminates any security provided by Verified by Visa or SecureCode. From his blog:
“What would a criminal do if they access to your card details but not your password? Of course, there’s that handy “I forgot my password” link. Let’s see how well protected that is.”
The first step in the password reset procedure is to enter your card number, obviously to ensure you are resetting the password for the correct account. Once that number is entered the system now requires some corroborating data to be sure that you are the legitimate account holder, let’s have a look at that “Identification” phase.”
“Oh noes, this doesn’t look good at all! Three out of four of the items of information used to verify my identity are all contained in the credit card data itself, embossed or printed on the card and contained in the magnetic stripe data. Wouldn’t the criminal already have access to this? So what remains? One piece of information that is not included on the card. Trouble is, it’s information that is not only widely shared on social networks, surveys, sign-up forms and a myriad of other places, but also freely available in public records. We cannot and should not consider our date of birth to be a secret.”
“Having entered the required information all that remains is to enter a new password of your choosing and your transaction is authorised. Worse still, no email notification is sent to alert the cardholder that their account has been accessed or modified. The cardholder need never know until they check their statements.”
This would all be very shocking if it wasn’t already painfully obvious to today’s cyber crooks. When I read the Trend blog post, I began searching for several screen shots I had taken of a discussion on an underground carding forum more than two years ago, which explained very clearly how to get around this added level of card security. The tutorial in the screen shot below was posted by an administrator from the carding forum carder.pro on Halloween, 2009:
Programs like these are a good example of security that is designed to make people feel more secure but that add little in the way of real security, or merely shift the risk to another party. Supporters of 3DS would do well to adopt the password reset advice offered in the Trend post, and to absorb the main points in a paper released last year by researchers at the University of Cambridge, “Verified by Visa and MasterCard SecureCode: How Not to Design Authentication” (PDF).
Thanks Brian, this post is a perfect break-room coffee-table item.
Makes me think that they should buddy up with TSA.
my visa issuer does only allow VBV password resets when authenticated in the Internet bank so this behavior seems to differ depending on issuer. Is it different in US/EU ?
It is up to the issuer bank what method and how to use it. Our customerbanks in Finland have decided to use one-time-password authentication instead of these trivial passwords,zip,addresses whatever. For our customers it was easy choice, they distribute otp’s to clients anyway, they are used for online-banking too.
Which banks? (Full list, please)
Last time I tried using Sampo-Visa w/ something like this (I can’t recall if it was VBV or some other thing), I was forced to use Java to log into my bank (see the article immediately preceding this one for why that’s bad, not to mention my system didn’t have java).
Well, finding correct DOB is not easy is it would be hard to determine card belongs to same person whose DOB is found somewhere.
Secondly, most merchants require card billing address as part of authentication and also do not ship to a non registered address. But it’s good point to acknowledge whenever 3d password is changed.
Not only is it trivial to find someone’s birthday online, but it’s usually a cake walk to find someone’s mother’s maiden name, with all the info people put on their facebook pages and social networking profiles.
How many people do you know that have their profile linked to their uncle on their mother’s side? Think about it. It’s not very hard.
We have a long way to go toward developing secure authentication in this country, and unfortunately we still rely on indicators that are really not that secret anymore.
This is exactly why I don’t use social networks with valid details although granted I have links to family still :\
This article makes me think the VBV program is a complete sham put in place purely for the purposes of making people think there is a higher level of security then there actually is TBQH.
Just yesterday, I had a long argument with my bank. They left a voice mail, asking to call them back on 1-888-something, and when I did, they wanted to “verify” me by asking for my cc number, social’s last four, and mother’s maiden name. I refused of course, and called the bank’s direct listed number instead. Actually got connected to the same guy in the end, and even though he was working for their “fraud department”, he plainly could not see why their style of phone messages were conductive to MORE fraud.
I’m pretty sure there are security people in banks and at Visa who DO know better. They probably just get overruled all the time by the profiteers and big bonus hucksters.
I think it gets worse than this…
While purchasing an item I entered the wrong password and decided I’d forgotten. I decided I wanted to pay on another card anyway and hit cancel. I was very surprised when the payment immediately succeeded!
I rang my card services phoneline who told me merchants can choose to accept payments even after 3ds failure… I wonder if they have to take on more risk of recall.
“I wonder if they have to take on more risk of recall.”
Depends on the issuer and aquirer terms but in general there is no liability shift when a merchant chooses to accept a transaction where 3DS verification failed. So that tends to be reasonable after all.
As already mentioned, the 3DS reset function depends on the card issuer. So there are possible even worse examples out there 🙂
Almost always the “forgot password” link asks you for details that is not so secret/ easy to guess. It is a lot easier to gather information about you than to brute force your password. And most people keep their password secret, but fail to protect the other “keys” that can be misused. Email and social networking sites are very much prone to this type of attacks.
Isn’t a fair amount of credit card fraud perpetrated by someone the person knows? If so this wouldn’t even require a social networking site.
Do we agree this is a card issuer’s problem, and not a 3DS problem ?
I mean, the fact to rely on a password is a card issuer’s decision, as some of mine use 3DS but do not rely on a password.
The one I prefer rely on something I have, not something I know.
For each transaction, it sends me a SMS on a predetermined number, with a secret one-time code in it, which I need to type on the page.
No reset, no alternative… no “I don’t have my mobile”, just a “resend please, I didn’t get it”. And it doesn’t give the full number it sent the text to, just the few last digits.
So I agree, no mobile, no SMS, no order…
But still, my point is this password thing is a card issuer decision… alternatives are already used by others.
And actually noone ever asked me if I was ok with yet another password… or if I prefered another means or “verification/authentication”.
That’s a decent start. The problem is that there exist malware that can beat that approach by changing transaction details behind the scenes. I prefer such systems to include transaction details in the notification including $$$ amount & receiving party. Helps prevent these MITM attacks.
More security theater…..
I’m actually glad this password reset procedure is so weak. Since my bank foisted this nonsense on me without a by-your-leave, I don’t even try to remember a password, just reset to a random string when I (infrequently) get forced to Verify.
Privet pidarjuga Krebs! Kak delishki, huj uzje sosala suka?
Даже интересно, чем Кребс-то на мозоль наступил? Если не секрет? (я просто переводчик, этот блог перевожу, ничего личного – просто любопытство)
Brian, about Java theme. Many users do NOT tell java and javascript. Sorry for poor English.
@Victor Did you mean: “Many users do not know the difference between Java and Javascript.” ? If so, I agree. I’ve run into the same problem with many users.
You need to see it from the banks perspectives, though. The cost of fraud has to be balanced against the cost of lost business from people who don’t make a legitimate purchase because the security measures are to strong. I don’t think there is any such animal as perfect security and perfect convenience.
At the end of the day security theater is good for banks because it’s more profitable that way. If it wasn’t we’d see something else happening.
Nobody is talking about perfect security. Just cheap, easy security measures that defeat most remote attacks. I agree that security theater is more profitable for the banks. As for lost convenience purchases, banks could give better liability deals to customers that use the more secure banking option. That way, things don’t change for careless people & people who care can protect their assets. Currently, most banks don’t give customers who care an option that’s remotely secure.
The problem with your approach is a legal one. It sets a standard that the company will be judged on in court. There are already a number of lawsuits in the USA alleging security negligence by banks and the banks reply is the same, “not our problem.” When banks offer advanced security options to customers they are tacitly acknowledging that security is their problem and that makes their legal position difficult to sustain. The banking industry’s POV is that they don’t want the burden.
I don’t see a market based solution to this problem. The only way you’ll get what you want is when laws are passed forcing banks to do it.
Кребс, это всё ерунда. Объясняю почему:
1. Embossed name – крайне сложно поддается “угадыванию”, обычно first name и last name не соответствую в написании embossed name, т.к. в embossed name могут быть сокращение, отчество, приставки вроде MR и тд.
2. День рождения – информация в целом не секретная, если мы берем ее в отрыве от чего-то. Нам же нужна не вообще чье-то день рождение (что можно найти), а конкретного определенного человека.
3. Ограничено количество попыток подбора, их 3 штуки.
Т.е. в итоге мы имеем: 3 попытки сброса пароля, неизвестное количество денег на карте (кому нужны карты где нет денег?), проблемы с определением дня рождения для конкретной хорошей карте, проблемы с определением embossed name. После всего этого, да же если удастся сменить пароль, никто не гарантирует, что транзакция пройдет fraud-фильтры на стороне merchant.
В целом, при кажущейся плохой защите, все это делает попросту экономически не выгодным или практически не выгодным. Слишком много проблем, слишком много времени тратится, попросту те, кто понимает как это все работает не станут с этим возится на уровне, когда это может кому либо реально угрожать. Конечно, это не 100% гарантия того, что не смогут своровать, но это вовсе не та огромная проблема, которой пытаются представить происходящее в статье.
PS: i hope you will translate it in proper way.
Haven’t you heard of Spear Phishing or Malware? With Spear Phishing (or even ordinary phishing) you can get someone to input their credentials into a malicious form. You don’t necessarily have to have their credit card to-hand.
Malware can also intercept traffic containing Credit Card numbers (see Man in the Middle / Man in the Browser). It’s easy to get all of this information if you know what you’re looking for.
Then, with the details in this article, you can easily reset the user’s password.
Here’s a phishing example:
“We have some very important information for you regarding a recent complete withdrawal from your bank account. Please click some random malware link and input all of the data we need to reset your “Verified by visa” details so that we can verify your identity before corresponding with you.
Sincerely,
Bank of Nigeria”
I don’t know why this is being down voted, he’s saying that those authentication standards actually require a lot of work when lots of work when working with masses of data, and that he’d rather attack easier targets.
VBV appears to offer protection for merchants but little for the consumer. In contrast, Citibank’s mastercard and Discover both have a way to create virtual numbers restricted to the site where first used. Citibank’s number generator is nicer with options to limit/increase the authorized purchase amount, limit/extend the expiration date and cancel previously generated numbers. Discover’s generator mirrors the existing card on both expiration and amount available with no option to cancel previously generated numbers. Both require flash to create the numbers.
Good.
Goood.
Joseph Price wrote:
“While purchasing an item I entered the wrong password and decided I’d forgotten. I decided I wanted to pay on another card anyway and hit cancel. I was very surprised when the payment immediately succeeded!
I rang my card services phoneline who told me merchants can choose to accept payments even after 3ds failure… I wonder if they have to take on more risk of recall.”
I had a similar experience with a major online store. I was running NotScript (Chrome’s version of NoScript) and the Verified by Visa screen came up. I had to allow it in NotScript, and that refreshed the page. When it did, the purchase immediately went through without me having to put in a password.
I remember telling my girlfriend how idiotic it was that you could get around it that way. In retrospect I probably should have looked into it more and perhaps reported it to Visa, but I had just finished a 3,000 mile move and was starting a new job, so I had more important things on my mind. I don’t know if the vulnerability there is on Visa’s end or the merchant’s end. I may place another order through that site and see if it still works.
As I understand it from speaking with my card services phoneline, this is a feature, not bug.
I can sort of… ish… understand them letting you choose not to use 3ds and continue with payment, especially if you choose not to set it up… but once you’ve failed to enter the right password?! (as in my case) Authorizing funds transfer after that is far far worse in my opinion.
Many of these points are not shortcomings of the 3-D Secure Protcol that Visa introduced, but rather of the companies on how they chose to integrate and offer the service to card holders and merchants.
1) “Forgot your Password” issue: The bank that is blurred out chose the data collection that is being displayed in order to allow the customer to reset the password. Banks or their software provider have options on what challenge questions should be positioned to the card holder. This could have been handled better by the bank. However, what is also should be highlighted is that in this example the customers personal data has been stolen. Verified by Visa does create an extra step for the person committing fraud in order to place the order. People still need to protect their financial information better. Because this merchant is participating in Verified by Visa he/she is not liable for the fraud in this case. The Issuing bank and cardholder is responsible. Merchants integrate 3-D Secure to provide an extra security measure. But, merchants also use all the other major tools as well: AVS, cvv2. Geo IP, or even other fraud solutions that 3rd party companies provide. 3-D Secure is the only program that shifts fraud liability and helps protect the merchant community.
2) Static Password: Many banks still use a static password associated with a card number as means of authentication. However, the 3-D Secure Protocol is not designed around static passwords. As mentioned above, SMS/Text, IVR, ect can be used. The methods for authentication are completely open and up to the bank or the market place to decide what will work best and most securely. In theory, bio-metrics, USB Devices, Chips in your computer, anything can be used as the means of authentication. What is important is the resulting data that is created from the authentication be submitted on authorization to show the networks (Visa, MasterCard, AMEX, JCB) and the issuer of the card that authentication was attempted or successful.
3) Invalid password or Cancel still leads to authorization. This is a poor merchant integration of the service. The merchant is participating, but is choosing to ignore result codes that the transaction failed authentication and chose to continue with authorization. Why didn’t the bank decline the authorization? Most banks systems for 3-D Secure are not well integrated with their authorization engines. “The right hand doesn’t know what the left hand is doing”. Again, this can be corrected with a better integration by the bank based on recommendations by their software provider.
I agree to a certain extent with points #1 and 2. However, I’m pretty sure that it would certainly have been possible for the designers to have put in their own, more strict, guidelines for things like password resets.
The same goes for point #3. There’s really no excuse for allowing a transaction to be processed after the user has a) entered their password incorrectly, b) hit cancel, or c) blocked javascript and hit refresh. The responsibility for that sort of epic failure cannot be pushed off solely on the merchant. Systems do have to be integrated, but that’s the sort of thing that should be considered part of the integration process. There should be safeguards in place that will keep the system from even working unless certain checks can be passed, and one of those checks should be that a person can’t have their transaction processed by hitting cancel. It shouldn’t be considered optional.
I agree. More thought in the beginning around password reset would have been ideal. However, password reset was not part of the original design. You either were able to enter your password or authentication failed.
It was added in response to the merchant and banking communities having concerns over customer frustration during checkout if they could not remember their password. Some banks do not allow this option at all.
The merchant software vendor should take responisbility for the merchant integrating the solution properly. I agree it should not be an option; the merchant should always throw a “failed authentication” message and force the customer to provide a new form of payment or re-attempt with the current form of payment. The above example is certainly a rare exception and not the rule on how merchant’s implement VbV and SecureCode. More and More banks are making the appropriate updates to tie their two platforms together to reject transactions.
The magnitude of the system modifications that were required by Shopping Carts, Payment Gateways, Payment Processors, and Issuing Banks had to make in order to support these initiatives was immense. 10 years later there are still platform providers who cannot accept and pass the necessary authorization data to support 3-D Secure.
What’s important is that there is starting to be more and more discussion around these programs and authentication of payment sources. These discussions will only drive innovation and produce better systems and solutions to protect both consumers and merchants from fraud.