3 ms·

> 2. (As mentioned in the article) issuers accept transactions from EMV (chip)-capable readers that nominally originate from EMV-capable cards without requiring

> 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.

amluto 4y ago
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.)
- lxgr 4y ago
  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.
  - amluto 4y ago
    > 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.
    - lxgr 4y ago
      And that is exactly what happens :)
- techsupporter 4y ago
  > 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.

amluto 4y ago

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.)

lxgr 4y ago
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.
- amluto 4y ago
  > 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.
  - lxgr 4y ago
    And that is exactly what happens :)
techsupporter 4y ago
> 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.