You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: