Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for logins to sites requiring 2FA login #29

Open
Goosth opened this issue Sep 17, 2020 · 0 comments
Open

Support for logins to sites requiring 2FA login #29

Goosth opened this issue Sep 17, 2020 · 0 comments

Comments

@Goosth
Copy link

Goosth commented Sep 17, 2020

This issuer relates to #9 but given the amount of discussions on the original Rememberme function its probably better to log this as a separate request/requirement to consider.

The original post from @melanierichards on #9 referred to the bank website login usecase. Banks don’t typically allow a user to remain logged in across sessions. They need to protect their users, while still aiming to make the login process easier.
The industry best-practice for a high-security login situations is two-factor authentication (2FA). Choose 2 factors from:

  • Something you know (e.g. password/PIN)
  • Something you have/possession (e.g. SMS OTP, Trusted Mobile App, Hardware device)
  • Something you are (e.g. face or fingerprint biometrics).

Supplying all of these at a login or step-up can be painful. WebAuthn will start to improve this, but there are still a number of cases where this is not supported, or where a device pin/biometric is not appropriate (e.g. multiple people in a family has their fingerprints setup on the device).

The possession factor is a key element. In fact, many banking apps start off by asking you to ‘Register’ the app before you can login. They use full 2FA based on existing authentication elements, and then mark the app identity as a trusted device for this user. For future logins, only a password or PIN is asked, with the app being considered as the possession factor from thereon forwards.

Could we not enable a similar capability for browsers. Basically a user will still perform 2FA (e.g. some form of OTP or Out of Band push to their Banking App). After that is completed however, we could allow a customer to trust/Register a browser for this domain. To some extent this is already done today via Cookies or IndexedDB. Today however, these may be cleared if user does not regularly return to the site. And that then results in legitimate implementations having to fall back to device fingerprinting, which is of course not ideal.

The goal is to allow a better user experience on these trusted browsers, by allowing users to consent to it. If they don't want it, they can still login with a more explicit 2FA authentication every time. I think it relates to 'ExpectsPersistentState' that @ajknox mentioned or perhaps even 'RememberDevice' mentioned by @johnwilander.

What if we created an explicit call to allow the browser to get user consent (e.g. setTrustedBrowser)? The browser would then ask the user if they would like to trust/register this browser. It could include a default duration that could be selected. E.g. "Trust this browser for 3 months to improve your bank.com logins". With this consent the browser could then get a clear signal that bank.com’s Cookies and IndexedDB storage should be maintained for the approved duration. After this duration expires, the user could also be prompted to renew (“You previously indicated that you want to trust bank.com for logins. Would you like to renew that for another 3 months?”).

This mechanism would really help current sites that are using cookies or information for legitimate reasons to help create a better user experience for end-user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants