Referral links

Unlike other ads on this page, the two links below are to services I use - if you're looking for a new SIM or broadband connection I can personally recommend them, and these are specific referral links that I can get bonuses from if you sign up, so please use them :-)

Get a free giffgaff Sim Broadband from £5.99 a month with an included wireless router when you sign up to Plusnet - terms apply

Wednesday, 10 February 2010

3DS - Verifed By Visa/SecureCode insecure

[ Shortened link to this page if you need it - ]

Don't let the apparent length of this article put you off, the main body of the article is up to the first horizontal line, everything after that consists of transcripts from conversations with the banks

Many credit/debit card vendors are now enrolled in one of two schemes depending on the type of card. Visa ones use VerifiedByVisa, and Mastercards use SecureCode. They are fundamentally the same 3D-Secure system (henceforth '3DS'). I'm sure most of you have seen sites that use it during checkout. Initially you register your secret password, and when performing a checkout on a merchant's page, you are presented with (as recommended by Visa) an integrated IFRAME (an IFRAME is a window within a window for the less-technical readers) asking you to put in 3 characters from your password, or to register if you haven't already.

The banks tell us that this is done 'for additional security to validate the person who is trying to use the card', and yes it does that. But in my opinion the system's security is flawed.

Firstly, it's quite possible you haven't even noticed this, but the embedded IFRAME that shows up isn't even part of the merchant's site. It is actually displayed from your bank, or a site administering 3DS on behalf of your bank. So even though you've made sure you're on a secure encrypted web site by checking the yellow bar in your browser (and possibly checked the associated certificate too) you probably wouldn't think to check whether the IFRAME is encrypted at all, even less to check where it's coming from or where it's sending bits of your password to:

The image on the right (click it for the full size version) shows what you get if do actually make the effort to bring up the details for a 3DS frame in your browser. Given that users are generally not clearly told that they should verify this SSL certificate, you don't know where their password might be getting sent to, therefore it could easily be a middle man without your knowledge.

Where are users told to verify the embedded IFRAME SSL certificate ... on Twitpic

Some banks make it even worse than what I've just described. The screenshot I've just showed you above clearly shows that the SecureCode frame is coming from Barclays Bank from their domain. However, as hinted earlier, many banks outsource the SecureCode/VerifiedByVisa authentication to a third party. In the UK, is one such site that's regularly used for outsourcing, and if you looked at the URL and saw that, wouldn't it set of alarm bells and make you think it was a phishing site looking to steal your details?

