How online card security fails

January 26th, 2010 at 12:25 UTC by Ross Anderson

Online transactions with credit cards or debit cards are increasingly verified using the 3D Secure system, which is branded as “Verified by VISA” and “MasterCard SecureCode”. This is now the most widely-used single sign-on scheme ever, with over 200 million cardholders registered. It’s getting hard to shop online without being forced to use it.

In a paper I’m presenting today at Financial Cryptography, Steven Murdoch and I analyse 3D Secure. From the engineering point of view, it does just about everything wrong, and it’s becoming a fat target for phishing. So why did it succeed in the marketplace?

Quite simply, it has strong incentives for adoption. Merchants who use it push liability for fraud back to banks, who in turn push it on to cardholders. Properly designed single sign-on systems, like OpenID and InfoCard, can’t offer anything like this. So this is yet another case where security economics trumps security engineering, but in a predatory way that leaves cardholders less secure. We conclude with a suggestion on what bank regulators might do to fix the problem.

Update (2010-01-27): There has been some follow-up media coverage

Update (2010-01-28): The New Scientist also has the story, as has Ars Technica.

Entry filed under: Academic papers, Banking security, Legal issues, Politics, Security economics

27 comments Add your own

  • 1. Some bloke  |  January 26th, 2010 at 15:11 UTC

    I congratulate you on an excellent paper. The fact that the entire 3DSecure system goes against the kind of messages that security professionals have been trying to get out to the general public for years in relation to fraud, phishing, spoofing and so forth is absolutely laughable. This is obviously *not* a system which was designed by anyone with infosec experience.

    I was astounded to read in Section 2.6 (“Inconsistent Authentication Methods”) of the paper that “… one bank asks for the cardholder’s ATM PIN.” – who are these idiots?! Moreover, why have you not ‘outed’ them?

    Your conclusions are laudable but unlikely to be implemented. Why? Because implementing systems such as transaction authentication or trustworthy payment devices are expensive and the banks will not pay for them if there is no legal requirement for them to do so. The likelihood of there being legislation to enforce the banking sector to do this and thus take some responsibility for fraud is about as likely as a snowflake surviving hell. Our regulatory bodies for the financial sector are largely toothless in the face of banking power. Our own Government which state owns some of these institutions cannot even control the level of bonuses being paid out. How will they ever pass legislation to force banks to implement proper secure authentication schemes?

  • 2. Hugues  |  January 26th, 2010 at 15:18 UTC

    Scary!

    Here in Belgium, most e-commerce websites served by Ogone require authentication via an external card reader (not connected to the computer)

    The merchant redirects to Ogone website which asks for card details and then redirect to the bank site which in turn ask to “sign” the transaction by displaying a 8 numbers code to input in the reader and sign it with the pin code.

    At least this is how it works with Ogone/Dexia, but I think it is the same with other banks here (since they all use the same pass: http://www.vasco.com/products/digipass/digipass_readers/digipass_800_range/digipass_810.aspx)

    To steal me you would need the card, the reader and my pin code. If the pin code is wrongly entered three time, the card is locked.

    A bit more secure I hope…

  • 3. Andrew Main  |  January 26th, 2010 at 17:06 UTC

    Despite the liability shift, a lot of merchants actually hate 3D Secure. A huge proportion of would-be customers drop out during the online verification phase, ultimately failing to make their purchase. It’s a pain for cardholders (even ignoring their extra liability), which makes it a pain for merchants. Some card issuers are starting to demand that merchants support 3D Secure, as a condition of accepting payments on their cards.

    The handoff of the user journey from the merchant’s website to the card issuer’s ACS is also technically problematic. It’s tricky to make a website do this, because every part of the system has to change to accommodate the radically different structure. In theory it allows the cardholder to talk to the issuer without the merchant getting involved, and this couldn’t be achieved otherwise in a purely web-based way. But you’ve noted the difficulty for the cardholder in checking that they’re actually talking to the issuer, so it’s obviously not yielding the intended payoff for all that pain. Again, unappealing for merchants.

    Readers may wish to know how to avoid 3D Secure on their online purchases. This is possible. You need to contact your card issuer, and ask for your card to be “unenrolled” from 3D Secure. (Cards are normally “enrolled” by default, and this means that 3D Secure verification will be attempted by a merchant that supports it. This is different from being “registered”, which means having established a password/whatever to verify your identity. If your card is enrolled but you have not registered, you’ll get a 3D Secure dialogue, in which your card issuer will try to get you to register.) First-line support are likely to not know how to unenroll a card, or even that it’s possible, so you need to get to talk to the right person. Some card issuers actually refuse to unenroll, and some merchants won’t accept unenrolled cards for online transactions, but I’ve never encountered either myself.

  • 4. Steven J. Murdoch  |  January 26th, 2010 at 18:42 UTC

    Heise Security have a feature on this: Researchers criticise 3D Secure credit card authentication.

  • 5. Sandeeo  |  January 26th, 2010 at 19:28 UTC

    Just FYI – 3D secure is required by law for all online transactions in India.

    *sigh*

  • 6. Steffen Neumann  |  January 27th, 2010 at 12:02 UTC

    Hi,

    years back (when I didn’t care about credit cards,
    so details are fuzzy now) I encountered an issuer
    who gave out one-time-credit-card-numbers for
    online transactions. Does anyone remember that ?
    Did it not succeed because the number space
    is too limited ?

  • 7. Joel Hockey  |  January 27th, 2010 at 23:12 UTC

    Steven and Ross, thanks for posting the paper, it’s quite a blast from the past. I was involved a little in the spec development and original implementation (versions of the spec prior to 0.7 and then on up to 1.0.2) of a Merchant Plugin (MPI) component about 10 years ago when working for QSI Payments (now TNS) . The original developers of the spec were Arcot. I know Don Park worked at Arcot and had a lot to do with things there.

    As someone who is aware of the liability shift from acquirers / merchants to issuers / cardholders and what this means, I have never personally signed up for this scheme, but it hasn’t really taken off here in Australia in any case.

    I agree with your criticisms of ACS implementations. The use of pop-ups that hide the browser address bar and the fact that most issuers have outsourced ACS to 3rd parties that use non-bank URLs makes it just about impossible for a cardholder to know whether they are using a legitimate site. These sorts of security problems were well understood 10 years ago, but as you guys know (I’ve read Ross’s book, and follow this blog) banks tend to follow their own economic incentives even if it means suboptimal overall outcomes.

    There is a strong incentive for acquirers and merchants to use 3DS (liability shift and lower interchange rate), but Visa had to mandate for issuers to participate since there is little reason an issuer would otherwise join. It makes it easy to understand why issuers would outsource to the cheapest supplier rather than host their own ACS and integrate tightly with backend systems.

    I do have some feedback / criticisms on your paper. I would have been interested to see some scrutiny of the actual protocols being used (VEReq / VERes, PARes / PARes messages, use of client-SSL, central directory system, message signing, browser used for message delivery, etc). Despite the problems with some ACS UI implementations, I believe that the protocol is secure and does very well for the restrictions that it had.

    I am curious as to why you see the scheme as being a single sign-on protocol? I have never thought of it along those lines, and I don’t see why you would compare it to OpenID, Liberty, etc. I must admit that it was 2004 when I last had any involvement with 3DS so things may have changed, but the wikipedia page states that version 1.0.2 is still the current version. The PAReq / PARes (Purchase Authorisation Request / Response) messages are required for each and every purchase. They provide the ‘transaction authentication’ that you say in your paper is required rather than single sign-on which you state (and I agree) is the wrong model.

    This is not a very important point, but given that 3DS came out around 2000, I would also challenge your statement that it is the industry’s response to the increase in fraud that has occurred in the last 5 years after the introduction of EMV. I live in Australia where I rarely ever see 3DS, so perhaps in UK and Europe there has been a bigger push recently as a response to fraud, but I would say that 3DS is the industry’s response to the failure of SET and the fraud that occurred during the late 90s.

    I like your suggestion of using a USB device with trusted display, or using SMS to provide auth codes. I know that chip cards are already used by some issuers as part of the 3DS authentication process, and I believe some use SMS to provide auth codes – it was certainly talked about often during the early phases of the protocol as a way to add security. I would be interested whether you think these out-of-band / multi-factor / trusted-system techniques would fit in the existing 3DS protocol and use of browser with redirect to issuer website during checkout, or if you think a different messaging / workflow protocol is needed?

    Lastly, I’m a little unsure about your conclusion that regulators need to intervene. In principal I guess it is a good idea, but the thundering hooves of regulators coming to the rescue doesn’t really fill me with confidence. Consumers / cardholders already have (or had) quite good protection against fraud. It has always been the requirement for merchants to prove that a cardholder authorised a transaction. The introduction of new technology like 3DS or regulation like the EU Electronic Signature Directive (which you mention, but I am not familiar with) can only result in liability shifting from the merchant to the cardholder.

    I could only see that regulator intervention would be to mandate the use of some technology (along with liability shift to the cardholder). So while the technology of digital signatures and strong authentication and chip cards and USB devices with trusted displays have the possibility to reduce fraud, the fact that banks often mess up in the implementation, and the fact that liability is shifted to cardholders when they enrol for these schemes means that cardholders may be better off if regulators don’t intervene and they are allowed to continue to use older technology like magstripe track 2 data and paper cheques.

    Once again, thanks for publishing the paper. With hundreds of millions of users like you say, this is certainly an important part of Internet and overall commerce and can only benefit from academic attention.

  • 8. Stephen Wilson  |  January 28th, 2010 at 08:54 UTC

    You raise very good points about the phishability of 3D Secure, and the way it will train people to stray from standard security advice.

    But why do you call 3D Secure a “single sign on” system? I know SSO comes in multiple flavours, but it’s generally about using one credential/mechanism to access multiple services, for convenience. 3D Secure is very much one-to-one. If I have two Visa cards from different issuers, the two 3D Secure experiences will be separate (and indeed distinct for as you point out, the authentication mechanism is left to the choice of the issuer).

    In addition to the security issues, and the commercial heavy-handedness, there is a deeper architecural problem with 3D Secure: it breaks without obvious good reason the decades old Four Party card settlement model. An important feature of the Four Party model is that it means customers’ transactions are distanced from the issuer. As you say. this is good for customer privacy. It’s also architecturally elegant that traditionally, payment information flows between cardholder and merchant in real time, and between acquiring bank and issuing bank in batch time. 3D Secure joins the cardholder to their issuer in real time, to effect the authentication step. This is an unusual behaviour, it creates performance bottlenecks, and in principle, almost certainly opens up new vulnerabilities thanks to the sheer complexity and novelty.

  • 9. Clive Robinson  |  January 28th, 2010 at 15:09 UTC

    @ Joel Hockey,

    “I like your suggestion of using a USB device with trusted display, or using SMS to provide auth codes.”

    Personaly I’m very unkeen for USB devices (due to end run attacks and unknown functioning status).

    Put simply It is impossble for the user to see if there are side channels that are being exploited or not. So the user does not know if they or somebody else “owns” their security token. (I’ve had a conversation about this previously with the likes of the Cronos system).

    Likewise SMS has always had some user issues (and they will probably get worse). Part of this is due to the way the SMS system is designed as a secondary and unreliable service. Although other issues make it fail all three of the CIA triad. All of which could in theory be mitigated in one short message, however you get back to the issue of trusting a token which has issues (as we know from the TI calculator and issues with subcontractors of Apple making a trusted token of any kind has real issues). So it’s a circular argument…

    “I would be interested whether you think these out-of-band / multi-factor / trusted-system techniques would fit in… …with redirect to issuer website during checkout”

    It’s not realy a question with fitting tokens into a current limited/insecure design on an open and insecure network.

    The tokens that are favourd are not secure by themselves…

    There are two issues with all the token systems I’ve seen so far,

    1, They are all mutable
    2, You can find potential “end run attacks” for them.

    First of mutability is not good in a security product unless very carefully built in which invariably it is not or not suficiently so. There are several problems with mutability and most are actualy not technical at all.

    If you look at electronic tokens they need to be built on FMCE lines. Due to production test and returns loss (as seen in all COTS equipment) they will almost certainly be mutable. In the main this is to do with the asymetric costs of production-distrubution to return-rework.

    However for the same reasons It is unlikley that any mutable token will have a physical interlock as this has a significant impact on line time as well as cost. Thus the tokens move by very deliberate design into the realm of “security by obscurity” (more of which later).

    As has been seen with the likes of Sky settop boxes, MS X-Boxes etc etc, that where there is any incentive at all, any inherent lack of security anywhere in the system, will end up being exploited (thus all games consoles and all DRM etc etc etc).

    I have been bold enough in the past when things where a lot less clear to make the claim that any semi-mutable system without physical interlocks that is connected to a general use communications system (MobPhn/Inet etc) either indirectly or directly is open to being attacked via a number of vectors if there is sufficient incentive. Obviously where multi billion pound fraud is involed there is considerable incentive.

    And as has been seen with the work that the Camb-Labs amongst others have done with card systems etc the attackers always out evolve the banks (which with todays hidsight tends to make my bold claims sound like a squeak of the inevatable ;)

    Sadly many of these systems are successfully attacked before the initial roll out of a new system gets going. Which can suggest to an outside observer that either those implementing the systems do not know what they are doing, or they are working within an environment where those paying the bill do not care for the actuality, just the marketing.

    Thus it would be easy to conclude that the systems any financial organisation picks will almost invariably be ill thought out and to the lowest possible price break point that does the job at the marketing level. And thus require legislation to correct.

    However the implementation of industry wide systems is way more complex than a first sight knee jerk analysis or legislation can deal with.

    Just one example being the length of time it takes to get a system out the door.

    In technology generations (12-18month) we are looking at 5 or more generations from an initial fesability requirment through to production shipping. Then there is roll out etc etc. That is the same as bringing on line an engine designed by Thomas Newcomb et all.

    Thus a primary cost requirment buts head to head with a security requirment. In that no mutability = no cost effective update etc. However incautious mutability will be exploited. Which is a vicious circle unless you prevent unauthorised changes. And as has been seen witht the code signing in TI calculators and simmilar in consumer systems an information only solution will be defeated and probably reasonably quickly with sufficient financial incentive.

    So the lack of protection against change leaves an oprotunity for attack especially for devices conected to an open public network (MobPhn/Inet)

    Which means the system is vulnerable to “end run attacks”. None of the current comms connected token designs appear to take sufficient care to prevent end run attacks.

    That is the systems user communicats with a token that potentialy cannot be trusted at any time.

    You will hear cries of “that’s not possible” but unfortunatly it is.

    Apple was found to be shipping ipods with virus software on them even though it was not supposed to be possible. It appears that a subcontractor installed it into part of the final setup etc. Mobile phone manufactures do “over the air” code updates that use code signing but, they invariably do not check the code from the security perspective and release signing keys to many people. Vodaphone in Greece however had software installed on the mobile phone network system it’s self that alowed 100 or so senior Greek Government officials to be “bugged” prior to and during The Athens Olympics. TI however had their signing keys cracked and published. And there was a story of extra hardware being added to E-Pos terminals that allowed card skiming to happen.

    You can see there are many malicious ways an attacker can “get at” devices if the incentive is there.

    Then there is the isue of keeping a crack open and or hiding the functionality from the user. Which boils down to side channels and their exploitation.

    Side channels have been known about since the 1970’s and SALT.

    If you have a communications channel it has a base level bandwidth (Shannon Hartly) that says how many “symbols” of information can be sent down it in a given time.

    However the symbols can be multi bit in many ways and the bandwidth can effectivly be increased by “coding” as was seen with the modems used on POTS.

    However the closer you get to the limit the higher the bit error rate so necescitating error correction. By the time you add in alsorts of overhead for various layers in a stack your information bandwidth can be less than half the natural bandwidth.

    That is there is a lot of redundancy in the channel which can be used for purposes the user cannot see.

    The usual way of dealing with this is to fix the channel bandwidth at the lowest level to a known data rate (usually low) and clock the inputs and outputs with a protocol with absolutly minimum overhead and states and fail hard on error thus minimising various side channels (including those nasty little time ones). Thus the information effectivly fills the available channel.

    However this data rate limiting does not stop side channels if it is done within an application as a modified application does an end run arround the limit and uses the “unseen” bandwidth to communicate in (rather like an “Engineering Order Wire”). It realy has to be done at the lowest possible level (below the driver ie in the hardware is getting close)

    Pottentialy the worst case of available bandwidth to information bandwidth is the use of a phone camera to view a bar code on a web page.

    The actual “information” is about 1-4K bits, potentialy the visual channel between the web page and the camera is hundreds of megabytes depending on screen and camera resolution and the coding used.

    However as we know from digital water marking there is only so far you can push a covert channel in such a medium but it could easily be 2^4 or more times the “information”. This is simply because the information channel is almost invariably over engineered for one time reliability, whilst a covert channel can use simple averaging over many repeats to get the required level of reliability.

    So covert communication that the user cannot see can easily be taking place around/over/under the secure channel from the legitimate other end of that channel. Thus a man in the middle attack whilst simply acting as a faithfull relay to the secure channel is activly doing many times that rate of communications over the same communications path…

    Thus it is possible if the token uses device drivers etc for the malicious code to talk from the comms driver to the display driver compleatly running around the end of the secure channel which terminates in the application code…

    I could go on and describe it in more depth but I think you get the general idea of what is possible.

    However a point of hubris, I came up with a protocol back in the late 90’s to get the authentication into the users head using icons and such like, I have described it several times since using instead “capatchers”.

    I made the mistake of trying to trade of human adility at one thing against a computers inability to do the same thing (visual recognition).

    However as we now know various spamers etc get around this by subcontracting the work to humans in places like China for just a cent or so a key stroke…

    Such is the joy of security there is always a person with a different perspective on solving a problem.

    However I still think the financial organisations could go a long way with the likes of OTPs and tokens etc.

    Oh one last point. I conceade that for perfectly valid reasons tokens need to be mutable. However I thoroughly disagree that they should require code signing etc as the only bar, it must be physical and the fact that a change has been made must be obvious to the user.

    The lowest cost way to achive this is with a tamper evident seal, that is tamper evident in that it prevents the device doing anything untill it has been replaced by a new seal.

    The software industry has paid dearly (and continues to do so) over the false idea of “over the wire patching” it is a back door with very poor locks. It was done initially to reduce the cost of releasing product updates etc to the point where shipping shody software is ok simply due to the “no cost patch” later.

    From the security asspect the whole idea is a disaster and the temptation must not be followed by anyone developing security tokens etc. It will get hi-jacked at some point if the incentive is high enough and the cost of fixing it…

    Oh and also resist the urge for the “cheap fix” we have seen cheap fixes just turning so so crackers into uber crackers. Cheap fixes may look good on this quaters figures but 40 quaters later and having still not solved the problem is not cheap it is mind boogelingly stupid.

  • 10. Steven J. Murdoch  |  January 29th, 2010 at 17:33 UTC

    @Joel, Stephen

    Thanks for your comments. I think the rationale behind why I classed 3DS as a single sign-on system is both interesting and subtle, so I have written a separate blog post on this question.

  • 11. Mary Branscombe  |  January 29th, 2010 at 18:17 UTC

    I made a transaction that forced me to sign up for Verified for Visa yesterday – and the bank rejected it as coming from an insecure site. I can’t work out from what the customer service agent said whether they think the (fairly well known) retailer is dubious or whether it’s the same VFV iframe issue, but I’m going to carry on trying to boycott sites that insist on VFV ;-)

  • 12. Theo Markettos  |  January 29th, 2010 at 18:23 UTC

    Another data point… I know of one UK bank who set up 3DS using a default password of your telephone banking password. And, some years ago, when they set up telephone banking, the default choice of password was… your mother’s maiden name. As we know that isn’t hard to find out, or otherwise guess.

  • 13. Emmanuel Haydont  |  January 30th, 2010 at 23:55 UTC

    3d-secure is a very interesting protocol. It is modern, and offers full flexibility for the Issuer domain leaving a lot of space for adaptation to emerging authentication technologies and future evolutions. The basic principle of this original electronic protocol is its concept of three domains (Acquirer-Interoperability-Issuer), that has no conceptual flaw – on the contrary!
    What may be criticized is the authentication methods the Issuers have chosen. This is where the weakness is not in the 3d-secure protocol itself.
    A enigma for me is that no Bank has yet implemented 3d-secure with EMV cardholder and card authentication services, which would require a secure reader but would leverage on a standard that is – not brilliant but – mature and secure…

  • 14. Will Tatam  |  January 31st, 2010 at 12:05 UTC

    I totally agree with Emmanuel’s point and Joel’s question. Having implemented a generic interface to support 5 different major payment service provider’s 3DSecure enabled APIs I have read though a fair bit of implementation documentation from their various PSPs to find the common factors.
    While the quality of the PSPs side of 3Ds does vary both in terms of how easy it is to use and also secure the implementation is, I haven’t really seen any issues with 3DS itself.

    I dispute your argument that 3DS is a form of SSO, the basis for your logic is that the merchant does not know anything about the customer, so therefore it must be SSO. This isn’t really the case, what the purpose of the ASC is to provide a “signature” to the transaction that the merchant wishes to submit to the bank, it’s not an identification of the user, but an authorisation for an action. Therefore I would argue it’s closer to things like the Flickr api, where an application submits a request for an action (in this case the re-usable permission to upload) and the user logins into a central website to “sign” this request as being authorised by them

    As for the issue about Card Issuers running ACS from hosts not within the bank’s primary domain name, this is I agree totally retarded. After all, even if your subcontracting, how had is it for the there party to use a new vhost per bank !

    As for the issue of what Card Issuers are doing with ACS, I think it’s a little unfair to lump all the issues together. I agree that activation during shopping issue, but this is the inevitable drawback of a “soft” deployment where it’s rolled out bit by bit rather than the I love chip and pin February 14th style switch. The issue of what issuers then use for authentication is their issue rather than one relating to 3DS itself and is better suited being in a paper about online banking. The great feature of 3DS is just how disconnected from the merchant the ACS is and the flexibility that it offers. If issuer A wishes to create some iPhone specific ACS they can do that as enough detail is sent by the merchant prior to the user entering ACS. If issuer B wants to implement some groovy new as yet to be invented OTP token that works in conjunction with a voice recognition system, 3DS will support that.

    Who we really need to be giving a good kicking is the Muppets and penny-pinchers at the issuing banks that have subbed out ACS to 3rd parties, not spent enough on customer education and tried to cut corners by using ADS

  • 15. aack  |  February 2nd, 2010 at 01:23 UTC

    Now talking about of economics of papers: The post looks like written by Ross, it’s exactly what I’d expect from him, but in my opinion the paper so weak that it didn’t deserve Ross to be signed as a coauthor. It looks like Ross gave some sketch to Steven and the contribution of the later was poor. Then Ross saw that if he disown the paper the Steven will publish it anyway so he decided the less bad is if he signs him too. Sad.

  • 16. WilliamB  |  February 2nd, 2010 at 19:10 UTC

    @Andrew Main (#3):
    I’ve had this problem. I couldn’t use a PenFed cc to purchase online or over the phone from Target. I did not have the option to not be covered by VbV and Target wouldn’t accept the card without it.

    I didn’t make the purchase and consumed 30 min of Target customer service and days of PenFed VP’s time in the process of trying to buy and learning what the hell was going on.

    At no time during the process did anyone tell me that using VbV meant I was liable for any misbillings.

  • 17. WilliamB  |  February 2nd, 2010 at 19:14 UTC

    May I have permission to print out your paper? I would like to send it to PenFed. Right now it doesn’t seem to understand why using VbV is such a problem for its customers.

    Thank you.

  • 18. Mike Bond  |  February 2nd, 2010 at 22:32 UTC

    I think we need some new words. Theres been discussion as to what to call the protocol, what the name of the bit that might be bad should be, if the deployed system is a composite of protocols/implementations. The phrase I like is “protocol framework”.

    Is the protocol within a protocol just called an “implementation”, or is the implementation the actual code, and the protocol which it implements a combination of the framework and some proprietary spec document that never sees the light of day? (2 marks)

    EMV and 3DS appear to be similar animals: protocol frameworks. They specify the way things work — in part — and then there is freedom to do as you wish within the framework, including getting it right, fixing stuff up, pushing other protocols through it, or shooting yourself in the foot.

    Now, in the case of banking, if an issuing bank acts like a muppet, and the framework permits it, is the framework broken? (5 marks)

    What about if the issuing bank is clueful — or even rather smart — but there is a shortcoming in the framework that means they cant actually make the cool extension or feature they want without breaking the framework? (10 marks)

    So the fact of the matter is that protocol frameworks are partly, but not totally responsible for the quality of the space of possible implementations that lie within them.

    3DS has to take a bit of rap for what issuers feed through it, as does EMV. And dont even get me started on PKCS#11…

    Answers on the back of a postcard, please.

  • 19. Clive Robinson  |  February 6th, 2010 at 11:00 UTC

    Well TESCO customer support is rolling out the line on VbV that “they have no choice it is the card issuer who says it has to be used” (which is not true)

    After explaining this to various people on their”customer support this is not the case.

    They refused to pass on the call to somebody more senior and refused to hand over their own identifing details.

    Finaly after more preasure they handed over the following address for written complaints,

    New Tesco House,
    Delamare Road,
    Cheshunt,
    Herts,
    EN8 9SL

    But the customer support droid refused to give a name or department it should be marked for.

    So TESCO’s customer droids are breaking various rules etc.

    So does anybody know the name and correct address of a director level person to whom a formal complaint can be sent?

  • 20. Carlisle  |  February 16th, 2010 at 00:06 UTC

    @Clive Robinson:
    http://www.tescocorporate.com/plc/ir/corpgorv/boardcomposition/

  • 21. Steve Parker  |  March 6th, 2010 at 02:20 UTC

    http://thedailywtf.com/Articles/Verified-By-Fail.aspx
    - specifically: http://img.thedailywtf.com/images/201002/errord/verified_by_fail.png seems to sum it up

  • 22. James Lin  |  March 26th, 2010 at 16:10 UTC

    Hi,
    Can you take a look at this solution and give me your feedback?

    http://www.paymentseal.com

    Although it still has the pop-up involved, it is easy to implement and it does not require additional communication with issuing bank entity. 3D secure is designed to benefit the merchants while the PaymentSeal solution I’m proposing addresses the shopper’s concerns.

    p.s. The demo sites are not SSL secured, but in an actual implementation, there will be SSL.

    Your time and effort is much appreciated. J.L.

  • 23. Martin J  |  June 19th, 2010 at 09:32 UTC

    Does anyone know of a UK card issuer that still lets its customers avoid using the 3D Secure system?

    I recently asked First Direct, but was told that I couldn’t disable Verified by Visa on my account. I’ve avoided registering so far, but it’s getting harder and harder to buy things online without registering. There’s a bullying message telling you that future online transactions may be refused if you decline three times.

    On a related topic, has anyone tried using a card for face-to-face transactions with the CVV number obscured on the back of the card? It strikes me that the CVV number should not appear on the card, as it’s only necessary for cardholder-not-present transactions. But sometimes (e.g. in hotels) the CVV gets written down (even though it’s against the rules): I guess hotel staff must be tempted to take the path of least resistance, because the customer will complain if they pre-authorise a suitably large amount at check-in, even though that’s the correct thing to do.

  • 24. Eyal  |  June 28th, 2010 at 09:34 UTC

    I have been asked by different sites to use 3d secure and bypassed it during the process. If you try several times back and forth at the end somehow the process “forgets” you were supposed to register to it…..

    BTW what security gives you any service where you register to it online during the payment process!!!! if you hacked the real owner info you will use it anyway to register and pass the process with no problems….

  • 25. Ross Anderson  |  July 16th, 2010 at 19:07 UTC

    The Zeus botnet is now (July 2010) doing active middleperson attacks on 3Dsecure – see stories from The Register, Infosecurity Magazine, SC Magazine and Darkreading.

  • 26. Simon Phipps  |  March 13th, 2012 at 14:45 UTC

    Ross: Did any regulator engage on this subject? I’ve started working my way through all the options and finding none of them seem to want to touch the subject. Any information you have would be most welcome – thanks.

  • 27. Allen Jasson  |  March 23rd, 2012 at 15:42 UTC

    The root problem comes down to that mentioned by the author: While Mary guards and Bob pays for failures”. It has a resonance with Exon makes the profit while the general public pay for spills cleanup. This is the kind of gravitational slide that is pervading the whole system as wealth and power concentration applies it’s positive feedback mechanisms to weaken governments and regulators and contrive the whole system to the interests of the wealthy and powerful few. It’s epitomised in WAR where the taxpayer pays the bill for the process, wealth lends governments the money and supplies the arms and equipment at profit and the whole enterprise is to make the world safe for capitalism.

    This is a broad trend (A pays the bills B enjoys the benefits) in the whole capitalist system that can only come to a bitter end and there will be tears when it does.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

January 2010
M T W T F S S
« Dec   Feb »
 123
45678910
11121314151617
18192021222324
25262728293031