Verifying Verified By Visa - Registration breaks chain of trust

The UK banks are encouraging us to join Verified by Visa (and the equivalent from MasterCard, to which this issue also applies), and may soon make it effectively compulsory. However the marketing people in both Visa (MasterCard) itself and the UK banks do not seem to understand the authentication principles on which it is based.

What they are doing is providing a link, for registration, to an unknown US company, Cyota Inc (masquerading under a UK domain name), or at least that is what I see on the versions of their pages that I have fetched. The problem is that the Visa and bank VbV pages are on their insecure sites, so there is no protection from being fed a fake version of these pages pointing to the https site of a man in the middle.

I tried asking for confirmation of the Cyota URL over one of my internet banking sites secure mail system, but the support person refused to confirm the URL, saying the only URL they could provide was that of their insecure page. Basically we have people who hopefully understand the issues, who developed VbV, but marketing and support people who don't understand the issues and undermine its security.

Does anyone know of a well known UK bank that uses the Cyota service and provides the signon link from a secure page, with an SSL certificate that belongs to them? Otherwise, the main hope is that someone in VbV or UK banking who actually understands the principles upon which VbV is based and has influence with marketing will read this.

Whilst these links have pointed at Cyota for some time, so it is most unlikely that they are other than legitimate agents for the banks, I still feel unhappy having to rely on such weak tests of authenticity.

Reply to
David Woolley
Loading thread data ...

I'm probably missing something here - but I don't understand your concern. Why is the link to the signon page from a normal ("unsecure") http page a problem?

Most banks have links to their interbank banking signon page from a normal http page, and always have done, and sometimes that's the only way to get to the signon page.

Provided they don't ask for the security details on the unsecure page what's the problem?

Or are you thinking of a DNS server/host file hijack type scenario?

-- Andy

Reply to
Andy Pandy

I read the terms and conditions when it first sprung up in front of me, and since it seemed to change a number of fraud scenarios to be my liability rather than the bank's, I declined it. It may make fraud less likely, but I don't see why I should accept extra fraud liability for doing so - that was too one-sided. So far, one company lost my business by using it, and another had to take a phone order rather than an on-line order.

Reply to
Andrew Gabriel

I've had the same problem with my bank, who insist that VbV increases security. I've explained that I am being asked to submit a password to an insecure third-party site, and that password is one of the ones used to access my online bank account. So I have gone from having that password in my head to access one system, to it being sent to an unknown third-party. I am also concerned that in order to do this I was required to enable javascript, thus opening up another vector for no good reason. From the conversations I've had with my bank it's clear that they don't "get it" and that they have been programmed to regurgitate the "VbV Is Good" marketing message.

Reply to
Chris Lawrence

same thread in comp.security.misc

formatting link
Verifying Verified By Visa - Registration breaks chain of trust
formatting link
Verifying Verified By Visa - Registration breaks chain of trust
formatting link
Verifying Verified By Visa - Registration breaks chain of trust
formatting link
Authentication in the e-tailer / payment gateway / customer triangle
formatting link
Authentication in the e-tailer / payment gateway / customer triangle
formatting link
Authentication in the e-tailer / payment gateway / customer triangle

we had been brought to consult with small client/server company that wanted to do payment transactions on their server and had this technology they had invented called SSL they wanted to use ... the result is now frequently referred to as electronic commerce. Part of what was done was something called a payment gateway ... and we mandated some amount of the useage interface between the webservers and the payment gateway ... including implementing something called "mutual authentication" (which wasn't implemented at the time). misc. past posts mentioning payment gateway for electronic commerce

formatting link
we also did detailed protocol and business process walk thru of SSL, digital certificates and these new businesses calling themselves certification authorities.

for the payment gateway process, SSL mutual authentication evolved to the point where it was apparent that digital certificates were redundant and superfluous ... and there use was just a side-effect of using the existing SSL software library ... aka the payment gateway had table of all authorized webservers and each webserver had table with details about the payment gateway (so obtaining the corresponding public key from a digital certificate was superfluous).

also, at the time, the use of SSL domain name authentication ... by clients were based on some business process assumptions ... in order to result in:

the webserver that a client is interacting with ... is the webserver that they think they are interacting with

aka

1) the client understood the relationship between the server they wanted to talk to and the server's URL

2) the client supplied the URL to the browser

3) the browser validated the digital certifcate obtained from the server

4) the browser validated the URL corresponded with the URL in the (validated) digital certificate

misc. past posts mentioning SSL domain name digital certficates and/or domain name digital certification

formatting link
Almost immediately electronic commerce webservers discouvered that SSL cut their thruput significantly and they dropped back to using SSL just for payment/checkout. This created a large disconnect in the assumption about the SSL business process and the associated integrity/security that it provided. No longer was SSL being used to validate the URL provided for initial contact.

The payment/checkout paradigm has the (typically completely unvalidated) webserver making claims about a button that is clicked on. The client clicks on a button which results in the webserver supplying a URL to the browser (not the client). This now typically creates a huge disconnect between the webserver that a client thinks they are talking to and the associated URL.

Since the browser is only validating that the authenticated supplied digital certificate corresponds to the supplied URL (not by the client but by the webserver that hasn't been authenticate) ... SSL typical is now

the webserver that a client is interacting with ... is the webserver that the webserver claims to be

There is a huge difference between validating that the webserver is the webserver the client believes it to be vis-a-vis validating that the webserver is the webserver that it claims to be.

This is also at the root of phishing vulnerabiilties ... an email has verbage saying clicking on a button takes the client to a banking webserver ... the actual URL is for some webserver under control of an attacker ... who has applied for and obtained a valid domain name digital certificate for that webserver (proving that the webserver is the valid webserver for that URL).

The critical issue in the original SSL deployment was that the client knew & understood the relationship between the webserver they believed they were talking to and that webserver's (SSL validated) URL. That has become increasingly rare in the current environment.

Reply to
Anne & Lynn Wheeler

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.