3 ms·

I agree with your solution of an affirmative step. I can see internet credit/debit card transactions moving towards a "request for funds" model where the consu

I agree with your solution of an affirmative step. I can see internet credit/debit card transactions moving towards a "request for funds" model where the consumer(via smartphone) has to explicitly ok the transfer of funds: Merchant - (RFF) -> Bank - (prompts for auth) -> Consumer - (grants auth) -> Bank - (RFF granted) -> Merchant Of course, smartphones are still potentially insecure, another more cumbersome model could revolve around challenge-response codes - where the customer has an offline digital code card: [Merchant - (RFF) -> Bank - ($challenge) -> Merchant -($challenge) -> Consumer(punches in challenge code) - ($response) -> Merchant - ($challenge$response) -> Bank - (auth) -> Merchant

jfim 14y ago
You've just described ARQC EMV card payments.
- conorgdaly 14y ago
  After having a cursory glance through the ARQC EMV wiki entry, it seems that EMV corresponds to what we currently have in Europe -> the same (consumer) PIN is still going to be re-entered in every transaction i.e. it's re-useable and can be easily captured(camera/eyeball) for later use at POS/ATM
  - jfim 14y ago
    Correct, it also describes your first flow; the only thing different is that the authentication is done through the merchant's PIN pad rather than a code sent through the cell network. In other words, providing the PIN unlocks the card, which serves as your authorization to dispense funds. IIRC the card signs the merchant's request for funds once the PIN has been validated by the chip on the card, then sends it to the bank. I don't think there's anything in the standard that would preclude having one time PIN codes(the PIN validation is done by the chip, so you could just have a different app that does more than check a single PIN code), but the chip in the card itself doesn't have network access. If you really wanted to have online authorization through the cell network, you could hold the processing of the AQRC message until it is verified through SMS (which can take several minutes for delivery and is best effort). However, that would hold the card reader unusable until the authorization is granted, as the card needs to stay in the terminal until the transaction is complete. This obviously disregards offline processing (ie. card terminals that are not always connected to the network) and CNP transactions. For those, verification through another channel would be much more realistic.
sjmulder 14y ago
The system that I think you are describing is already out there. I can’t speak for other countries but here in the Netherlands, the banks have standardised on “iDEAL”. When you’re on a website and want to make a payment, the site makes a request to the bank, which then presents you with whatever method of authentication your bank uses. Generally this is some two-factor system. After giving the OK, you’re redirect back to the merchant. Actually, it would seem to me that PayPal is very similar.

jfim 14y ago

You've just described ARQC EMV card payments.

conorgdaly 14y ago
After having a cursory glance through the ARQC EMV wiki entry, it seems that EMV corresponds to what we currently have in Europe -> the same (consumer) PIN is still going to be re-entered in every transaction i.e. it's re-useable and can be easily captured(camera/eyeball) for later use at POS/ATM
- jfim 14y ago
  Correct, it also describes your first flow; the only thing different is that the authentication is done through the merchant's PIN pad rather than a code sent through the cell network. In other words, providing the PIN unlocks the card, which serves as your authorization to dispense funds. IIRC the card signs the merchant's request for funds once the PIN has been validated by the chip on the card, then sends it to the bank. I don't think there's anything in the standard that would preclude having one time PIN codes(the PIN validation is done by the chip, so you could just have a different app that does more than check a single PIN code), but the chip in the card itself doesn't have network access. If you really wanted to have online authorization through the cell network, you could hold the processing of the AQRC message until it is verified through SMS (which can take several minutes for delivery and is best effort). However, that would hold the card reader unusable until the authorization is granted, as the card needs to stay in the terminal until the transaction is complete. This obviously disregards offline processing (ie. card terminals that are not always connected to the network) and CNP transactions. For those, verification through another channel would be much more realistic.

sjmulder 14y ago

The system that I think you are describing is already out there. I can’t speak for other countries but here in the Netherlands, the banks have standardised on “iDEAL”. When you’re on a website and want to make a payment, the site makes a request to the bank, which then presents you with whatever method of authentication your bank uses. Generally this is some two-factor system. After giving the OK, you’re redirect back to the merchant. Actually, it would seem to me that PayPal is very similar.