3D Secure Vulnerabilities?

[Jack A. Hudson]

I’ve read the merchant implementation guide for 3D secure.  Verified by Visa is definitely a step forward.  But, to me it seems overly merchant-oriented.  I mean, merchants are protected pretty well from fraudulent cardholders.  But the cardholder is only marginally safer as a result of this technology.  Or am I missing something?  Here are some of the reasons (questions) I feel that 3D secure still leaves the consumer vulnerable in internet transactions.   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