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
[Feature] Secure email change, multiple identities, and new identity types #1
Comments
@robotdan Adding to this (And the conversation in slack today) we have a couple of other ideal use cases for our team.
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. |
Relevant post about digital identity: https://christine.website/blog/identity-model-software-2021-01-31 |
@mooreds Quick question. Will fusionauth support mobile phone / SMS soon as MFA? and maybe as secondary method to do a password reset? |
@sanderkooger SMS MFA is already supported: https://fusionauth.io/docs/v1/tech/guides/multi-factor-authentication#types-of-mfa-supported |
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.
coolonlinegamestore.com
allows users to sign up with emailcoolonlinegamestore.com
does not require email addresses to be verified.coolonlinegamestore.com
with an email address ofjared@piedpiper.com
.jared@pipedpiper.com
already exists in FusionAuth.coolonlinegamestore.com
account.coolonlinegamestore.com
with his email address ofjared@piedpiper.com
.email
claim ofjared@piedpiper.com
.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 thepassword
oremail
he can now completely take over the account. At a minimum he has logged into the application managed by FusionAuth asjared@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.
coolonlinegamestore.com
allows users to sign up with a username.coolonlinegamestore.com
with an email address ofjared
.jared
already exists in FusionAuth.coolonlinegamestore.com
account.coolonlinegamestore.com
with his username ofjared
.preferred_username
claim ofjared
.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 thepassword
,username
oremail
he can now completely take over the account. At a minimum he has logged into the application managed by FusionAuth asjared
.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
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.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:
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
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.
The text was updated successfully, but these errors were encountered: