IAM users are not completely aware of their login options and restrictions

[viorelaioia-zz]

I'm not sure if the title captures entirely the issues we have, so I'll try to give some context.
From the issue reported by a DeepSpeech contributor who tried to register to discourse, looks like there is a need in giving people more info about the available options and restrictions that come after selecting a method, when they try to register to an RP via IAM.

Problems :

• Users don't know that they will be forced to use mfa when selecting the github login option;
• Autologin is triggered even though the login / register attempt has failed;
• Users currently believe they can choose any of the available login method for register, if their previous register attempt has failed (eg: login with github mfa has failed -> so the user tries to login with google using same email address);
• Users are not aware they won't be able to login using a less secure account if they registered using github / google;

After conversations from slack, we considered a few changes in order to improve user experience:

• Make "Go Back" button disable autologin - agreed to implement;
• Make it more visible for people that selecting the github method to register/login will prevent them from logging in with google or passwordless and that they must enroll 2fa in order to successfully register/login;
• Record register with github no-mfa as a failed attempt and allow users to register with another (probably less secure) method;

There are probably other solutions, so this is just the starting point.
Everyone, feel free to share your thoughts on this.

[mbransn]

Thanks for the write up here @viorelaioia, extremely helpful!

Make it more visible for people that selecting the github method to register/login will prevent them from logging in with google or passwordless and that they must enroll 2fa in order to successfully register/login;

@hidde is it possible here to provide an intermediate screen (or overlay?) that outlines for users: "You are about to Log In / Sign Up via a method that requires 2FA. Once you do, this will be the only login method available to you as it is the most secure. " This assumes that we also provide a 2FA and most secure as links to more info via FAQ.

Users are not aware they won't be able to login using a less secure account if they registered using github / google

Additionally, is it possible to do something similar for Google, but with messaging tailored to this method (e.g. remove 2FA messaging)?

I'd like to avoid bloat/slow-down in the experience and believe auto-login will help users avoid these interstitial screens on subsequent logins. For a first time experience though, touchpoints like these are becoming more crucial.

*Note: I'm working on an updated NLX user journey where we can more readily map this experience and tailor touchpoints to each case. Will especially want yours and @viorelaioia's eyes on this when it's ready (likely next sprint).

[hidde]

@hidde is it possible here to provide an intermediate screen (or overlay?) that outlines for users: "You are about to Log In / Sign Up via a method that requires 2FA. Once you do, this will be the only login method available to you as it is the most secure. " This assumes that we also provide a 2FA and most secure as links to more info via FAQ.

Additionally, is it possible to do something similar for Google, but with messaging tailored to this method (e.g. remove 2FA messaging)?

This can be done, but I guess we'd ideally only do this on a first time? There's a blocker there: we currently don't have the notion of “NLX first-time use”, and I think we can't have that reliably unless users always have to enter email before anything else.

You can get an idea of the slowing down by filling in an email address that does not end in @mozilla.com, as we currently look up those email addresses before we decide which screen to show next. It is reasonably fast, but not instant (and it is more noticeable on slow connections/devices).

[mbransn]

This can be done, but I guess we'd ideally only do this on a first time? There's a blocker there: we currently don't have the notion of “NLX first-time use”, and I think we can't have that reliably unless users always have to enter email before anything else.

I'm proposing we do serve this interstitial screen for GitHub and Google all the time.

• Pro: Those users who have auto-login enabled will bypass it.
• Con: Those who do not, and who regularly switch between accounts, will most likely get annoyed. My understanding though is that these users are more edge case, fewer in numbers?
• Overall benefit: Email is not required of every user coming to NLX, thus keeping things fast but also aiding those users who are new.

Curious of the teams reaction to this approach...

[gene1wood]

I'm sharing this as my opinion, not as a position of infosec. My intent is for it to be considered along with everyone else's opinion and not to have greater weight than that.

I disagree with the fundamental idea of the IdP ratcheting (where once you login with GitHub for example you can never login with Google again). My reasons for this are

