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.

David Woolley wrote:
> The UK banks are encouraging us to join Verified by Visa (and the

Sorry. That wasn't really on topic. I was trying to cross into a group
with people who understood how web security works, and I sort of misread
SSH as SSL.

"David Woolley" wrote in message
news:4892277e$0$620$5a6aecb4@news.aaisp.net.uk...
> 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.

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

On Thu, 31 Jul 2008, David Woolley wrote:

> 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.

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.

--
Chris

On Thu, 31 Jul 2008 22:00:14 +0100, David Woolley
wrote:

>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.


When you ring up because it won't let you register they'll tell you
it's because it doesn't work in your choice of browser, that it's a
known issue and that it's tough.

The system sucks imo. iframes hidden and redirecting to god knows
where doesn't inspire confidence.

If shops only sold and delivered to the address on the card then it'd
solve a lot of problems.
--
http://www.freedeliveryuk.co.uk
http://www.holidayunder100.co.uk

"Andy Pandy" writes:
> 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?

same thread in comp.security.misc
http://www.garlic.com/~lynn/2008l.html#28 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#29 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#30 Verifying Verified By Visa - Registration breaks chain of trust
http://www.garlic.com/~lynn/2008l.html#31 Authentication in the e-tailer / payment gateway / customer triangle
http://www.garlic.com/~lynn/2008l.html#32 Authentication in the e-tailer / payment gateway / customer triangle
http://www.garlic.com/~lynn/2008l.html#33 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
http://www.garlic.com/~lynn/subnetwork.html#gateway

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
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

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.

--
40+yrs virtualization experience (since Jan68), online at home since Mar70