> Regarding #4: The digital signature makes the transaction tamperproof.
But, the transaction is sent twice: once for display in the password
dialog and again for authorization. A digital signature guarantees
integrity through one data transit. But it doesn't guarantee
equivalence of two separate transmissions sent to two separate servers.
For example, the merchant sends transaction information to issuer for
display in password dialog. Digital signature guarantees issuer
receives untampered transaction data. After authentication, merchant
sends transaction to acquirer. Digital signature guarantees acquirer
receives untampered transaction data. But, the digital signatures don't
ensure the issuer and acquire got the same data. Right?
> 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.
Merchants are not given the password, agreed. But can they intercept it
through clever hacking?
>
> 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.
What do you mean by "bank customer's existing security solution"? Like
what?
>
> 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
Sorry, don't follow. Scrapped what part? And what do you mean by
"creditcard numbers a problem". What problem does using a credit card
number cause in VbV?
> 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".
>
>
> 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
>
>