• This behavior (of limiting which IdPs you can login with based on what you've logged in with before) is unique across websites and will be the first time a user encounters this idea.
• This behavior category (of limiting what a user can do based on previous innocuous seemingly idempotent actions) is also unique across websites. Users are not used to taking idempotent actions and having permanent changes occur because of them.
• It breaks the rule of "don't surprise users". This could be mitigated by warning them beforehand.
• This isn't what the user wants. The user wants choice in what IdP they use.
• The notion that Google is less secure than GitHub or LDAP because we can't determine from Google if the user has MFA enabled is a based on the assumption that the single most important method that Google uses to prevent fraud in their IAM system is MFA. I believe that Google is using many many signals to detect unauthorized login to Google accounts and that MFA is merely one of those signals. I think Google should be considered equally safe to GitHub+MFA or LDAP+MFA.
• The passwordless IdP login method is less secure than the other options if the recipients email provider is of lower security. This lower security could manifest either as poor user authentication (no MFA, no IP geo tracking, etc) or as not supporting encrypted SMTP. The vast majority of users have email addresses with one of the major web email providers and as a result enjoy high security email (encrypted transport, IP geo testing and other heuristics to prevent fraudulent use). As a result passwordless shouldn't be considered of lower security than the other IdPs and we should accept the added risk of the minority of users who have home built email systems and login with passwordless.
• The overall negative impact to users is greater than the benefit of security that ratcheting provides.

[gdestuynder]

On removing 2FA and other account verification requirements

(ie @gene1wood's point above)
If trade offs in the name of convenience are made, then it becomes difficult to use the same infrastructure for all RPs. I disagree with the statements echo'ing that we should lower the security of the system due to the issue of a few. There will always be some degree of cristicism if you have enough users, no matter the implementation.

On UX

I do agree that we should enhance the UX where we can though, if possible until it is no longer an inconvenience. I suspect that mozillans.org repositioning will also help with this as well as profile v2 (which considers primary_email to be similar to user_id and solves a good part of the root of the issue)

I suspect that we need the complete user flow mapped in order to take the right UX decisions though, otherwise we might redirect some work to testing UX work-arounds that we may retire a quarter later.

Some additional ideas

Finally, a few additional options (not to implement necessarily, just to think about):

A)
we could always redirect users to a mozillians.org's account upgrade page when it is detected that they attempt to login with a different login method but the same primary_email. Effectively this makes the user flow:

1. login with passwordless [email protected]
2. login again later with github [email protected] (for the first time)
   2.1 Auth0 detects the login method for the same primary_email, [email protected] changed from passwordless to github
   2.2 Auth0 deletes the newly created & temporary Auth0 account for github|xxxxx ([email protected]'s github user_id)
   2.2 Auth0 redirects to mozillians.org/account_upgrade/[email protected]&from=email&to=github (or similar)
   2.3 Mozillians.org proposes to the user to upgrade, explaining the added security grant them the use of access_groups - but losing the possibility to login with passwordless for that primary_email, or, to go back and cancel

B)
Same as A), but in addition, allow non-2FA'd accounts. This still does not let you login as passwordless and github (for example) as you have to select which one you want, but allows using non-2FA'd Github (and thus also Google and others). In that case, it also forbids the usage of access groups. Note that this option would still be unavailable for any LDAP account.

Neither A or B solve the "logout" issue, which is, if a user does not know where to log out, they effectively cannot log out until the session expires. Many systems such as Google's avoid this by owning the code for every single RP they utilize and providing a logout button. We do not have that luxury, though. I suspect making auto login default-off for new users and making it clear that enabling it means you have to logout (or in the future, change your login method) sounds better to me than the interstitial screen though. We could even have both options I guess (auto-login on/off interstitial screen on/off)

ps: I tried to make this a short post and failed ;p

[mbransn]

I suspect that we need the complete user flow mapped in order to take the right UX decisions though, otherwise we might redirect some work to testing UX work-arounds that we may retire a quarter later.

In progress 👍