[Feature] Secure email change, multiple identities, and new identity types

[robotdan]

Secure email change and multiple identities

Problem

Allowing just anyone to change your email address without adequate confirmation from both the current email address owner and the new email address owner - hopefully they are the same person - can be a huge security risk.

Solution

To properly handle modifying your email address the existing email address used for login must continue to work for authentication, and the owner of the email address must be notified of the change and allow it to be reversed or not approved at all.

There are many complexities to this problem that need to be solved correctly to ensure a secure transition from one email address to another.

Solution Details

The current design we have will allow for multiple emails per user to account which means the user may have a primary and one-to-many secondary email addresses. The user can then authenticate with a primary email address while a secondary one has been added and perhaps not yet verified during a change email workflow.

Account Takeover Scenarios

One of the use cases will be to protect against account takeover. The following are some examples of account takeover techniques.

Un-verified Email address

The lesson here is that unless you verify that a user owns the email address it can potentially be used for account takeover.

1. A 3rd party application such as coolonlinegamestore.com allows users to sign up with email
2. coolonlinegamestore.com does not require email addresses to be verified.
3. Johnny Hacker signs up for coolonlinegamestore.com with an email address of jared@piedpiper.com.
4. A user with email address jared@pipedpiper.com already exists in FusionAuth.
5. FusionAuth has enabled an OpenID Connect IdP to allow users to login with their coolonlinegamestore.com account.
6. Johnny Hacker logs into an application using FusionAuth as the IdP using the "Login with Cool Online Game Store" button.
7. Johnny Hacker proceeds to log into coolonlinegamestore.com with his email address of jared@piedpiper.com.
8. The token is returned to FusionAuth which contains an email claim of jared@piedpiper.com.
9. FusionAuth looks up this user by email which is globally unique within a FusionAuth tenant and completes login for Johnny Hacker.

Johnny Hacker does not yet known the password for jared@piedpiper.com in FusionAuth but if the application allows the user to modify the password or email he can now completely take over the account. At a minimum he has logged into the application managed by FusionAuth as jared@piedpiper.com.

Non unique loginId

The lesson here is that any "login identifier" that is not globally unique can be potentially used for account takeover. In this example we'll utilize a username as it is the most common example.

FusionAuth is not currently susceptible to this attack because we do not allow the username to be set during a reconcile Lambda or used as the unique identifier during an IdP reconcile. We have discussed removing this limitation because it also limits legitimate use cases where the user of the lambda and IdP can guarantee the uniqueness of the username within a specific domain.

This feature will aim to support a non-unique "login identifier" and provide adequate controls to utilize it safely with external identity providers.

1. A 3rd party application such as coolonlinegamestore.com allows users to sign up with a username.
2. Johnny Hacker signs up for coolonlinegamestore.com with an email address of jared.
3. A user with a username of jared already exists in FusionAuth.
4. FusionAuth has enabled an OpenID Connect IdP to allow users to login with their coolonlinegamestore.com account.
5. Johnny Hacker logs into an application using FusionAuth as the IdP using the "Login with Cool Online Game Store" button.
6. Johnny Hacker proceeds to log into coolonlinegamestore.com with his username of jared.
7. The token is returned to FusionAuth which contains a preferred_username claim of jared.
8. FusionAuth looks up this user by username which is globally unique with a FusionAuth tenant and completes login for Johnny Hacker.

In this example, the account takeover may have been malicious, or it may be a username collision.

Johnny Hacker does not yet known the password for jared in FusionAuth but if the application allows the user to modify the password, username or email he can now completely take over the account. At a minimum he has logged into the application managed by FusionAuth as jared.

Self-service account management

This feature will also impact our self-service account management pages. We should ensure that all of the use cases are covered there including updates to email address, username, MFA, and password.

Related Issues

• Reconcile Lambda not allowed to set user.username OIDC with GitHub and Discord: impossible to set user.username #698. We could potentially allow a free form identity type to allow a name space to be declared where a username is unique. For example, if we allowed a Twitter namespace to be declared, then we could allow the Twitter username to be used to reconcile an identity of type Twitter.
• Connect social media accounts to a FusionAuth user w/ a different email address. Permit user to add directly their social account to an existing account #751

New identity types

Since this feature requires significant changes to our identity modeling, supporting new identity types seems like a good fit to include as well. Currently, FusionAuth supports emails and usernames for identities. Additional identity types might include:

• Phone number (mobile likely)
• Government id
• Secure id
• Certificate/token
• None (just an id)

By adding the ability to have different identity types and verification and validation for each, FusionAuth can handle a wide array of use cases.

Related

• Add phone number as loginId for push login and registration #208
• Permit user to add directly their social account to an existing account #751 (comment)
• User Email Updated without verification overwriting existing email (verified) #1638
• Possible to create multiple users with same Login #1874
• Passwordless Authentication through SMS (Twilio) #1552
• Possible to create multiple users with same Login #1874

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[zbruhnke]

@robotdan Adding to this (And the conversation in slack today) we have a couple of other ideal use cases for our team.

1. A user would like to add a secondary email (but not make it primary)
2. A user would like to add a secondary phone number (but not make it primary)
3. A user would like to add a new email and set it as primary
4. A user would like to add a new phone number and set it as primary.

Ideally we could have no limit to the number of emails or phone numbers tied to account but if there was a limit I'd say at least 3-5 would be nice on the high end.

On ALL of these scenarios ideally we would send an email (or text message) to the CURRENT primary email (or Phone number) for confirmation and to the new email (or number).

for a net NEW email or phone number we would want it to be confirmed before it could be made primary or used for account information.

Ideally there would also be a way to configure a setting in FusionAuth to either choose to FORCE the old email or phone to approve the change (with an email or text message) or allow it to happen without approval by the account owner (by just not objecting to it)

Because I think some use cases (like ours – banking) might dictate stricter rules (like always approve) while others (like SAAS) could be slightly more lenient.

In this use case we're thinking both multiple emails and multiple phones because we're using FusionAuth for 2FA and Email verification so building out a backend just for adding the additional ones seems like it would be silly to have that done outside of FA.

Let me know if this all makes sense.