Thanks for the whitepaper. Very helpful. This whitepaper included information about SPA and Maestro that I've not found anywhere else. Know of any more information on SPA/Maestro?
Step 9 of the Maestro process is: "Issuer performs transaction matching in the wallet server" The transaction matching allows the consumer to stop the issuer from charging more than the cardholder authorized. Does VbV or SPA have anything comparable to this feature - matching preauthorized transaction to authorized transaction? Jack > -----Original Message----- > From: Bahram Boutorabi [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 25, 2001 3:49 AM > To: Anders Rundgren; Jack A. Hudson > Subject: RE: 3D Secure Vulnerabilities? > > Hi guys, > > I have attached a white paper that describes 3D Secure as well as SPA. > It also recognises the Man-in-the-middle attack. > > I thought it might be of some use to you. > > Regards > > Bahram > > -----Original Message----- > From: Anders Rundgren [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 25 October 2001 5:10 PM > To: Jack A. Hudson; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: 3D Secure Vulnerabilities? > > > Jack, > Some of your concerns are indeed valid. Being a European I can inform you > that few > EU banks rely on passwords only. One-time PIN-codes, SecureID (and > similar), and > digital certificates is the norm. > > Passwords are AFAIK not to be given to merchants at all. Only to > rogue implementation. > > Now I don't have the latest spec. but if 3D Secure does not utilize the > bank > customer's > existing security solution it is broken and flawed. > > Regarding creditcard numbers I agree that it is a problem but I thought > the > idea > was to use "proxy" such. Actually 3D Secure should have scrapped that > part and the directory. Doing that, a user would have to enter their > bank's > 3D Secure > URL. The VISA directory is just a [redundant] part of the "power game". > > Regarding #4: The digital signature makes the transaction tamperproof. > > Anders Rundgren > > ------------------------------------ > 1) The merchant pops up a daughter window for password collection > on behalf of the issuing bank. How can the cardholder be sure the > merchant > isn't just popping up a look-alike window to collect and keep their > password? > > 2) The user enters their password in this dialog and the issuer > checks > it. But how is the password checked for correctness? > It is just blasted over to the issuing bank for validation? If so, that > seems to raise other security concerns (i.e. couldn't a > false-merchant intercept the transmission of the password?) Or does 3D > secure use the password as a "secret key" to avoid this > problem, since doing so removes the need to transmit the password over the > Internet? > > 3) Because the cardholder enters a password, they may feel > comfortable > that their card is safe with that merchant. But, even > if the merchant implements VbV and prompts for a password, once the credit > card number is stored in their database, it is just as > vulnerable to theft as a non-VbV enrolled card. A VbV card can be stolen > and used at any merchant that doesn't prompt for the > password. Merchants are right to feel protected by VbV. But why should > consumers feel protected when they see the password prompt? > > 4) Let's say the cardholder enters their password correctly and the > merchant proceeds to submit the transaction. What (aside > from eventual human detection) prevents them from submitting a higher > amount > than the cardholder authorized at the password prompt? > For example, the password prompt shows transaction details of 14.95. But > when the transaction is sent to the acquirer for > authorization, what prevents the amount from increasing to, say 149.55 > (which the merchant could claim as accidental)? > > 5) The merchant implementation guide says, if the password is > entered > wrongly, the merchant cannot submit the charge. But, > what is to prevent them? They could submit the charge as a card-not- > present > transaction (i.e. without the CAVV), and reassume > liability if a chargeback results. > > Thanks > >
