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
