Verifying Verified By Visa - Registration breaks chain of trust

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?

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.

es:

Remind the bank that Consumer Credit Act limits your liability to the first £50 of unathorised transactions on credit cards and in some cases on debit cards as well.

Indeed - however the problem is that the bank may argue that VbV is secure which means that only you could have authorised the transaction (like they often do with ATM withdrawals).

Ironically, if you did have a large disputed CC transaction it may be better to tell the bank you were careless with your password ;-)

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.

In the better cases, these lead to an https URL in the well known domain for that bank. In the case I know of where this is not true, one can still check the subject of the SSL certificate for the secure domain and confirm that it was issued to that bank.

The domain name doesn't match Visa or the bank's well known domain name. Alarm. The domain name (something like securesite.co.uk) is pretentious. Alarm (pretentious names are used by the more dodgy internet traders. SSL certificate subject is neither the bank nor Visa. Alarm. SSL certificate subject is a US corporation. Alarm (off shore companies trading under UK domain names are also an indication of a possible dodgy internet trader, and one of the typical bits of internet buying advice is to check for a UK address, which all UK business sites are required to include, although many still don't).

Note. A similar problem arises with many e-commerce sites which use an unknown service (their ISP?) for credit card processing, but the main risk there tends to be that authentication doesn't guarantee the company is trustworthy.[C]

Yes. Most, if not all, of the security related[B] reasons why one would want to buy an SSL certificate rather than using a self signed one.

As I understand it, in terms of actual hacker activity, DNS poisoning is the most likely attack, but anywhere outside of the client PC is vulnerable to attack. I could be wrong, but I suspect the insecure, marketing, web sites of banks are not as highly secured as their secure operational systems.

Incidentally, subject to finding out how it actually works, I have concerns that the transaction verification stage of VbV is trivially vulnerable to man in the middle attacks, unless, possibly, one uses SSL, rather than the VbV methods to authenticate the VbV server. Does that certificate also point to someone other than Visa?

What could have been done, for registration, in roughly decreasing order of desirability is:

- Use the chip and PIN calculators, that the banks have been dishing out, in sign mode - this may avoid the need to register entirely.

- Don't outsource the process.

- Only outsource it as as far as Visa.

- Supply the VbV contractor with a subdomain of the bank's domain, on which to run a virtual server for the bank, and give them the corresponding SSL certificate; or the same, but at the Visa level.

- Put the final link to the contractor's secure site on an https site in the bank or Visa's domain name space.

- Supply them with an SSL certificate for a subdomain of their domain, which should be a .com domain representing their business name, so that people are not misled about the location to where they are sending data.

- Make prominent announcements in non-internet media telling people the domain name to check for when they register, and what the subject of its SSL certificate will be.

- Supply that information on demand when requested by people who care about security.

Note A. I wanted this to have some exposure on a newsgroup frequented by people who understand intenet security, but made some poor choices of newsgroup. I was thinking SSL when I used the SSH group, and the uk one seems to be weird, with encrpted messages. Hopefully comp.security.misc will be better, although it is rather broad.

Note B. The non-security reason for buying a certificate is to stop a browser nag, but whilst some have argued that the whole certificate sale thing is a con, there is some value in a certificate here.

You do not need a browser root certificate signature for encryption and I believe that SSL can create anonymous certificates for key exchange, and even do without them, although I don't know to what extent browsers and servers support this.

Note C. Actually, outsourcing the credit card processing may be better than having ones own certificate, but only if one uses a well known service, like WorldPay or PayPal. Even then, it would be advisable to indicate that service prominently on the web site and promotional material - I note that people are beginning to do that on the web sites.

The reason that reputable outsourcing is desirable, is that one doesn't need to trust a relatively unknown company with the credit card details.

The problem is that even to sort it within the bank you have got to get past the support drone, their supervisor, marketing promotions side, and reach someone on the technical side that understands trust in secure systems. The full chain is worse. It probably starts with the development side of Visa marketing, then goes to their technical people (or more likely it is outsourced, introducing another level of first line support). Starting back from the technical people you then have: (outsourced first line support), Visa marketing (development), Visa marketing (promotion), bank marketing (promotion), support management, and finally support drone. Of these only the technical people may really understand.

When one introduces scripting, as well as making it more difficult for the customer to verify, you probably introduce a script programmer, who probably doesn't understand security.

I've pruned the crossposts, as the originals were poorly chosen.

we were 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 didn't exist at the time). misc. past posts mentioning payment gateway for electronic commerce

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 the 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 that 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

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 that the client knew & understood the relationship between the webserver they believe they were talking to and that webserver's (SSL validated) URL. That has become increasingly rare in the current environment.

Which is the whole problem with the VbV registration process. The average user doesn't look at the domain name and wonder why it has changed, but simply believes that all must be well because the connection is encrypted, even though they were sent there from a site that was unprotected.

Which is why banks should be encouraging people to challenge any unexpected domain name, rather than making unannounced domain name switches themselves (but they also use other bad practices, like using scripting)

This is particularly bad for VbV as VbV is about authentication.

re:

Verifying Verified By Visa -Registration breaks chain of trust an email phishing countermeasure has been if the area to be clicked on (i.e. between the ">" after the href URL and the "") looks to be a URL ... then the email client checks if the purported claimed URL matches the actual URL in the href. A simple work-around/countermeasure (by the attackers) is to not display anything that resembles a URL ... so there is nothing to match on.

However, i've seen cases (for at least some email clients) ... where they take the hostname from what appears to be a displayed URL ... and do a string compare against the hostname in the actual href URL ... and it is treated as valid, even if the attackers are using a much longer hostname (that just has a prefix part that matches the hostname part of what is displayed).

the URL may or may not be a HTTPS/SSL connection. However, even if it is a SSL connection ... all the attackers need to have done is to obtain a SSL digital certificate proving that the actual provided URL (in the HREF, not what is displayed) is a valid URL.

Mutual authentication is much older than SSL (SSL doesn't really contain anything new, it just popularised techniques). For example, PPP, for dialup connections, supports it, even though Dial Up Networking, Microsoft's implementation of it, doesn't. PPP is also new compared to the concept. (Mutual authentication is used in spy stories, done verbally, and is used by military sentries. The clickers used on D-Day were a form of mutual authentication.)

Note that the libraries don't need digital certificates. There are ways of negotiating session keys that don't use them at all. It is really the browsers and servers that impose that limitation.

What you haven't said, but must be the case, is that, if they don't have public keys, they must have shared secrets. preferably a bit stronger than the last transaction number, and information that is secure by obscurity.

That's generally the case for the targets of phishing attacks. It is also the case for major brands, like Amazon, but a lot of transaction start from a Google search, and then the correct retailer name, or even whether the retailer really exists at all, is unknown.

(I am disappointed, though, that one of my banks uses a non-obvious domain name for their secure server, which forced me to read the SSL subject the first time I used it.)

That doesn't actually matter as long as one re-checks the domain name on the transition to a secure connection. The problem is that e-tailers have been telling everyone that SSL is only about encryption, so they are not educated to make this check, and sometimes vanity issues result in significant obfuscation (e.g. using frames, or turning off chrome).

It is also important that significant information about the transaction is reconfirmed in the authenticated part of the transaction - in particular transaction value (as a limit on risk) and delivery address, although the details of the order are also a good idea.

The main conflict here is between "web designers" and the browser. Web designers may want the ability to hide this subcontracting and browsers tend to go along with this, but browsers could be made to force the URL for an authenticated connection onto the user. I do though, note a trend towards positively identifying the payment gateway, where it is a major brand, probably because it increases consumer trust, and because consumers are becoming aware of this "disconnect".

As I noted in my footnote, where the e-tailer is an unknown, but the payment gateway is well known, knowing that one is talking to the gateway can actually be more comforting for the customer than knowing one is talking to the e-tailor domain name one is talking to, especially if the gateway identifies the e-tailer it is serving.

The problem I have found is when an e-tailer that I marginally trust hands off to their ISP's payment gateway, or a minor league gateway, because they can't afford to buy a certificate for themselves or to use one of the well known payment services. This may be becoming less frequent, because of the increasing availability of well known payment services, although it can still be difficult keeping track of all the services.

And one of the problems here is that many e-tailers seemed to be unaware of the authentication concept, and SSL was sold to the general public purely on the basis of encryption, which, as you point out, doesn't need certificates.

>

Note that, because the internet is vulnerable to man in the middle attacks, you cannot safely negotiate session keys without simultaneously authenticating, even though I believe the SSL libraries allow this. That authentication can be done with symmetric keys, and in the extreme case, authentication can simply be the result of using the master key without negotiating a session key.

David Woolley writes:

re:

Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust I didn't say they didn't have public keys ... i claimed that the digital certificates were redundant and superfluous.

for some topic drift ... the original public key draft for Kerberos was certificate-less ... with digital certificate specification added later (kerberos is a widely used authentication infrastructure available on mainly platforms, including windows)

there have also been certificateless public key implementations dones for RADIUS ... a widely used authentication mechanism used by ISPs and corporate intranets ... frequently the mechanisms found at the server end of PPP connections misc. posts mentioning public key & digital signature authentication w/o requiring digital certificates in the certification authority model ... a public key is generated and a certification authority does some validating about the entity associated with the public key and other information associated with the entity. it then issues a digital signed digital certificate (including the entity's public key and the associated information).

this is part of the process that we long ago and far away audited ... when the organizations calling themselves certification authorities were new & young.

however, for this to work ... a browser (or other application) has a built-in table of public keys (belonging to certification authorities) that are used to validate/authenticate the (certification authorties) digital signature on the digital certificate ... as the step where the browser/application "validates the digital certificate (before trusting/making use of the public key included in the digital certificate).

so the payment gateway provides its public key directly to the webservers as part of all the other stuff that the payment gateway provides to the webserver for correct operation. each webserver provides their public key to the entity operating the payment gateway (as part of a whole lot of other information that they need to provide). the exchanged public keys are kept in tables in much the same way that browsers keeps a table of (trusted) certification authority public keys.

involving an independent (redundant and superfluous) 3rd party certification authority in the process, is redundant and superfluous and the digital certificates that they issue are then also redundant and superfluous.

the digital certficate scenario is the electronic analogy to letters of credit/introduction from the sailing ship days when the relying party had first time encounter with complete stranger and had no other recourse to information about the stranger they were dealing with.

the digital certificate design point is the offline email paradigm from the early 80s; the electronic postoffice is dialed, email exhanged, connection is broken ... and there is first-time communcation between a complete stranger. In the absence of any other mechanism for information about the stranger, a digital certificate can be better than nothing.

after having realized that digital certificates were redundant and superfluous in situations where the parties already have information about each other and/or have online access to information about each other ... which was part of setting up payment gateway for electronic commerce

we were brought in to the x9a10 financial standard working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail transactions ... which resulted in the x9.59 financial standard some of the other financial transactions efforts going on in that period (that also involved public key) ... were heavily steeped in digital certificates. a serious roadblock for them was that the digital certificate paradigm increased the typical payment transaction size by a factor of 100 times as well as increasing the processing overhead by a factor of 100 times. misc. past posts mentioning the enormous bloat that (redundant and superfluous) digital certificates represented for payment transactions the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrasturcture for *ALL* retail transactions ... and so we had a lot of payload size, transaction processing overhead and protocol chatter constraints that other efforts simply ignored.

for other topic drift ... recent posts in crypto mailing list regarding certificateless public key in the DNSSEC scenario and a hypothetical superfast SSL "lite"

The PKC-only application securitymodel The PKC-only application securitymodel The PKC-only application securitymodel The PKC-only application securitymodel

re:

Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust Authentication in the e-tailer /payment gateway / customer triangle for other topic drift, lots of past posts discussing man-in-the-middle attacks one of the scenarios about certificate-less operation is that the table of trusted (certification authorities) public keys preloaded in browsers and PGP tables of trusted public keys are effectively the same mechanism ... they are directly *trusted* public keys.

certification authorities and digital certificates provide a mechanism for indirect trust (ala letters of credit/introduction model from sailing ship days) when there is no other source for the information.

for other topic drift ... part of recent thread in crypto mailing list and(uk) financial crypto blog about historical pgp (and certificateless public key)

Own a piece of the crypto wars Historical copy of PGP 5.0i for sale-- reminder of the war we lost there is archeological reference to old email from '81 for a (certificateless) pgp-like implementation ... approx. decade before pgp.

there is overlap in this area between x9.59 financial transaction standard (usable with certificate-less public key) ... references

and the EU FINREAD standard ... misc. past posts discussing issues and objectives of the EU FINREAD standard ... i.e. how do you know that the transaction being digitally signed is really the transaction that you think it is.

Agreed. And, in fact, in the case of businesses with a significant non-web presence (like banks and Visa!) it would be quite possible for them to publish their key fingerprint on their printed literature and letterheads (although the concept might be too technical for the marketing people) and the full key on the web. Visa could even put a key fingerprint on every Visa card!

However, when you have an American subcontractor pretending to be a UK web site, you are not going to know how to find the key fingerprint.

Incidentally, as I'm sure you know, in the sort of extranet environment that you describe, you can create a self signed certificate, and install it in the browser, so that the browser now trusts you as though it had a certificate from, say, Verisign. Microsoft even provide tools for making these, although they claim they are only for testing.

Further topic drift: there are other flaws in the certificate system in that, by default, browsers come with all certificates enabled, but some represent higher levels of verification than others. As the level of trust for some interactions may differ from that for others, one would really need to check the issuer on every access needing more than minimal authentication. That's mainly dumbing down, but it has been suggested that you can basically buy the right to have a root certificate in a browser. I think very few browser users realise that not all certificates are alike.

there have been several discussions over the past decade on the vulnerabiilty of the infrastructure when all certification authorities are treated the same. simplest scenario is that if the probability of any particular certification authority is X/year and there are 100 loaded certification authority public keys ... then a compromise of any specific one (compromising the whole infrastructure) is 100*x/year.

One issue raised is what happens if a certification authority goes out of business, what is the assurance of the associated private keys.

as discussed in this scenario

The PKC-only application securitymodel The PKC-only application securitymodel The PKC-only application securitymodel The PKC-only application securitymodel

mentioned in earlier post

Authentication in the e-tailer /payment gateway / customer triangle is the ssl domain name certification authority catch-22 Basically, some number of the SSL domain name certification authorities were supporting DNSSEC operation ... for a couple of reasons.

1) the original SSL domain name digital certificates were, in part, justified based on perceived weaknesses in the domain name infrastructure. However, the SSL domain name certification authorities rely on the integrity of the domain name infrastructure as to the "true" owner of a domain (when validating requests for SSL domain name digital certificates). Part of the DNSSEC scenario would include having domain name applicants to register a public key as part of registering a domain name. Then future communication would be digitally signed (authenticated with the on-file public key), minimizing vulnerabilities like domain name hijacking. This improves the trust that certification authority can correctly identify the true owner of a domain .... and validating that the true owner is applying for an SSL domain name digital certificate i.e. a fundamental basic trust issue for ssl domain name digital certificate resides in whether the domain name infrastructure correctly maintains the true owner of the domain name. 2) the current SSL domain name digital certificate process requires the certification authority to perform the expensive, time-consuming, and error-prone process of verifying that the digital certificate applicant is the same as the owner on-file with the domain name infrastructure. With an on-file public key, the certification authorities, can require that SSL digital certificate applications be digitally signed. They then could do a real-time retrieval of the on-file public key and turn an error-prone, time-consuming, and expensive verification process into a much simpler, less-expensive and reliable authentication process.

this creates the catch-22, since if the certification authorities can do real-time retrieval of on-file public key ... then it is possible that the rest of the world could also.

the scenario is that a standard DNS host->ip-address lookup would optionally piggy-back a (on-file) public key (and potentially other crypto negotiation options) in the responseresponse. Then an extremely lightweight SSL ... has the client generating the random secret key, encoding it with the server's public key and encrypting the initial communication ... from the start (bypassing all the SSL protocol setup chatter).

For additional topic drift ... in the 80s ... we had been involved in both the NSFNET backbone activity ... some old email

and various posts and we were also on the XTP technical advisory board ... which was looking at a highly efficient reliable protocol ... that would support both efficient reliable transaction operation (minimum packet exchange of 3 packets ... compared to minimum packet exchange of 7 packets for TCP) as well as multicast and some number of other features. There was also an attempt to get (ASC) X3S3.3 (us chartered organization for standards involving the area around level 3 & level 4 in the OSI networking model) ... misc. past posts So in XTP terms (having access to the server's public key, either cached from some previous interaction and/or piggy-backed on recent name->ip-address response), a full transaction SSL-lite could be done in the 3-packet minimum exchange ... prefixing the first packet with the public key encoded random secret (session/transaction) key with an appended encrypted transaction.

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.

"Andy Pandy" writes:

same thread in comp.security.misc

Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust Verifying Verified By Visa -Registration breaks chain of trust Authentication in the e-tailer /payment gateway / customer triangle Authentication in the e-tailer /payment gateway / customer triangle 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 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

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.