I think its important to make a distinction between two different scenarios where authentication is required:
- app challenge (e.g. when requiring touch ID to open the app)
- server challenge - when requiring authentication to perform an action on the server e.g. sending a peer to peer payment
For the first, the authentication must be done locally with the device otherwise you won’t be able to access the app offline. This type of authentication is somewhat superficial, it only mitigates the risk of someone who has access to your unlocked phone from accessing the Mondo app and reading your transactions (moving money requires additional authentication anyway). Whilst I personally wouldn’t give my unlocked phone to someone that I didn’t trust, I understand why some people are motivated to. Within this context, touch ID works very well and we can fallback to the iphone passcode when touch ID fails for some reason.
For the second, touch ID also works well (you can use it to unlock a secure token which is then used to authenticate with the server). A second method is required to bootstrap the token on first use and to fallback to when touch ID fails. Using the card pin as this second fallback has pros and cons. On the one hand, there isn’t any cognitive overhead for the user (when compared with an additional pin/password). On the other hand, it will make the user more susceptible to sophisticated phishing attacks that target their pin number.
I think this is an acceptable trade off and this is why:
The card pin cannot be used to create a card transaction without physical access to the card. The type of malicious actor that carries out phishing attacks (targets lots of people and hopes for a few victims) is very different from the one that can steal your card. For an attacker that wishes to steal a card there are numerous ways they can additionally obtain the pin:
- threaten the victim at an ATM
- watch you at a store if you don’t fully cover the pin keypad
- use a thermal camera to tell which keys you pressed
It all boils down to security economics. There is an attack vector (phishing pin + stealing card) and the two components (in isolation) are fairly easy to for an attacker to do. However, the combination is much harder and it is much easier for them to commit fraud with the card in other ways.
Whilst I don’t (yet) have an exhaustive knowledge of PCI, I do have reasonably comprehensive knowledge and I’m not aware of any PCI rule that restricts us from allowing a user to enter their pin within the app which is then sent securely to our server.
Let me know if you have any questions