For the record, is a genuine server used for authentication - if your bank uses it you will have been redirected there the first time you registered (either during checkout, or via your banks registration page), although you may niot have realised it. However there isn't even an information page at to give you any indication of who they are, which makes it look even more suspicious. Here is an equivalent screenshot from another bank which outsources to, showing the security details you get when you right click to bring up the IFRAME's info (on the right) and by bringing up the details from the main page(the merchant's info, on the left) clearly showing the distinct SSL certificates:

So most users:

  1. probably don't notice it's an embedded IFRAME, but even if they did:

  2. wouldn't check to ensure that the IFRAME's content is encrypted

  3. won't separately check the IFRAME's SSL certificate,

So with this in mind how can we, as customers, have confidence that the password is actually being sent to your bank instead of some thief? The 'Personal Greeting' that you define when registering for the service gives some confidence that the IFRAME's content originated from your bank, but unless you verify the source of the IFRAME you cannot know that the merchant or other intermediary isn't sending your browser to a third-party performing a man-in-the-middle attack to get your Personal Greeting or password characters. So the level of extra security provided by these systems is not as much as the banks might have you believe.

Fundamentally, it's not making my transactions any more safe unless the card is actually stolen/copied. And even then, the system isn't universal so won't stop all transactions (such as 'cardholder-not-present' ones) going through. And resetting the code is easier than it should be for a dedicated thief. Even ignoring that, if a thief took you're details, wouldn't they just use it on a site that doesn't support 3DS checkouts? There seems to be little additional real fraud protection for the end user in this system.

I have tried contacting several Financial Institutions using these systems to see if they could alleviate my concerns (see previous article in my blog for info on how easy it was to contact each bank). The question I asked was about how I knew where my password characters were being sent to when the page is in an IFRAME. The banks should be able to respond to these concerns, and give customers confidence that they treat internet security seriously. I hoped at the very least to get a reply telling me that the Personal Greeting shows that it is genuine, but the true answer is of course that users should also verify the IFRAME's SSL certificate. Banks need to make that clear to give the impression they understand internet security.

Visa explicitly recommend that merchants use an IFRAME to make things simpler for the user, but they do acknowledge that there is an potential cardholder concern in this area in some of their implementation documentation, which I cannot repost here. Those comments are probably true, and at least acknowledge the potential issue, but PayPal seems to work ok without an IFRAME, and I personally havne't heard many people complain about that.

NOTE: While drafting this I was pointed by a colleague on twitter to a good article written recently while I was researching this myself (Coincdentally I posted the first screenshot above to twitter about a day before that article was published!) from a couple of guys at Cambridge University who had come to the same conclusion as me. That 3DS security is flawed from the perspective of the end user.

The dialogs below are complete and unedited other than reflowing text and removing signatures/headers/standard footers from the messages to keep the size of this post down. Automated confirmation "We have receieved your message and will reply shortly" type emails are ommitted. The original text sent to each bank was more or less the same, with only minor redrafting. Why not send this to your bank and post the response you get? (Replace Mastercard Secure with Verified By Visa if that's what your bank uses)

Hi, I'm struggling to properly understand Mastercard Securecode. Is
there a proper technical overview of the system somewhere that does
just basically say 'You should register a password for your security'?
There isn't much more info on Mastercard's own web page.

If I go to a merchant's site, the securecode validation is integrated
into their own page, and the referring site's SSL certificate is still
the one displayed on the page. So how do I verify that I am being
challenged by you, and not a Trojan Horse? From what I've seen,
SecureCode gives NO WAY of allowing me to validate the source of the
challenge, and therefore does not provide much more benefit over the
CSC, unless the card is stolen.

For completeness I also tried contacting Visa and Mastercard directly. Mastercard haven't responded, Visa initially responded referring me to the personal message which is displayed, but when I replied probing further into the security of the IFRAME I didn't get a response.

Barclaycard (Terms1 Terms2 - different wording on each!)

Barclays put up a bit of a fight, insisting that "for security" they had to verify who I was and wouldn't answer the question via email. This is nonsense, the question is not account specific and they should be able to respond to this query from a potential customer who doesn't already bank with them. Not a good start to finding out which companies take security seriously.
BANK: When you purchase online, Barclaycard Secure issues a receipt at the end of the checkout process.
BANK: The receipt includes details of your current purchase, such as site name, purchase amount and date.
BANK: You sign the receipt using your personal password and click 'Submit' to proceed with the purchase.
BANK: Without your password, the purchase cannot take place.
BANK: Since your card is protected by your personal password only you can use your card online.

SXA: This reply shows that you clearly haven't understood my original
SXA: question which was as follows:
SXA: "So how do I verify that I am being challenged by you, and not a
SXA: Trojan Horse? From what I've seen, SecureCode gives NO WAY of allowing
SXA: me to validate the source of the challenge,"
SXA: Please pass the request onto someone who understands web security to
SXA: answer this question. How do I know that the receipt that's shown to
SXA: me is coming from Securecode and is not a fraudulent page just trying
SXA: to acquire my password. Since the receipt is *embedded* in the
SXA: merchant's page instead of coming up in a new window (which seems like
SXA: a fundamentally bad design), there is no easy way (and certainly none
SXA: which the average user will do) to verify that the challenge is coming
SXA: from Barclaycard, since the browser (by default) is only showing the
SXA: SSL certificate for the merchant's site.
SXA: Having looked at the way it's implemented a bit more, I'll ask another
SXA: question: Since the securecode challenge is inserted into a frame, are
SXA: users expected to verify the SSL certficate of the securecode  frame,
SXA: and if so where is this documented? Otherwise, the security level of
SXA: the securecode system is something of a joke, and I could quite easily
SXA: create my own web site selling things and pop up something that looks
SXA: like securecode frame and the user wouldn't have a clue. It's not even
SXA: obvious to the user that the inlined frame is SSL because the URL of
SXA: it isn't visible unless you go looking for it.

BANK: Due to our strict security policy, we are unable to take any direct action
BANK: from e-mail queries or requests sent via a non-secure e-mail channel, as
BANK: we are unable to identify if we are communicating with the true customer.
BANK: We are only able to take action from specific queries or requests if they
BANK: are sent via our secure e-mail facility, which is through 'My Account',
BANK: on our website.
BANK: In order for us to effectively be able to resolve your query, please call Barclaycard
BANK: Customer Services on 0844 811 9111, or from abroad on ++ 44 1604 230230 to
BANK: clarify the relevant details.  When calling Customer Services, press 6 and you will
BANK: be transferred to a Customer Account Manager.
BANK: I hope this information helps you and if you have any more questions, please feel
BANK: free to contact me again.

SXA: I was NOT asking for any account specific information. I was looking
SXA: to understand your policies regarding internet security and get
SXA: answers in writing via email so I have a record of them. If you are
SXA: not willing to divulge this information then you clearly don't take
SXA: security particularly seriously if you're not willing to answer my
SXA: request for information for details on how the SecureCode system
SXA: works.
SXA: Nothing in my request should be related to whether or not I am an
SXA: existing customer.

BANK: We want to help answer your query but as your query is regarding your account
BANK: we can not help you further via this channel.

At this point I tried using their secure communications mechanism, which failed to correctly send the message. Barclays then called me to discuss the issue, but the person on the end of the helpline clearly didn't understand internet security any more than whoever was replying to my emails, and so I didn't get a response. I still have an outstanding request on this via their secure communication channel, but haven't heard anything back after over a week. Not a good impression from what is probably the UK's most well known credit card company.

*UPDATE*: Barclays did finally get back to me on March 3 (The last message I sent them was on February 9) with this response:

In reply to your query, I would like to assure you that Barclaycard Secure is a
legitimate, free service offered by Barclaycard in association with Visa and
MasterCard. This service enables you to validate your online payments by supplying a
password known only to you and your credit or debit card issuer.

May I advise you that Barclaycard takes the issue of hacking very seriously and have
put in place all the necessary steps to store your data securely. The registration
pages are a secure Barclaycard site.

The personal information you are supplying is used as a security measure to make
sure you are the real cardholder. The information you supply is verified against the
data stored in the Barclaycard database. 

May I also explain that how Barclaycard secure works:

Your bank, or credit card issuer may ask you to register for the service during the
payment process, or ask you to register using their website independently. 

To register you will need to enter some information about yourself and your account,
and set up your 'personal greeting message' and your 'password'.

Following your registration, each time you use your card online to pay, your card
issuer will request the password that you?ve specified, and will also display the
'personal greeting message' that you specified. This is an extra check - just so
that you know the request for your 'password' is really from your bank. 

By correctly entering your password-Secure Code when making a payment, your issuer
is able to confirm that you are the authorised cardholder. If an incorrect Secure
Code is entered, the payment will not be completed. Even if someone knows your
credit or debit card number, the payment cannot be completed without your Secure

In regard to your question, "How do I know that this site is safe and will not
result in my details being phished?"

Barclaycard takes the issue of internet security very seriously and have put in
place all necessary steps to store your data securely; the site has been approved by
both Visa and MasterCard who regulate our actions. 

Each time you make an online purchase at a participating store/retailer, you will be
prompted to enter your Secure Code. At this time, you'll see your 'Personal
Greeting' and other purchase details. The 'Personal Greeting' is your assurance that
you are communicating with your card issuer. If the 'Personal Greeting' displayed in
the pop-up box is incorrect, you should not enter your Secure Code, but should
instead contact Customer Service immediately by calling the phone number on the back
of your credit card, to report a possible fraud.  

You can find out more information, or activate Barclaycard Secure on your
Barclaycard by either: 
-  visiting the Barclaycard website at: (Click on the Credit
Cards section of our home page and then you?ll find a link to Barclaycard Secure at
the end of the page on the left hand side).
-  or by choosing to activate the service if you are prompted during shopping online
with a participating retailer. Just check that the retailer you are shopping with is
registered with 'Verified by Visa' or ?MasterCard SecureCode'.
For more information about protecting your security online, visit the 'Security
Information' section on the Barclaycard website. You'll find a link to it at the
bottom of all our pages. 

I hope that this information is of assistance to you.

Should you have any further queries, please do not hesitate to contact me.

Barclays, I wasn't looking for a description of how the system worked, I can find that out anywhere, I want to know how the system protects against man-in-the-middle accounts, which the 'Personal Message' doesn't do, and saying it is "Approved by Visa and Mastercard" doesn't answer the question I'm afraid.

Bank Of Scotland (Terms)

BANK: In relation to your query, I can confirm that the Halifax Secure system is
BANK: purely a password based authentication application. It is an extra layer of
BANK: security that will authorise the merchant's website to connect to our banking
BANK: servers to request the funds, only if the correct password is provided.
BANK: Not all website's are involved in this free service, which is run independently
BANK: by Visa and Mastercard. Therefore, you may not encounter it every time you
BANK: attempt an online purchase.
BANK: More information can be found at

SXA: Hi, thanks for your reply, however you have not addressed my specific question:
SXA: The SecureCode request comes up embedded in the merchants' pages. When the
SXA: SecureCode prompt comes up, how do I verify that I am being challenged by you,
SXA: and not a Trojan Horse?
SXA: Unless I am able to verify who I am giving characters of my SecureCode to, the
SXA: whole mechanism is insecure.

BANK: I am sorry that the previous response didn't answer your query.
BANK: I am currently looking into this matter, and will contact you again as soon as I
BANK: have the information for you.

At this point I didn't hear back, so after two weeks I followed up:

SXA: Any update on a response to this question?

BANK: I am sorry for the delay in my response.
BANK: Please be advised that when you register for the Secure Service, you are asked
BANK: to register a password and a PAM (Personal Assurance Message).
BANK: When the Secure box comes up this message is always displayed, this then gives
BANK: you confidence to enter your password as this message will only be on our
BANK: genuine Secure pop up box.
BANK: No one except the cardholder would know what the message was set at time of
BANK: registration therefore this gives assurance that the request is genuine.

SXA: Firstly, thanks for your response Johanna. Most of the banks I deal with struggle
SXA: to understand the question, and the reason I'm asking is to make sure that banks
SXA: take these sorts of concerns seriously. And I'll stop dealing with the ones that
SXA: haven't given me a straight answer :)
SXA: While I agree that the PAM appears to provide some level of assurance, but what
SXA: is there in place to avoid man-in-the-middle attacks? Without knowing the
SXA: identity of the site that appears within the inline frame (which is often a third
SXA: party such as, I can't remember if HBOS uses that one or not) I
SXA: can't tell if the merchants web site is sending me to a genuine VbV/SecureCode
SXA: site. As far as I am aware, there's nothing to stop a merchant directing my
SXA: browser to a trojan/phishing site that is able to act as a proxy to obtain my PAM
SXA: and present it to me during the checkout without my knowledge. Or alternatively,
SXA: is there anything to stop the merchant itself from obtaining my PAM and
SXA: displaying ithat to me inlined into the checkout page?
SXA: From the implementation documents I've found I couldn't see anything in the
SXA: transaction flow preventing this. Would you agree? (Obviously if I'm right, I'm
SXA: not going to hold it against you, since it's Visa/Mastercard's issue, not yours!)

No response to this so far. They did reply without too much delay, usually within 24 hours to each email I sent with the exception of the delay in the middle. So a good effort from HBOS, and they included URLs referring me to documentation

First Direct

BANK: When you register your card for Verified by Visa you also set up a 'personal
BANK: assurance message'. When ever you are asked for your password your personal
BANK: message is also displayed, this is how you can be sure it is a genuine password
BANK: request. If a fake site tried to ask you for your password it would not know
BANK: what your personal message was.
BANK: You can find out more about Verified by Visa on our website under 'credit
BANK: cards', then 'online card security'. Alternatively, you can visit it the Visa
BANK: web site here:

SXA: Thank you very much ----. You are the first bank I deal with where
SXA: I've asked this question and received a straight answer first time,
SXA: given references and actually given me confidence that you understand
SXA: the question :-)
SXA: While I agree that the personal message provides some confidence that
SXA: the password request initiates comes from a genuinely authorized
SXA: system, is there anything to prevent man-in-the-middle attacks, for
SXA: example if the merchant's embedded IFRAME pointed me to a trojan site
SXA: that proxied my request through to the VerifiedByVisa site and was
SXA: therefore able to obtain my personal message that way.
SXA: From the Visa merchant implementation documents I couldn't see
SXA: anything in the transaction flow preventing this. Would you agree?
SXA: (Obviously if I'm right, I'm not going to hold it against you, since
SXA: it's Visa/Mastercard's issue, not yours!)

BANK: Trojan viruses usually work by obtaining information by monitoring your key
BANK: strokes so your personal assurance message should not be intercepted.
BANK: We would advise you to keep your anti virus and firewall up to date with the
BANK: latest definitions to protect your computer.

SXA: You've slightly misunderstood what I meant. Assuming my own computer
SXA: is virus-free, what is there in the VerifiedByVisa protocol to stop a
SXA: malicious vendor's web site redirecting my browser to a third party
SXA: site (man-in-the-middle attack) that proxies the VerifiedByVisa
SXA: request to the real server and can therefore acquire my personal
SXA: message?
SXA: To clear up any confusion, I was referring to 'Trojan web site' to
SXA: refer to a potential man-in-the-middle server masqerading as an
SXA: official VerifiedByVisa server (ACS I believe is the correct
SXA: terminology). With VbV's recommendation of IFRAMEs it's not obvious
SXA: where the VbV request is going to unless you know to look at the SSL
SXA: details of the IFRAME, and I'm not sure anyone actually recommends
SXA: doing that.

BANK: We appreciate your feedback which has been passed forward to our Project Design
BANK: Team who are responsible for future enhancements to the service. Thank you for
BANK: taking the time and trouble to write to us with your comments on the service.

This is the best response I've had from any of the banks I contacted, and probably as good as I'm going to get. The above exchange occurred over the course of a day, so they were quick to respond. They clearly understood the question because the first reply told me that the personal message gave me some security, and although they didn't admit any flaws in the protocol or tell me to check the SSL certificate, they at least didn't try to feed me false information, and gave me some URLs with information. I guess this is the reason First Direct come out top of many customer satisfaction surveys.


BANK: Unfortunately, this channel is for general enquiries only
BANK: and to protect your personal details we are unable to
BANK: respond to account-specific queries. Please call us or
BANK: write to us using the details below, and one of our
BANK: Customer Service Advisors will be able to help.
BANK: Call us on: 0870 908 6000^
BANK: Write to us at:
BANK: Citi Cards
BANK: PO Box 49920
BANK: London
BANK: Please contact us on 0870 908 6000 for further assistance.
SXA: This is *not* an account specific query. It is a general question about
SXA: SecureCode and bears no relation to whether I am an existing customer or not.
SXA: Please answer via email.
BANK: Please be informed that we have arranged for a callback
BANK: regarding this. You will receive a call from us shortly.
BANK: We request you to contact us on 0870 908 6000 for further
BANK: assistance.

After two working days (that message was on Friday evening, I contacted them again on Wednesday) they called me at a time when I wasn't at my phone, and left a message regarding securecode. The last 2 seconds of the message were unintelligible so I've no idea what they were going to say.

I followed up with another support request saying that I had given up because of the voicemail that was left for me, and received a call on the next working day. The person who called me (from a withheld number) initially6 tried to ask for my identity, because he seemed to be looking to guide me through the SecureCode registration process. Once I convinced him I wasn't (clearly he hadn't read the previous communication properly) he explained the workflow, and said that you should check that the certificate for the page is valid via the lock symbol in the browser (which would only verify the merchant's site, not the SecureCode IFRAME) but was unable to give any assurance that I was typing my password characters into a secure channel. He just said "Your details are sent to the Mastercard server and if the password is rejected the transaction will not go through. That's how the system is designed". And further went on to say that my question was too technical for him to be able to give any further answer (although he did appear to understand the question by the end of the conversation). So yes, that's how the system is designed ... badly ;-)


Santander's FAQ is better than some of the others and tells you to check the Personal Message, so there wasn't any point in asking them the initial question about how I check the source of the password request, so I went in with a lower level question:

SXA: Most merchants just seem to say the Mastercard SecureCode (and
SXA: VerifiedByVisa) are 'for your own security' but don't go into much
SXA: details as to why. My specific concern in the protocol is as follows:
SXA: If I go to a merchant's site, the securecode validation is integrated
SXA: into their own page, and the referring site's SSL certificate is still
SXA: the one displayed on the page. So how do I verify that I am being
SXA: challenged by you, and not a Trojan Horse? Although there is a
SXA: personal greeting (and your FAQ is particularly good at mentioning
SXA: that you should check it) but that doesn't stop a man-in-the-middle
SXA: attack where a third party intercepts the request and obtains my
SXA: personal greeting. So ultimately, SecureCode gives NO WAY of allowing
SXA: me to validate the true source of the challenge, and therefore does
SXA: not provide much more benefit over the CSC, unless the card is stolen.
SXA: So when I'm using 3D-Secure through SecureCode, how am I expected to
SXA: know where the request for my password is coming from? Unless I can
SXA: check that, the whole system is pointless from a security perspective.

BANK: Thank you for your e-mail regarding Verified by Visa.
BANK: The Verified by Visa system is in place on a large number of websites where a customer can 
BANK: make a purchase. The details requested, would require you to have the card, account
BANK: details and your own personal details including a password.
BANK: When you are making a purchase from a website, the initial card details etc you enter are 
BANK: for their information, however to verify these details are valid, the Verified by Visa box 
BANK: will appear under a different security certificate (Santander's) to ask further security 
BANK: information so that we can confirm you are the account holder and that there are 
BANK: sufficient funds to pay for the purchase.
BANK: The box requesting this information should always have the 'padlock' symbol in the bottom 
BANK: left hand corner - this is to assure you that the information is from a secure source. We 
BANK: have never experienced any security breaches or viruses etc through using this system, 
BANK: however if you are ever unsure of where the request has come from, for your own piece of 
BANK: mind feel free to call us on 0845 600 4388 - we're open from 7am - 11pm Monday - Saturday 
BANK: and 9am - 9pm on Sundays. You can also check any updated online security information 
BANK: through our website by selecting 'security & privacy' and then 'online 
BANK: security'

SXA: Firstly thanks for providing such a complete reply. No other bank I've contacted so far has 
SXA: correctly referred to the source of the IFRAME's separate SSL certificate. While I 
SXA: understand that you have never seen any security breaches, my concern is that it is 
SXA: possible to exploit the system, and the fact that you've never seen anyone do it doesn't 
SXA: alleviate the concerns around it.
SXA: However, in theory the merchant's web page could redirect your browser (either intentially, 
SXA: or through a malicious man-in-the-middle) to an intermediate site which would be able to 
SXA: intercept the VbV (Verified By Visa) challenge, acquiring your personal message and 
SXA: receiving the password characters you type.
SXA: As you correctly say, verifying the certificate as being from Santander protects against SXA: this, but that doesn't show up if you use the 'lock' icon to view the site's certificate - 
SXA: it only shows the merchants certificate details on the browsers I've tested. So unless 
SXA: people know to check the IFRAME's certificate explicitly, they won't be able to identify 
SXA: for certain who they are communicating with, only that the connection to 'someone' is 
SXA: encrypted. 
SXA: One further thing - you referred to the frame including Santander's own security 
SXA: certificate, but your VbV registration page is on the third party web 
SXA: site. I assume this means that your customers (assuming the unlikely case where they check 
SXA: the SSL certificate) are expected to accept securesuite's certificate, which actually 
SXA: doesn't look like it has any link to you (so initially looks like a phishing site).
SXA: It's potentially worth changing your FAQ to indicate that securesuite is an official 
SXA: provider of the VbV service for Santander.

So they did give a good answer at the beginning, and didn't try to hide behind any other security measures. They were the first bank to actually respond in a way that gave the impression they understood about the IFRAME's separate security credentials. So well done to Santander (even if they didn't go quite as far as admitting there was a potential issue, they did say they haven't experienced any such attacks - wishful thinking?)

No comments:

Post a Comment