Hacker News Reader

Comment by Scoundreller | Hacker News Reader

> 2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring the chip to be used. So what’s the point of the chip? (Note that this allows a card to be cloned without even touching the card - see #1.)

I would think the issuer could refuse the transaction higher up in the process, but it's faster and fewer packets going back and forth if the POS terminal could reject the swipe up-front and tell you to insert the chip.

View on HN

That’s like saying you think a server can reject a wrong password on the backend, but it’s faster and fewer packets going back and forth if the client JavaScript just verified the password before sending POST. This is nuts. At least there’s nothing fundamentally wrong with a card reader also rejecting the transaction.

(It’s also not fewer packets. Although it does require the backend to know whether the card reader can read a chip, and I don’t know whether the reader reports this as part of the transaction. OTOH there are rather severe penalties assessed on merchants with non-chip-capable readers, so something up the stack has at least some idea.)

A better comparison would be the client JavaScript rejecting a four-character password, because it knows the backend policy requires at least eight.

Done right (without e.g. checking for "key down" events to thwart password managers...), this could could actually improve security somehwat by avoiding whatever the user entered (maybe a low-entropy PIN?) hitting the network or backend, besides providing for a faster error response and thereby nicer UX.

> It’s also not fewer packets

It avoids an entire round trip to the issuer's backend and back, which are often still somewhat expensive and slow, given the legacy systems and connections involved.

> It avoids an entire round trip to the issuer's backend and back, which are often still somewhat expensive and slow, given the legacy systems and connections involved.

Not if done both client-side and server-side.

Right now, if I swipe my magnetic stripe, then terminal will reject it if the stripe has the magic bit set. If the magic bit is clear, the terminal will (eventually, but usually while the customer waits) send a message to the network saying that the card was present and asking for authorization. The network responds. No additional round trip would be needed for the network to deny authorization if the chip was not used.

And that is exactly what happens :)

> That’s like saying you think a server can reject a wrong password on the backend, but it’s faster and fewer packets going back and forth if the client JavaScript just verified the password before sending POST. This is nuts.

I don't think it is nuts. The terminal doing the rejection accounts for the "oops the customer did something wrong" case of swiping the card when the issuer wants them to use chip. It's better to tell the customer this now than run an entire transaction.

But checking on the far end that the transaction meets all of the issuers rule accounts for the fraud case of "someone has maliciously rewritten the magnetic stripe data to try to go around the requirement to insert the card." Since, hopefully, this happens far less often than the first case, it is an acceptable path.

Reply on news.ycombinator.com