Implement Idle App / Re-Login Behavior

[bseebacher]

As a user, I expect to provide my password on initial setup and when the application is started. After the app resumes from sleep, the password is presently not required. Since mobile OS platforms are aggressive about using sleep behavior, this may result in the application not being fully shut down for extended periods, leaving the application open for viewing without a password prompt.

As the product owner, I need to decide how to balance usability (minimizing password prompting) and security (checking credentials). We have the capability to prompt for password every time the app resumes from sleep, but it may not be desirable to force this on the user on every load. Some sort of timeout mechanism may be possible to implement as a compromise.

[rockfordlhotka]

In talking to @tlhotkamcm it sounds like the preferred approach is to use a timer so the app locks after a few minutes of inactivity.

[jacob-maristany]

@rockfordlhotka
We have two states to consider: what happens when the app comes to the foreground from the background and what we manually lock while in foreground due to "inactivity."

We can easily force the login each time the app is brought up from the background and persist the work the user was doing by overlaying the login page.

For the foreground, the concept of "inactivity" in iOS and Android are vague. While in the foreground, the app is continually running, but what is "inactivity"? There is a layer of security where devices should have passcodes and lock screens, but (in these scenarios), we cannot depend on the users to have such passcodes and lock screens. So, back to the original question: if we assume the user is in the foreground and we start a timer while the user is using the app in the foreground:

1. What do we determine as inactivity? E.g. no navigation has occurred? Any more granular than that and the "inactivity tracking" implementation will be quick pervasive. What if the user is simply reading the content docs? There is some navigation there, but also a lot of text. Either way, we should set a high enough inactivity to recognize if the users are spending a respectable amount of time on any given screen.

2. What should that timeout period be for for the app in the foreground to meet the conditions of "inactivity" (item Add readme file #1)?

My opinion would be to

• Force the authentication every time the app is brought into the foreground
• Only track navigation for purposes of "inactivity". This can be easily done in the few navigation methods in ViewModelBase.
• Set an inactivity timer of 10 minutes. 5 minutes feels too short.

[rockfordlhotka]

I talked to @TeresaLhotka about this, and she thinks you are correct. The 10 min timeout seems right, as does forcing authn when the app is brought into the foreground.

[jacob-maristany]

@rockfordlhotka @TeresaLhotka ,
I realized today that sometimes we (users) put the app into the background temporarily as we check email/etc and then bring it back up in quick order. My proposition to force the user to re-auth 100% of the time that they bring the app into the foreground seems overkill. I'm proposing to set a limit of a minute or so (maybe 2?). If the user brings the app back to the foreground in that short window of time, then they will not have to re-auth.

Also, since this isn't captured elsewhere yet other than the Project board, I'm going to spend some time this summer putting in biometric auths as an option for the user (touch id, face id, etc.) As how these tech always work, the password will still be there and a fallback to the biometric auth.

[TeresaLhotka]

That seems reasonable. It does seem unlikely that a return to the app within a minute of putting it in the background will greatly increase the risk of access by unauthorized users. I love the addition of the biometric authorizations. Thank you for all that you are doing!!! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Jacob Maristany <[email protected]> Sent: Friday, June 12, 2020 10:50:25 AM To: HTBox/MobileKidsIdApp <[email protected]> Cc: Teresa Lhotka <[email protected]>; Mention <[email protected]> Subject: Re: [HTBox/MobileKidsIdApp] Implement Idle App / Re-Login Behavior (#310) @rockfordlhotka<https://github.com/rockfordlhotka> @TeresaLhotka<https://github.com/TeresaLhotka> , I realized today that sometimes we (users) put the app into the background temporarily as we check email/etc and then bring it back up in quick order. My proposition to force the user to re-auth 100% of the time that they bring the app into the foreground seems overkill. I'm proposing to set a limit of a minute or so (maybe 2?). If the user brings the app back to the foreground in that short window of time, then they will not have to re-auth. Also, since this isn't captured elsewhere yet other than the Project board, I'm going to spend some time this summer putting in biometric auths as an option for the user (touch id, face id, etc.) As how these tech always work, the password will still be there and a fallback to the biometric auth. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#310 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJVFMSHBD7JQYZCXUZQCG6LRWJFEDANCNFSM4GDAYC5A>.