Saturday, 13 February 2010
I'll share my experiences:
Contact was via this online form. You get a confirmation email that your message has been receieved fairly quickly, and then get a reply later. Each successive reply comes in with a different subject line (basically a reference number seems to get added) which messes up threading somewhat. Although it's not on their web site, I assume the email address works directly instead of via the form.
At one point they asked me to continue the discussion via a secure communications channel. This seemed like a good idea, other than the fact they're secure form doesn't accept special characters, which includes apostrophes and limits your message to 750 characters. If you put apostrophes in, it just says "You have not completed all required information" and gives you no indication of why it hasn't accepted your message.
Bank Of Scotland
Unfortunately, Bank Of Scotland don't seem to want you to email them with general enquiries and say you need to be registered and log in to send an email to them. Disapointing, especially given that even they say on that page that you can discuss non-account specific information via email. So why not open it up?
To be fair, Bank Of Scotland were the only organisation where the exchange of emails threaded properly in my mail reader, which is a great help for records.
Email address provided on their 'Contact Us' page. Nice and simple. However threading of emails didn't work though for some reason.
They have a contact page that you fill in to send details to them and they reply via email.
This sounds good, but in practice you get an email back with a return address of email@example.com, which you obviously can't reply to. In my case they failed to answer my question and on the second attempt (for each contact attempt I had to submit another request on the contact page) they emailed on Friday evening to say they'd call me back, and I've heard nothing up to the following Wednesday. Sent another request through the web site to complain about not getting a call. They called on Thursday when I wasn't at the phone and left a frankly unintelligible message. I sent another request, and got a call back on the next working day where I was able to discuss the issue with a representative who appeared not to have read my previous communications. Overall, a bit more work than it should have been.
I tried to find a way to contact them, but like Bank Of Scotland, it wasn't possible without having an account with them.
Very similar experience to First Direct, although finding the email address was more tricky. It was findable through their SecureCode FAQ which is on the external securesuite.co.uk site. Again like First Direct, threading of emails didn't work as expected.
They made it easy, with a direct email address on their contact page
Visa also makes it easy to contact them via email via their contact page. They also were the only company I contacted which included the history of the conversation in their replies, so I didn't have to go back to remember what I'd said to them, which was useful given that they took a few days to reply :)
Friday, 12 February 2010
So, given that my second choice for a replacement handset would have been the Motorola Droid/Milestone, I was quite pleased to find http://www.androidonhtc.com which hosts a project for running Android on several of HTC's Windows Mobile devices (recent ones like the HD model's aren't supported yet).
It doesn't actually replace Windows Mobile - that remains as the primary OS that the device boots into. What it does is use a little utility called 'HaRET' which you run under windows which reboots the whole device into Android, similar to what loadlin did for DOS years ago - basically the running windows image is replaced by a Linux kernel and a copy of Android. Installation of Android is just a matter of dumping the files onto either the root of your memory card on an 'android' subdirectory thereof (Internal Storage on the Diamond), copying the appropriate device configuration file to 'default.txt' in the place you extracted to, and running HARET. The first time it starts up it takes a bit longer because it automatically creates a flat file to use as it's filesystem, but it's all automatic. Simple ...
Also if you choose to keep everything in an 'android' subdirectory then you can keep multiple versions on the card and rename whichever one you want when you're ready to start it. Great for testing things on different OS versions!
The first version I installed (which was the 24th January 2010 build, first on the download list at the time of writing) had a very bad problem where it was soaking up very large amounts of battery power. I couldn't figure out why since even after stopping everything I could (removing the connection to my google account, disabling wireless, disabling bluetooth, stopping location updating) it still didn't allow the device to run for more than 2-3 hours. I've now replaced it with a different build and it's working better.
 - I'm not sure why but I couldn't get any of the older ones didn't work. It didn't clear the Diamond's screen properly and just froze (A black line appeared on the left of the screen but that's all). Note that some earlier versions are designed to be installed into the root of the memory card/internal storage, not in an 'android' subdirectory. I'm hoping all future ones will be ok under 'android'
Once you get used to what all the buttons do, it works really well and is a great way of giving me an Android device for free, so congratulations to the team responsible for making this stuff available to us! It's not perfect, the camera, and some other things aren't yet supported but most of the other bits work. I'm currently booting into Android 2.0.1 from February 2nd, 2010, but various versions are available and the fact that everything's in its own directory on the memory card means that backing up and trying a new version is easily done by just renaming the old directory, and restoring it if required.
Now do I want to start getting into Android development, or will I just leave it as a toy?
Wednesday, 10 February 2010
I wired up my N900 into my car's monitor a while back. TV-Out is one feature that seems to be limited to only a very small number of handsets at the moment. Nokia has been doing it with the high-end N-series handsets since the N95, and the N900 continues that, being supplied with the CA-75U cable required to transmit audio and video to an external screen. It is only composite video, so don't expect the quality to be fantastic, but it means you can wire the N900 up to a projector, a hotel TV for playing any video files stored on the unit, or in my case the screen in the dashboard of my car.
I don't have any integrated satellite navigation in my car, so having the ability to use Ovi Maps on the screen in front of me is a great help. Now if Nokia will hurry up and release their new, free, turn-by-turn navigation for the N900 it'll be a perfect solution. Unfortunately, wiring in the CA-75U cable to the back of the head unit has meant that I don't have a spare for other uses, but since they are very cheap to pick up on ebay that's not a problem, and I've ordered a couple of them - one for office use, and one for everything else.
I guess with a good enough connection, you could also use it to stream your favorite YouTube videos to show all your passengers, but of course don't distract the driver when doing that ;-)
 - For the record, I think it's great that Google and Nokia are giving navigation software away now, because tomtom has charging way too much for it's phone navigation up to now, and I hope this hits them hard. I would happily have bought TomTom mobile for previous devices, but it needed to be half the price, and without the restrictions on moving it between devices.
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
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.
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'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?)