iOS TouchID not enabled until 1P app explicitly opened and unlocked with Master Password

BLD
BLD
Community Member

After a restart of my iOS device, an iPhone in this case:

1) Open an app that requires credentials from 1P.
2) Tap "Passwords" to launch 1P. (1P is configured to allow TouchID and Lock on Exit.)
3) Use the Master Password to open 1P for the first time since device restart.
4) Tap credentials and proceed as expected.
5) Some time later need credentials again (same app or another one, doesn't matter).
6) Tap "Passwords" to launch 1P.
7) Expect TouchID option to be available to unlock 1P, but it is not. TouchID does not become available until I explicitly open the 1P app and unlock it with the Master Password.

I usually remember to open 1P explicitly after a restart of my iOS device -- but sometimes I forget and run into this issue, and it's very annoying.

FWIW -- the macOS 1P app does not appear to be subject to this same problem.


1Password Version: 7.3.5
Extension Version: Not Provided
OS Version: iOS 12.4
Sync Type: Not Provided

Comments

  • Hi @BLD

    TouchID does not become available until I explicitly open the 1P app and unlock it with the Master Password.

    That is correct, and working as intended. To enable biometry for autofill the main app must be unlocked using the Master Password. During unlock the main app is allowed to “save” the biometry enabled flag. Due to current limitations autofill isn’t allowed to save that flag. That’s why unlocking autofill doesn’t enable biometry for future 1Password uses. Sorry for the inconvenience! I'm going to speak with our documentation folks to see if we can make this requirement more clear.

    Ben

    ref: apple-2729

  • BLD
    BLD
    Community Member
    edited August 2019

    Are these "current limitations" imposed by iOS or something in your current architecture of the iOS autofill app? If the former, insight would be appreciated as to why the autofill app is treated any differently than any other app. If the latter, I think this should be "fixed." It doesn't matter to the end user how 1P is initially launched.

    Why doesn't the macOS app have similar behavior if this is a design choice?

  • @BLD

    I don't claim to be an expert on Apple's autofill framework but in speaking with our development team it was mentioned that this is "due to limitations with AutoFill extensions."

    Ben

  • AGAlumB
    AGAlumB
    1Password Alumni

    @BLD: To clarify, macOS does not have a Password Autofill feature at all, so it's simply not relevant there.

  • BLD
    BLD
    Community Member

    @brenty, as far as relevance goes, on macOS we're talking about auto-fill in the browser with mini 1P instead. Here's a similar scenario for macOS that I gave above for iOS:

    After a restart of my macOS device, a MacBook Pro in this case:

    1) Open a browser web page that requires credentials from 1P.
    2) Tap the shortcut to launch mini 1P. (1P is configured to allow TouchID and Lock on ScreenSaver, main app exit, etc.)
    3) TouchID not yet available (as expected), use the Master Password to open 1P for the first time since device restart.
    4) Credentials auto-filled (or selected) and proceed as expected.
    5) Lock 1P main app either explicitly or through some event, such as screen saver.
    6) Some time later need credentials again (same web page or another one, doesn't matter).
    7) Tap the shortcut to launch the mini 1P.
    8) TouchID is now available to unlock 1P as expected.

    @Ben It sounds like the iOS framework is preventing 1P from doing what would be desired. As an alternative, perhaps the iOS 1P app could offer a setting that allows access via TouchID even on first use after a device restart -- similar to many other TouchID enabled apps. A banking app I use, for example, doesn't require a password after device restart if I have enabled TouchID.

  • AGAlumB
    AGAlumB
    1Password Alumni

    as far as relevance goes, on macOS we're talking about auto-fill in the browser with mini 1P instead. Here's a similar scenario for macOS that I gave above for iOS:

    @BLD: It's not at all relevant. On iOS, we're using Apple's Password Autofill feature, which does not exist on macOS. That works as ben described above. You're comparing Apples and oranges. ;)

    It sounds like the iOS framework is preventing 1P from doing what would be desired. As an alternative, perhaps the iOS 1P app could offer a setting that allows access via TouchID even on first use after a device restart -- similar to many other TouchID enabled apps. A banking app I use, for example, doesn't require a password after device restart if I have enabled TouchID.

    1Password for iOS has a setting just like that under Advanced. But it does not control iOS Password Autofill behaviour.

  • BLD
    BLD
    Community Member

    @BLD: It's not at all relevant. On iOS, we're using Apple's Password Autofill feature, which does not exist on macOS. That works as ben described above. You're comparing Apples and oranges. ;)

    @brenty, it's relevant because on both platforms I'm using auto-fill that triggers 1P to be implicitly launched. While the underlying technologies are different between the two platforms (Apple's password auto-fill under iOS, and the browser's auto-fill under macOS), the use case is identical.

    1Password for iOS has a setting just like that under Advanced.

    Thanks -- I didn't realize that setting was there. In general, I find it confusing when all settings for a feature are not in one place. But changing that Advanced setting to Never is the (next best) behavior I was looking for -- TouchID works to open 1P initially regardless of whether it was opened via auto-fill or explicitly. That's not perfect (and again doesn't match what the macOS flow can do) -- but it's better than it was.

  • it's relevant because on both platforms I'm using auto-fill that triggers 1P to be implicitly launched. While the underlying technologies are different between the two platforms (Apple's password auto-fill under iOS, and the browser's auto-fill under macOS), the use case is identical.

    I understand. But what matters as far as this goes is the underlying technologies. While macOS and iOS are becoming more and more alike on the surface, much of what is under the hood is still very different. In this case we don't have the ability to make the experience on iOS exactly match the experience on macOS.

    Ben

  • AGAlumB
    AGAlumB
    1Password Alumni

    @BLD: That setting is hidden and not the default because a large percentage of people who use it forget their Master Passwords and then ask us for help accessing their data, and there is literally nothing we can do to help with that. Use at your own risk. Unless you never make changes to your device (e.g. OS updates), you will need to enter your Master Password eventually. Don't forget it. :+1:

  • BLD
    BLD
    Community Member
    edited August 2019

    But what matters as far as this goes is the underlying technologies.

    Ok, @Ben -- fair enough. I'm not an iOS developer, so I'll take it on faith that auto-fill extensions can't access app settings. That's unfortunate. But it seems strange to me because the auto-fill extension appears to launch the actual 1P app. So I would have thought the app would know it had been launched using the Master Password and be able to enable TouchID at that time.

    That setting is hidden and not the default because a large percentage of people who use it forget their Master Passwords and then ask us for help accessing their data

    @brenty, while trying to prevent users from shooting themselves in the foot is a noble goal, I don't agree that dispersing configuration for the same thing all over the UI ever makes sense. You could just as easily accomplish your goal by popping up a dialog when a user selects "Never" to say "Are you sure? We can't help you if... etc. etc." This is a little reminiscent to me of what drives me bananas about iOS in general -- I hate having to go to a separate Settings app to perform configuration for the app I'm in.

  • Thanks for taking the time to share your thoughts @BLD. :)

    Ben

This discussion has been closed.