Verifying Verified By Visa - Registration breaks chain of trust - SSH

This is a discussion on Verifying Verified By Visa - Registration breaks chain of trust - SSH ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Verifying Verified By Visa - Registration breaks chain of trust

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

  2. Re: Verifying Verified By Visa - Registration breaks chain of trust

    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.

  3. Re: Verifying Verified By Visa - Registration breaks chain of trust


    "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



  4. Re: Verifying Verified By Visa - Registration breaks chain of trust

    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

  5. Re: Verifying Verified By Visa - Registration breaks chain of trust

    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

  6. Re: Verifying Verified By Visa - Registration breaks chain of trust


    "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

+ Reply to Thread