3DS - Verifed By Visa/SecureCode insecure
[ Shortened link to this page if you need it - http://goo.gl/n22x ]
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.
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 barclays.co.uk domain. However, as hinted earlier, many banks outsource the SecureCode/VerifiedByVisa authentication to a third party. In the UK, securesuite.co.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, securesuite.co.uk 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 http://www.securesuite.co.uk 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 securesuite.co.uk, 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:
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)
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.
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:
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)
At this point I didn't hear back, so after two weeks I followed up:
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
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.
Citibank
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
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:
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?)
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.
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 barclays.co.uk domain. However, as hinted earlier, many banks outsource the SecureCode/VerifiedByVisa authentication to a third party. In the UK, securesuite.co.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, securesuite.co.uk 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 http://www.securesuite.co.uk 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 securesuite.co.uk, 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:
- probably don't notice it's an embedded IFRAME, but even if they did:
- wouldn't check to ensure that the IFRAME's content is encrypted
- 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: 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: 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: 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: 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: 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: 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: 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 Code 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: www.barclaycard.co.uk (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: 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: BANK: More information can be found at BANK: http://www.halifax.co.uk/bankaccounts/secure.asp. SXA: Hi, thanks for your reply, however you have not addressed my specific question: SXA: 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: 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: 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: 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: 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: 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 securesite.co.uk, 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: 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: 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: http://www.visa.co.uk/security/main.html 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: 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: 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: 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: 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.
Citibank
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: BANK: Call us on: 0870 908 6000^ BANK: BANK: Write to us at: BANK: BANK: Citi Cards BANK: PO Box 49920 BANK: London BANK: SE5 7ZF BANK: 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: 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
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: 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: 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: 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: 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: 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 www.santander.co.uk by selecting 'security & privacy' and then 'online BANK: security' BANK: 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: 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: 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: 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 securesuite.co.uk 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: 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?)
Comments
Post a Comment