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" <[EMAIL PROTECTED]> To: "Richard Guy Briggs" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, 04 December, 2001 5:56 PM Subject: Re: VISA: All Your Password Are Belong to Us > ----- Original Message ----- > From: "Richard Guy Briggs" <[EMAIL PROTECTED]> > To: "Enzo Michelangeli" <[EMAIL PROTECTED]> > Cc: "Richard Guy Briggs" <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > > > 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 [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
