VISA: All Your Password Are Belong to Us

[Enzo Michelangeli]

One last comment, if the moderator allows. While in my opinion sensibly
designed, the "Verified by Visa" protocol does suffer from one important
weakness: if no client plugins are used, an attacker can manage to spoof an
Issuer ACS and trick the buyer into revealing his/her password. This could
be avoided by implementing zero-knowledge authentication methods inside
standard browsers and HTTP servers: something that could greatly benefit web
security also for other applications. Now that SRP-3 exists and is
relatively unencumbered, it would be very nice if W3C and IETF considered it
for addition to HTTP. Maybe something for the Mozilla and Apache teams to
consider pioneering?

Enzo

----- Original Message -----
From: "Enzo Michelangeli" <em at who.net>
To: "Richard Guy Briggs" <rgb at conscoop.ottawa.on.ca>
Cc: <cryptography at wasabisystems.com>
Sent: Tuesday, 04 December, 2001 5:56 PM
Subject: Re: VISA: All Your Password Are Belong to Us


> ----- Original Message -----
> From: "Richard Guy Briggs" <rgb at conscoop.ottawa.on.ca>
> To: "Enzo Michelangeli" <em at em.no-ip.com>
> Cc: "Richard Guy Briggs" <rgb at conscoop.ottawa.on.ca>;
> <cryptography at wasabisystems.com>
> Sent: Tuesday, December 04, 2001 7:07 PM
> Subject: Re: VISA: All Your Password Are Belong to Us
>
>
> > On Tue, Dec 04, 2001 at 04:30:02PM +0800, Enzo Michelangeli wrote:
> > > ----- Original Message -----
> > > From: "Richard Guy Briggs" <rgb at conscoop.ottawa.on.ca>
> > > Sent: Tuesday, December 04, 2001 6:18 PM
> > >
> > > > So if I understand this correctly, if I am running a client, for
which
> > > > there is no plugin, I am screwed?  This seems pretty limiting.
> > >
> > > The plugin is a piece of software that runs on the merchant server,
not
> on
> > > the client (buyer's browser). Of course, this represents a pain in the
> neck
> > > for the merchants, as they'll have to buy and install such plugin...
> >
> > So what was the issue about it not working with Macintosh?  Why would
> > that matter?
>
> Perhaps there is also a client-side component to, e.g., cache the password
> in a sort of "wallet", or, in case of smartcard-based authentication,
> interface the Visa Smartcard. However, the protocol (formerly known as 3D
> Secure) should be able to work without any specialized client, because a
> password can be sent securely from a browser window to the Issuer ACS over
a
> simple HTTPS session. As I remember from last year, when I last examined
the
> protocol, one of the design goals was to keep unspecified the sub-protocol
> between Issuer ACS and buyer's machine, allowing for a variety of
> issuer-specific solutions.
>
> Remember the business relationship chain: Cardholder (i.e., buyer) <-->
> Issuer <--> VISA (or MC) <--> Acquirer <--> Merchant. Visa, a banking
> consortium, cannot (and doesn't wasnt to) deal with cardholders and
> merchants. Those should sort their issues with, respectively, issuers and
> acquirers. The purpose of "Verified by Visa" is precisely to let issuers
> authenticate their own cardholders, relieving merchants, acquirers and,
> (crucially!), Visa, from the burden of sorting out disputes deriving from
> misuse of someone else's card number. It's only natural that the issuer
> should be let free to choose the authentication method it prefers.
>
> Enzo
>
>
>
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
majordomo at wasabisystems.com




---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com