I don't know whether this is 1Password issue of an Apple issue but when I move the extension to the far left, as suggested, it does NOT stay there...would be great to get this fixed...
This is an iOS issue. Almost everyone on our team has filed a bug report with Apple, hopefully it gets fixed soon... It also existed in the betas.
Appreciate the link as well as the explanation which I think I understand as it appears that there are two timers i) time between opening with the master password and ii) time before asking for a finger print again...to maximize the amount of time that one can use touch ID the first needs to be set to 30 days (longest available) while the second can be set to a shorter interval for security (say, two days)...
I do however wish that the functionality would be different and simpler...to me the best approach would have been to simply allow the use of Touch ID in place of the master password (i.e. in the same way one can use Touch ID to unlock a phone).
There's no super simple way to do this. TouchID does not give us anything other than a "Yes/No" type of response. It's hard to replace the master password with Yes/No and still be secure
🙂
What we do is store the Master Password in the iOS keychain with a few important flags:
1) It can only be accessed by 1Password
2) It never leaves the device (no iCloud Keychain sync)
3) It requires the device's passcode (we suggest a longer non-digit only passcode) or TouchID to gain access to the item in the iOS keychain
We can then use that to unlock the application. Given that though, we felt limiting the time it was made available before typing in the master password served a few great functions:
1) Basing it on time means that the user can use it for fast app switching purposes only if they wish, or have it on for a longer period of time
2) Basing it on time means they do have to type their master password in at some point, otherwise they may forget it.
Nothing hurts worse than telling a person we cannot recover their master password because they forgot it. Happens often enough to give me nightmare's. We cannot reset a user's password so if it's forgotten it's forgotten and so is the data contained within. If we allowed resets that would mean there was a way for a malicious user to try to gain access.
We made these choices to provide the best set of options for you, our users. They may not always be exactly what you want, but they're usually a pretty good middle ground between being secure and convenient.
----------
I'm ok with needing to put the password in every 30 days or on a reboot and figure that Agilebits has valid security reasons for giving these options. The interface should make the options clearer, though, without having to find a FAQ page.
Agreed. It's just hard to explain in limited amounts of space
🙂 I'm sure we'll reword it over time in an attempt to improve it. Sometimes you have to get feedback from users about what is confusing and seeing it in support before you know what is unclear or needs alteration.