My iPhone supports Touch ID however it’s broken and I have found with numerous apps that allow Touch ID this is a nuisance since I’m now locked out of them.
Such as YikYak.
So instead maybe a pass code to go along with the Touch ID?
(Apologises if this is already done because I haven’t enabled Touch ID due to it being pointless for my phone at this moment)
What do you mean its broken? Is it broken physically?
You can always turn off Touch ID if it doesn’t work, then the apps would have to find some other way to authenticate you (but you won’t be locked out). :mondo: doesn’t have a passcode lock at the moment though.
Yes, broken physically and with it turned off the apps won’t find another way, they still ask for it. For example, YikYak has no alternative option to switch it off in app either so the only way to switch it off is in the main settings of the phone however that only turns it off for the lock screen and app store purchases.
Just wanted a head up to Mondo with this flaw so they can put an alternative in.
Same here, Touch ID seemed to crash the app, had to reset via iOS settings to access app again 
I’m surprised they don’t use a passcode too. I’ve seen some apps (e.g. OneDrive) that offer both so you can use a passcode if you choose not to use Touch ID.
Yes, we want to use the card’s PIN as a fallback, so if you fail TouchID you could log in with your PIN. In order to release soon we couldn’t include it yet, but it’s totally an option, specially if we see many people with this kind of problem (broken Touch ID, etc.).
Thanks a lot for the feedback 
Please do! That’d be a crucial failsafe option in case Touch ID has issues (maybe not necessarily broken, but failing to recognise my greasy/sweaty thumbs 
)
Thanks! 
Please do not do this. It is not an appropriate use of a card PIN, and it does violate PCI rules which you will be required to follow once you are a real bank. (Technically you should be following them now, but that’s up to Wirecard to enforce)
Thanks @billinghamj I must say that, as a user, I find totally appropriate to use the same PIN for both concepts.
So regarding your comment about the PCI rules maybe this is one of those where we let you define your own “passcode” knowing that the majority of people will use the same that the PIN just because it’s what makes sense (instead of remembering yet another number). While keeping happy that people that might be really worried about someone spotting their PIN when they type it in the app and then stealing their wallet, etc.
From the user perspective - I do totally agree. It’s just an issue of balancing that against the very real risk of phishing and encouraging unsafe behavior.
Allowing a user-defined PIN with the knowledge that many people will just set it to be the same as their card is absolutely fine - it’s not your fault if they do decide to go with that. With regards to explicitly condoning it - issuers of cards can’t really be seen to go around violating the PCI rules in a direct manner.
I imagine the PCI rules on this are less about actually protecting the PIN in the case where you’re entering it, but more about training consumers as to where it/isn’t safe to enter a PIN.
Fair enough.
Keep in mind though that with Mondo you get an instant notification if someone actually steals your card and PIN, and you can freeze the card instantly (you don’t usually get that with legacy banks).
Plus, the PIN would only be the fallback when other systems fail so you wouldn’t be so likely to expose it when you use the app out and about.
But yeah, don’t worry, we won’t do anything illegal, luckily we have people much smarter than me taking the important decisions
From someone who doesn’t know PCI but does know general security, it seems a bit wrong to have your phone know your card PIN for app unlock. That would mean having some form of the PIN locally and with four numbers, that’s trivially easy to offline brute force and there’s no hardware backoff timer or protection like there is on the card or the iPhone’s own SEP for device and data protection.
If it requires a server connection to unlock with PIN (so you could enforce various measures), that’s potentially quite slow and means you have to pull network status messages above the lock status and potentially just lock out people who are in regions of poor connectivity.
To defeat all of this and the Touch ID unlock, you could just log out and log back in via. email anyway with access to somebody’s device. I’d love to know exactly what the whole threat model and requirements for this is supposed to be because I can’t quite work it out. 
Again, you are assuming that someone stole your phone and card and manage to brute force the device before you had the time to contact us for us to block the card.
As a user that’s a risk that I’m happy to take. In other words, I don’t see any difference of me typing my PIN on a dodgy restaurant where maybe the owner has manipulated the payment machine to clone my card and number… yes, it can technically happen but I don’t care about it because otherwise I would be paying with cash everywhere
Maybe @daniel wants to chip in here? I’m just giving my two cents on how, as Hugo the user, I see this stuff from a non-tech perspective 
Then, with all due respect, what is being defended against, secured or protected?
I’m personally not too happy placing that much trust in the user to be able to block their card if they’ve had their phone stolen in the field too. It places the burden of security too heavily on the user for something that the app stored. I’m also concerned that the PIN information could be scraped in other ways, especially on Android where system level security and isolation can not be trusted as heavily.
I provoke and question all of this because I genuinely do care about the app currently known as Mondo being as effortlessly secure as possible but I’m always looking out for how something can be broken, either targeted or at scale.
I think its important to make a distinction between two different scenarios where authentication is required:
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:
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
Hi Daniel,
I do agree with pretty much everything you’ve said in principle. I do still think the phishing thing is problematic, but not necessarily a deal-breaker. You could just bootstrap the token when the user does a full login authentication though - then save it protected by their phone. It would then be available continuously until logout or Touch ID failure.
In terms of specific PCI rules though. Rules for “pin entry devices” (PEDs) are pretty clear:
Effectively, the requirement is that the touch inputs are encrypted before being sent to the device OS. As far as I can tell, only one company has produced hardware which complies with this requirement:
http://www.cryptera.com/cryptera-launches-cryptotouch-secure-pin-entry-for-touch-screens/
I have to agree that this is likely to breach PED rules, which is why all card readers taking payments on iOS devices such as the paypal card reader have a hardware pin entry system to encrypt the data before sending it to iOS via bluetooth.
FWIW I do like the idea of just using my card pin for this, I don’t really get the fuss over not liking personally but that’s probably just me! I’d likely be using that pin anyway even if the two weren’t tied together.
Hi James,
My understanding is that PCI defines a pin entry device as one used within a debit, credit or smart card-based transaction. This is consistent with the majority of US banks, which routinely ask the user to enter their card pin for parts of internet and mobile banking.
I appreciate that this is not something UK banks have done and one shouldn’t use US banks as an example of good security. We will be PCI compliant and all of our procedures will be approved by an auditor.
That does seem more following the letter of the rules, rather than their spirit, but in any case - I do appreciate that you have given it some serious thought and consideration for further developments.
I haven’t read all posts, but from the OP I think this is the best place for this.
The betfair app links into the iOS system whereby if your fingerprint doesn’t match, you use your iOS passcode. It’s the first app I have had that uses this and I feel it works well.