1261851 - Lack of passcode timeout exposes logins on application background/restoration

Status: RESOLVED FIXED

(Firefox for iOS :: Login Management, defect)

Description

[Simon Basca [:SimonB]]

Build: 3.0 (9)

Steps to reproduce:
1. Launch Mozilla Firefox 
2. Set Passcode On
3. Access Logins and enter password
4. Minimize Firefox by pressing the Home button.

Actual results:
- The logins can be access without entering the passcode.

Expected results: 
- The logins should be secured if the passcode is turned on even when the application is running in background.

Note:
- This represents a security risk as most users do not close the application but rather minimize it by pressing the Home button.

Comment 1

[Aaron Train [:aaronmt]]

Is there a set default passcode timeout (15 min?)? If not, should we add one?

Comment 2

[Stephan Leroux [:sleroux]]

We don't have a timeout period when looking at logins at the moment. We have a setting 'Require Passcode' which specifies a timeout period but is currently used as the 'remember' duration after a user entered their passcode. For example, if the user sets it to 15 mins and enters their passcode, they can access logins without inputting their code for 15 mins. We could use this interval as the 'timeout' period as well. This would look something like

Immediately -> Locks logins on background
N Minutes -> Logins are accessible in the background until timer goes off. If user returns back to app after timeout, they are required to enter passcode again.

One UX concern is that the Touch ID modal is displayed on the previous screen. If we come back from background and the user is using Touch ID, would we show the modal on top of the logins or push the user back to settings and request the modal from there?

Comment 3

[Stephan Leroux [:sleroux]]

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

Comment 4

[Stephan Leroux [:sleroux]]

Note: This patch resolves both the logins being available while returning from background and the blurring of sensitive content while being backgrounded. Security++.

Comment 5

[Robin Andersen [:tecgirl]]

(In reply to Stephan Leroux [:sleroux] from comment #2)
> We don't have a timeout period when looking at logins at the moment. We have
> a setting 'Require Passcode' which specifies a timeout period but is
> currently used as the 'remember' duration after a user entered their
> passcode. For example, if the user sets it to 15 mins and enters their
> passcode, they can access logins without inputting their code for 15 mins.
> We could use this interval as the 'timeout' period as well. This would look
> something like
> 
> Immediately -> Locks logins on background
> N Minutes -> Logins are accessible in the background until timer goes off.
> If user returns back to app after timeout, they are required to enter
> passcode again.
> 
> One UX concern is that the Touch ID modal is displayed on the previous
> screen. If we come back from background and the user is using Touch ID,
> would we show the modal on top of the logins or push the user back to
> settings and request the modal from there?

Yes, the modal should appear if 'Immediately' has been chosen or the timeout has been reached, on top of the blurred view.

Comment 6

[Robin Andersen [:tecgirl]]

Comment on attachment 8738596 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1689

Enable auth on return if interval limit has been reached

Comment 7

[Stephan Leroux [:sleroux]]

I tested using a 1 minute interval inside the logins list page and the app prompts for authentication after returning from the background when backgrounded for > 1 minute. Are you seeing different behavior?

Comment 8

[Brian Nicholson (:bnicholson)]

Comment on attachment 8738596 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1689

Looks good, just a few questions.

Comment 9

[Robin Andersen [:tecgirl]]

(In reply to Stephan Leroux [:sleroux] from comment #7)
> I tested using a 1 minute interval inside the logins list page and the app
> prompts for authentication after returning from the background when
> backgrounded for > 1 minute. Are you seeing different behavior?

I have mine to to "Immediately" and I can see my logins for .5s before the passcode prompt overlays. I have video that I can share privately (since they are my actual logins).

Comment 10

[Stephan Leroux [:sleroux]]

In the .5s are the logins blurred or are they unblurred? I can't seem to reproduce the issue where the logins are not blurred upon coming back into the app.

Comment 11

[Stephan Leroux [:sleroux]]

Moving to 5.0 as per discussion last week.

Comment 12

[Stephan Leroux [:sleroux]]

Forgot to re-NI

Comment 13

[Robin Andersen [:tecgirl]]

:sleroux — http://c.tecgirl.com/flXT

you can see the login for just a moment before the passcode.

Comment 14

[Stephan Leroux [:sleroux]]

Comment on attachment 8738596 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1689

I've moved the protocol extension into a subclass and extended the list/detail view controllers. With the previous approach, I found a bug where while on the detail page, the notifications were also being sent to the list view controller. Using the subclass approach also makes it simpler so I opted for that. Any issues you were seeing before :tecgirl should be resolved now.

Comment 15

[Brian Nicholson (:bnicholson)]

Comment on attachment 8738596 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1689

LGTM. Nice work with all the tests! Having issues running them though...not sure whether that's just my build.

Comment 16

[Robin Andersen [:tecgirl]]

Comment on attachment 8738596 [details] [review]
Link to Github pull-request: https://github.com/mozilla/firefox-ios/pull/1689

No delay! Woot!

Comment 17

[Aaron Train [:aaronmt]]

Land it?

Comment 18

[Stephan Leroux [:sleroux]]

There's an issue with the tests and the new menu that's causing some problems. I flagged fluffyemily in the PR but I'll NI here just in case.

Comment 19

[Emily Toop (:fluffyemily)]

:sleroux : yes, there is a bug in menu whereby we are not checking that the number of menu items is 0 before we try and use it in a division.

The main problem, however, seems to be that the test is trying to perform actions before a page has loaded. In fact, it seems as if the page never actually loads, so we are in a Loading state rather than on a webpage or a home panel. I think that needs to be addressed - I'm sure it never used to behave like that on these tests.

Comment 20

[Emily Toop (:fluffyemily)]

:sleroux: just added a link to a PR containing a fix for the menu issue: https://github.com/mozilla/firefox-ios/pull/1792

Comment 21

[Stephan Leroux [:sleroux]]

master c4b40b0a759e083ed284dfdb3ea46fa0081c75f5