I've reviewed several iOS posts about Touch ID, and after doing so I have a question and suggestion.
First, I'm wondering, how many Touch ID attempts/failures in a row does it take to transition the 1Password application on iOS to accept only a master password next to unlock? I'm referring to the case where otherwise nothing else changes (no new fingerprint changes added to Touch ID, no restarts of the device, no master password change and so on). I could be wrong, but it seems that after just two or three Touch ID attempts, the only means to unlock becomes the master password. Please let me know the definitive details on this - whether this is expected/desired.
Secondly, I get that Touch ID isn't meant to be a substitute for the master password for unlocking the application and its services. And for any nonstandard operations requiring "higher authentication", I would also expect to be prompted for the master password. (That still leaves the most common operations such as accessing and adding new passwords for the most part unlocked by Touch ID).
As an analogy, a similar tradeoff is made when it comes to booting an iOS device itself; upon cold boot, the device's password is absolutely necessary to power on and enable Touch ID. I value that tradeoff, and it's a small ask from Apple, especially given that I can easily keep an iOS device on with enough battery for a long period of time.
But, that said, I'd like to suggest that upon powering on the device, that only one password might be necessary (the device's password) to eventually provide the user access to their underlying passwords; similarly, this approach can provide an alternative to entering the master password in other situations (not just power on). What about letting the 1Password application request split-secret key material from iOS that's unlocked by touch ID, and also, all other devices owned by the user are sent a push notification, at which time the user then approves the unlock of the original iOS device with a Touch ID response or a simple acknowledgement when that device is unlocked?
The second part of that would be similar to how Apple's current multifactor authentication works (authentication needs to be approved from any other device). This can boil down to certain key material being provided securely to unlock the credentials at that time (rather than allow-by-permission, it can be designed as allow-by-cryptography). Then an attacker would need to steal more than one device to succeed - and the device would need to be on and unlocked. In all cases, the split secret can be arranged so that any isolated subset of shares reveals nothing about the secret.
If the key material only comes from the local device, this is an exceptional case, and then the protected passwords might only be as secure as the device's power-on password. Not all users may want that, but some might. The second source of the key material (another device) relatively enhances security when they have more than one device. These are a few ideas.
1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided