Since the blog post on our paper Verified by Visa and MasterCard SecureCode: or, How Not to Design Authentication, there has been quite a bit of feedback, including media coverage. Generally, commenters have agreed with our conclusions, and there have been some informative contributions giving industry perspectives, including at Finextra.
One question which has appeared a few times is why we called 3-D Secure (3DS) a single sign-on (SSO) system. 3DS certainly wasn’t designed as a SSO system, but I think it meets the key requirement: it allows one party to authenticate another, without credentials (passwords, keys, etc…) being set up in advance. Just like other SSO systems like OpenID and Windows CardSpace, there is some trusted intermediary which both communication parties have a relationship with, who facilitates the authentication process.
For this reason, I think it is fair to classify 3DS as a special-purpose SSO system. Your card number acts as a pseudonym, and the protocol gives the merchant some assurance that the customer is the legitimate controller of that pseudonym. This is a very similar situation to OpenID, which provides the relying party assurance that the visitor is the legitimate controller of a particular URL. On top of this basic functionality, 3DS also gives the merchant assurance that the customer is able to pay for the goods, and provides a mechanism to transfer funds.
People are permitted to have multiple cards, but this does not prevent 3DS from being a SSO system. In fact, it is generally desirable, for privacy purposes, to allow users to have multiple pseudonyms. Existing SSO systems support this in various ways — OpenID lets you have multiple domain names, and Windows CardSpace uses clever cryptography. Another question which came up was whether 3DS was actually transaction authentication, because the issuer does get a description of the transaction. I would argue not, because the transaction description does not go to the customer, thus the protocol is vulnerable to a man-in-the-middle attack if the customer’s PC is compromised.
A separate point is whether it is useful to categorize 3DS as SSO. I would argue yes, because we can then compare 3DS to other SSO systems. For example, OpenID uses the domain name system to produce a hierarchical name space. In contrast, 3DS has a flat numerical namespace and additional intermediaries in the authentication process. Such architectural comparisons between deployed systems are very useful to future designers. In fact, the most significant result the paper presents is one from security-economics: 3DS is inferior in almost every way to the competition, yet succeeded because incentives were aligned. Specifically, the reward for implementing 3DS is the ability to push fraud costs onto someone else — the merchant to the issuer and the issuer to the customer.
I believe your argument regarding SSO is not correct. The merchant is not part of the 3D process and is not the relying party. The 3 domains in “3D” are the Issuer, the Acquirer and the Interoperability domain (typically visa or MasterCard). There is no “trusted intermediary” – authentication is the preserve of the issuer domain, and it is the issuer that is the relying party (hence the liability shift). Further, the authentication method used is not properly a part of the 3D model as every issuer has the ability to define its own process, although in practice some form of password seems to be the universal approach at present.
If that is accepted, then it appears that your quarrel is more centred on the implementation of the protocol, rather than the protocol itself.
Archos is right, 3D-secure is again mentioned when the analysis of the paper from Steven J. Murdoch and Ross Anderson are about the Issuer authentication methods used. You can not criticize a protocol X using the name of protocol Y. Visa and MasterCard promoted implementations are one thing, 3D-Secure an other. Halt the confusion please.
If you want to make a critical analysis of 3D fine, but then we need to evaluate 3D itself, not related complementary services that are outside of the scope of 3D.
We need precision if we want to fix what is broken.
I agree with Archos and Emmanuel Haydont.
It seems that you still haven’t quite understood what 3D-Secure really is as you confuse issuer specific implementations with 3D-Secure as a whole.
So please do us all a favor and take the time to thoroughly study what you criticise in the future!
Emmanuel Writes “You cannot criticize protocol X using the name of protocol Y”. I beg to differ. If protocol X runs within protocol Y it may be fair to use the name of the superset to describe the subset. If 30 protocols Y1…Y100 all share the same property which is conferred on them through adherence to protocol X, then you can criticise the group using the name X. If protocol X and protocol Y are both built and designed by the same body then to an outsider there may be little practical difference. I don’t know if any of these are the case here, I haven’t read either the paper or studied the specs.
Looking at banking in general, all these industry bods specify protocols using a mixture of public documents and needlessly confidential restricted documents that are only available under NDA. How can one expect confusion to be avoided if some specs are public and others are not? It’s just a recipe for confusion.
I would suggest that some of these other responsible protocols which Archos, Emmanuel and Sebastian refer to “issuer specific implementations” don’t even have names. Can’t be read if they do have names, can’t be cited. So there appears to be little disagreement that many if not all issuers have crappy protocols — with the central thrust that stuff just doesn’t work — but then a lot of argument about the precise name of the bit thats broken.
Of course it matters a lot in industry if your piece is broken, rather than the next man, it may affect who gets a slap on the wrist and who doesn’t. But to an outsider you lot are all the same anyway. The customer doesnt see the card schemes and the issuers, as different, for instance. The schemes are owned by the banks after all. They’re just interchangeable.
Suppose in government, the “department for furry widgets” loses a million records of personal information. Suppose a newspaper misreports it that another department, the “department for smooth widgets” was responsible. Ok, it matters a hell of a lot for these departments, a minister might get the chop, but to the citizen, to the outsider, all that matters is that the government lost some records.
Think of it that way, and imprecision is simply not a relevant point to slam people on. You might as well slam Ross and Steven for having typos in their paper.
At the end of the day, I’m sure Ross and Steven have made some mistakes. I’m sure they’d spiritedly defend the accuracy of their statements too, until someone presents a suitably compelling argument that reveals the mistakes. The three or four derisive comments on this blog and on finextra aren’t constructive ones. I’m sure they haven’t understood it all as well as they could given unfettered access to all the relevant documents, including internal specs from issuers. I’m sure they will get slammed for trying to attribute blame for the weak state of affairs that the average customer experiences.
But I really do disagree that precision and correct naming of responsible parties is the route to fix anything in future. Thats just going to perpetuate buck-passing. What is needed is a shared responsibility approach where the entire industry realises that they have to take the criticism on the chin and fix a problem together when it is manifestly present.
Mike
I have found some links to publicly available docs from Visa. Although the specs are not publicly available, there is an overview at https://partnernetwork.visa.com/vpn/global/category.do?documentId=117.
The transaction flow in Table 3-1 describes the protocol.
There are also some documents at http://www.visaeurope.com/merchant/handlingvisapayments/cardnotpresent/verifiedbyvisa.jsp, and http://usa.visa.com/download/merchants/Acquirer-Merchant_Implem_Guide.zip
Some interesting comments from Mike Bond, but perhaps too much attention being paid to matters of minor semantics. The issue at hand here is whether 3D-S is a form of SSO, and it is very clear that this is not the case. This is not a controversial argument, it is a very clearly understood aspect 3D-S, and is part of the reason why this paper has attracted so many puzzled comments.
As Mr Murdoch in his original post places a very high level of importance to the 3D-S-is-SSO argument, then it is not an insignificant matter. There is much to criticise in the way in which 3D-S has been implemented, but picking a nonsensical way to make the argument does not aid the case as it does not give observers who are in a position to argue for changes confidence that the paper will be viewed as credible.
To Joel’s list I’d add that there is a pretty clear description of 3D-S on Wikipedia that does not take very long to read. It also picks up on nearly all the issues discussed in the paper, but without the more obvious errors.
@Mike Bond:
> So there appears to be little disagreement that many if not all issuers have crappy protocols
How do you know? Do you know them all?
To give the issuer the ability to choose an authentication method that fits its security needs is a strength of the 3D-Secure protocol.
So if the issuer finds out that the current authentication mechanism isn’t sufficient any more, they can choose a more secure protocol such as mobile phone authentication, hardware tokens or the like.
Note that I would never bash anyone for not knowing some detail. All I am criticising is the sloppy research.
@Archos
Ok, so I wandered off topic a little. Regarding whether it is an SSO, consider the customer experience point of view:
1. you visit a website you dont know
2. you want to log in and you click a button
3. a box or window appears relating to a company you already know
4. you type some stuff into it
At that customer experience abstraction level, the story told by bullets 1–4 could equally well describe both google accounts and my experience when I shop online with my credit card. So I dont really feel confident enough to weigh in with an opinion, but I think the similarities from a customer experience POV make it at least a feasible argument.
@Sebastian
Sebastian, regarding my comment about little disagreement that many…, you ask how do I know? I was just summarising the feeling that I had taken away from reading this blog post, the previous one by Ross and the one from Steven on finextra. The impression I had got was that most of the commenters agreed there were problems but the main disagreement was about in which spec the problems lay, or how best to characterise the problems. I was certainly not trying to do more than summarise the comments on these three threads. But it seems I might have taken away a different interpretation to you.
I think you are coming at this problem from a totally different angle to Steven and Ross. for instance, you write:
To give the issuer the ability to choose an authentication method that fits its security needs is a strength of the 3D-Secure protocol.
I think they are far more concerned with how the protocol fits the needs of the customer not of the issuer. My point was that errors you claim to see in their discussion which appear big and make the research look “sloppy” may become far less significant to the thrust of their argument if you take the perspective of the customer. So “sloppy” depends both on the content, and on your point of view.
I just dont understand why research that’s sloppy gets accepted to competitive peer reviewed conferences. either
(1) peer review as a process is broken, or the reviewers were incompetent
(2) work can be both simultaneously good and bad depending on your expectations
Anyhow, maybe I should stop banging away and go and read the damn paper and make my own mind up.
@Mike
> But it seems I might have taken away a different interpretation to you.
Thx for the clarification. Sorry for misinterpreting what you wrote!
> I think you are coming at this problem from a totally different angle to Steven and Ross. for instance, you write:
> […] I think they are far more concerned with how the protocol fits the needs of the customer not of the issuer.
Look: We have an issuer specific protocol Y which is connected to the 3D-Secure protocol X. There are requirements on how Y has to interact with X. X doesn’t force Y to implement a specific authentication method so the issuer can choose how they implement Y.
The authors claim that the implementation Y1 of Y that they analyzed was kind of SSO and so they conclude that X is also SSO.
So in which way is this related to the perspective?
And by the way: The authors suggest a USB device for authentication. In the last ten years I haven’t ever seen such a thing being accepted by customers. If you give them the choice, they will choose a payment method without a device hooked to their computer.
> Anyhow, maybe I should stop banging away and go and read the damn paper and make my own mind up.
Good idea! And don’t forget to read the papers in Joel Hockey comments as well as the wikipedia page! 🙂
@ Sebastian
> n the last ten years I haven’t ever seen such a thing being accepted by customers. If you give them the choice, they will choose a payment method without a device hooked to their computer.
Not to kick a dead horse much longer, but I thought I’d pick up on this. There are in fact examples of USB-connected card readers in the market with mass-market implementations, most notably in the Netherlands although their primary use is online banking rather than 3D-S (although there is no technical reason why they could not be used for that purpose). They are also highly popular, although personally I would prefer something with an air gap as opposed to plugging in a token to a Windows machine.
I confess to being an air gap fan also. Clunky, but harder to shoot yourself in the foot than with USB. It’s just a recipe for featuritis.
Talking online banking authentication in general, for all the shortcomings highlighted in CAP by Steven, Saar and Ross a while back (which I don’t dispute), I think it’s heart was in the right place, and CAP deserves credit for that. Some other authentication schemes have just been doomed from day one.
Mike
You are right Mike. We must regret that the Issuer authentication methods chosen by the banks have proven to be very weak. Showing no ambition, or maybe no understanding, from the issuers themselves.
So for sure the Paper was useful and the critics should remain on the Title/Naming, not the core of the analysis. But like you said. These weak authentication methods have no formal names… Let’s turn the page!