tracking logins

M

Martin Gregorie

It seems to me though the user should not have to rekey the challenge
phrase. Surely the credit card company must identify itself to the card
for a challenge to even be accepted.
I don't see how you can avoid re-keying the challenge and still guarantee
that the smartcard isn't accessible by trojans, etc.

The authentication page is published by the card issuer from their own
website using SSL and read by them, so the URL on the browser should
match the heading on the page and the SSL flag should be displayed. Its
hard to see how you can do better than that.

There's message separation involved: the vendor only knows your name,
address (for goods dispatch) and the card number, which he sends to the
card issuer. If these match the card issuer's database then control
switches to the card issuer.

The card issuer uses this detail to find the challenge seed in his
database and sends you a page containing the card number and your name
for confirmation together with the challenge. He also calculates a one-
time response and stores it in your account record. You only send the
response code from your card reader to the issuer, who compares it with
their expected response. If it matches the vendor gets an ACCEPTED
response and the issuer debits your account and credits the vendor.

The only field on this screen that accepts your input is the response box.

So, the message flow is:

Message Content
you->vendor your card number, name and address
vendor->CI your card number, name (and address?)
CI->you card number, name, challenge code
you->CI response code
CI->vendor ACCEPT or DECLINE
vendor->you transaction accepted or refused

which gives good separation: no message contains all the details that
would be needed to complete the transaction and the additional details
used in card-present or phone transactions (expiry date, security code)
are never part of any message.

Looked at it this way, its hard to see how a fake CI website, key logging
or sniffing the traffic can benefit a fraudster: the most they can get by
sniffing your traffic is card number, name, address and a one-time
challenge code. OK, and a one-time response code

I can't prove this, but I think the card reader just powers the card,
passes the challenge into it and displays the response when its returned
by the card. That way the card reader is kept simple and never stored
anything: it purely acts as a terminal for the smartcard.

BTW, I've head of, but not yet seen, another smartcard design that builds
the keypad and display into the card rather than requiring a reader, but
I have no idea what it uses for batteries or how they get charged: that
wasn't mentioned. All I'd say is that getting all that into a card that
still goes into an ATM is a pretty neat trick.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

New JDK out 1
Cookies 2
Dir scan 1

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top