1198418 - [meta] Local authentication Touch ID / Passcode support

Status: RESOLVED FIXED

(Firefox for iOS :: Login Management, enhancement)

Description

[Aaron Train [:aaronmt]]

We should look into how we can explore the value of adding local authentication (touch ID) support in the browser on Apple devices with this support

Some ideas

*  via Private Browsing tab access
*  general browser access

Comment 1

[Richard Newman [:rnewman]]

Perhaps most obviously:

* Before form-filling passwords.

Comment 2

[Robin Andersen [:tecgirl]]

(In reply to Richard Newman [:rnewman] from comment #1)
> Perhaps most obviously:
> 
> * Before form-filling passwords.

^ That was my first thought when Aaron mentioned it in #mobile.

I can't see a benefit from general browser access. Private Browsing, certainly.

Comment 3

[Robin Andersen [:tecgirl]]

+ Logins management

Comment 4

[Robin Andersen [:tecgirl]]

Attachment: TouchIDPasscode.png

Touch ID & Passcode flow for Logins and Private Browsing instances.

Comment 5

[Stephan Leroux [:sleroux]]

:tecgirl/:mpopova, would it make sense to create a separate AHA card for this? It's related to both private browsing and password management but I see it as a separate thing.

Comment 6

[Robin Andersen [:tecgirl]]

Yes, this needs its own Aha! card. A card for Master Password exists (https://mozilla.aha.io/features/FIOS-208) but this is beyond that. I don't have the permissions so I'll leave it up to Maria.

Comment 7

[Stephan Leroux [:sleroux]]

Attachment: Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1367

Comment 8

[Stephan Leroux [:sleroux]]

Oops - realized this is attached to the meta bug not the strings bug. Updating.

Comment 9

[Stephan Leroux [:sleroux]]

I notice in the mocks that we have a section that allows the user to configure areas of the app where Touch ID can be used. How does this configuration work for passcode and not touch ID?

Comment 10

[Robin Andersen [:tecgirl]]

(In reply to Stephan Leroux [:sleroux] from comment #9)
> I notice in the mocks that we have a section that allows the user to
> configure areas of the app where Touch ID can be used. How does this
> configuration work for passcode and not touch ID?

My initial reasoning is that passcode must be enabled prior to using Touch ID. So, by default passcode covers both instances for users that don't have Touch ID. My concern was for the user who may have a Touch ID device, but choose not to enable the feature, therefore not allowing them to choose which area of the app to protect (all or nothing). 

To simplify this, let's just the a toggle to enable Touch ID, and only apply it for Logins Management at this point. I'll attach an updated screen.

Comment 11

[Robin Andersen [:tecgirl]]

Attachment: TouchID&Passcode-On-TouchOn.png

Possible new string:
[Require Passcode]

Updated string:
[Use Touch ID] (was [Use Touch ID for])

Comment 12

[Stephan Leroux [:sleroux]]

I've been working on the passcode input screens for creating, changing, and validation of a passcode and I think we might be missing some strings for the screens to make sense.

For example, when changing a passcode, I assume that we would want to ask the user to input their old passcode and then ask them to enter a new one. The current copy we have available are:

1. 'Enter a passcode'
2. 'Re-enter passcode'
3. 'Turn off your passcode.'
4. 'Set Passcode'
5. 'Turn Passcode On'
6. 'Turn Passcode Off'

Ideally for these states we would want to ask the user 'Enter your passcode' then 'Enter a new passcode' in the case of changing your passcode.

Another thing that we probably want to include is some copy/UX for error states. For example, when using the system passcode UI, they display a red bubble with text indicating number of attempts. Not sure if this is something we want to do but one slightly confusing thing is if the user enters their passcode and fails to match it in the confirmation screen, we don't have any copy or UI to indicate to the user that the passcodes didn't match. On the branch where I have the passcode screen built I'm just scrolling the user back to the previous input screen.

Anyways I'm worried that this late in development with strings being frozen that we might not be able properly convey to the user the interactions of the passcode screens. I'm thinking this may need to be pushed to a follow up (2.1/3.0) release.

Thoughts?

Comment 13

[Robin Andersen [:tecgirl]]

We don't necessarily need to tell the user how many times they're allowed to attempt, but we may need strings and a course of action if X-attempts are made and if they don't match.

For excessive attempts:
"Maximum attempts reached, signing you out of Firefox Sync"
(that way, they can sign back in to sync to begin the process again)

For mismatched passcodes:
"Passcodes didn't match. Try again."
(shown on the passcode entry screen)

Comment 14

[Stephan Leroux [:sleroux]]

I did some research on the LocalAuthentication API used for Touch ID and have found out the following:

1. Allowing users to use Touch ID in our app is pretty straight forward. If the user has setup Touch ID and everything is working fine, we can simply provide a system-provided prompt asking the user to authenticate with their finger and know when it passed/failed.

2. There are a variety of errors that can occur when using Touch ID [1]. A few of them are simple to handle (UserCancelled) but others would require some copy to give feedback to the user about why it failed. This copy is not provided by the system.

3. Touch ID has the ability to 'fallback' onto another form of authentication. This fallback mechanism is a custom authentication scheme provided by the app developer. For example, account login password or custom passcodes. The system does not provide a default for a fallback.

Regarding 2.0 feasibility, even going with the Touch ID route we would need additional copy to convey errors to the user which would require new strings. For post-2.0 implementations, we can provide a custom passcode solution but this would not solve the forgotten passcode dilemma. A simple solution we could do for a fallback is to:

1. Require users who want to use Touch ID/Authentication to access logins/private browsing to use a FxA account.
2. Use the FxA sign in as the fallback authentication mechanism.

This solution would leverage the existing infrastructure for FxA account management. I'm not sure how that process works but we can include tie-ins with the app such as launching the forgot password pane or invoke the API to reset the password.

[1] https://developer.apple.com/library/ios/documentation/LocalAuthentication/Reference/LAContext_Class/index.html#//apple_ref/c/tdef/LAError

Comment 15

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

We should stick to the original plan of local passcode and optional touch id for those folks who have supporting device.

Comment 16

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

I think we are over-complicating this. Here are some thoughts:

First, a user *always* needs to set a passcode.(In reply to Robin Andersen [:tecgirl] from comment #13)
> We don't necessarily need to tell the user how many times they're allowed to
> attempt, but we may need strings and a course of action if X-attempts are
> made and if they don't match.
> 
> For excessive attempts:
> "Maximum attempts reached, signing you out of Firefox Sync"
> (that way, they can sign back in to sync to begin the process again)

Why do we want to connect this to Firefox Sync? Lets keep this simple and do not lock people out or disconnect them from Sync. This is absolutely not needed. It only complicates things.

Comment 17

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Stephan Leroux [:sleroux] from comment #14)
> I did some research on the LocalAuthentication API used for Touch ID and
> have found out the following:
> 

> 3. Touch ID has the ability to 'fallback' onto another form of
> authentication. This fallback mechanism is a custom authentication scheme
> provided by the app developer. For example, account login password or custom
> passcodes. The system does not provide a default for a fallback.

The fallback is our app specific passcode. The passcode is a requirement to be able to use TouchID. Without the passcode set, you cannot enable TouchID. So we do not need some special fallback. We just need to show our existing passcode dialog.

> Regarding 2.0 feasibility, even going with the Touch ID route we would need
> additional copy to convey errors to the user which would require new
> strings. For post-2.0 implementations, we can provide a custom passcode
> solution but this would not solve the forgotten passcode dilemma.

We can be simple about this: forgotten passcode means you have to delete the app, set it up again.

This is security. No backdoors, no complicated fallbacks via mechanisms not in our control (FxA).

Comment 18

[Stephan Leroux [:sleroux]]

I think we still want to implement a limit to the number of times a person can enter an incorrect passcode to prevent brute-force attacks. Orignally we were trying this to FxA but since we're not doing that not do we just want to do a simple timeout? Maybe an hour? 

The messaging would probably change I'd imagine to something like the following:

"Incorrect passcode. Try again (2 attempts remaining)."
"Incorrect passcode. Try again (1 attempt remaining)."
"Maximum attempts reached. Please try again in an hour."

Comment 19

[Richard Newman [:rnewman]]

(In reply to Stephan Leroux [:sleroux] from comment #18)

> "Incorrect passcode. Try again (2 attempts remaining)."
> "Incorrect passcode. Try again (1 attempt remaining)."
> "Maximum attempts reached. Please try again in an hour."

Careful about l10n for plural forms.

Comment 20

[Stephan Leroux [:sleroux]]

What's the recommended way of handling these plural forms? Is the fear that the translations might be verbose in some cases?

Comment 21

[Richard Newman [:rnewman]]

See Bug 1181777.

Comment 22

[Stephan Leroux [:sleroux]]

Looks like we don't have this infrastructure in place. As a compromise we could reword it to be:

'Incorrect passcode. Try again (Attempts remaining: N).'

This way we don't have to worry about plural rules.

Comment 23

[Robin Andersen [:tecgirl]]

This just reminded me that I may have not attached the updated mock (there are so many related bugs!)

We don't have to tell the user how many attempts are remaining. Let's just decide on a number and present them with a message if they hit it:

"Max attempts reached."

and present < Back

Comment 24

[Robin Andersen [:tecgirl]]

Attachment: TouchIDPasscode.png

Comment 25

[Stephan Leroux [:sleroux]]

Removing meta bug from tracking list.

Comment 26

[Stephan Leroux [:sleroux]]

Unassigning myself from the meta since dependent bugs have assignees.

Comment 27

[Justin D'Arcangelo [:justindarc]]

Closing meta bug.