Update: Authentication Cheat Sheet

[philCryoport]

Add "Change Registered Email Address" section to Authentication Cheat Sheet

I looked around and could not find any guidance on how to safely have a user change their registered email address in a system. At first glance, the Authentication Cheat Sheet seems to be the proper place to do this.

If it's in another cheat sheet, please, somebody tell me where to go look?

If another cheat sheet would be a better place to put this guidance, please somebody propose a more relevant cheat sheet?

Add section: "Change Registered Email Address"
...perhaps as a subsection of "User IDs"?

In that section

• IF there's already a good reference written by a well-accepted authority (NIST, CISA, etc.), then link to that.
• ELSE we write one out of whole cloth

Here's my suggested process:

1. Confirm user's authentication cookie / token is still valid

2. Note to the user that -- if their the originally-registered email address is no longer valid or inaccessible then the user needs to contact Customer Support at to confirm their identity in another way
   ...and that Customer Support will need to be regularly trained on social engineering attacks...or accept the liability risk of an un-authorized change of an account's registered email address

3. Request the user provide:

• new email address
• confirm email address (to attempt to prevent typos)
• current password (to attempt to prevent messing with accounts where the user walked away without locking the computer first)

4. Verify the typed email addresses match each other -- and are valid -- and the current password is correct. DO NOT GO FURTHER unless all of these conditions are successfully met -- and instead show error messages explaining what is broken.

5. IF all of the above verification conditions are successfully met, THEN

• (a) Send email messages with nonces to currently-registered email address and requested-new email address requesting the user click on the link in each with stated time limits of when the change process expires (maybe 1 day expiration?).
• (b) Store these nonces with the expiration time in the data store -- along with the requested-new email address. Leave the currently-registered email address as-is.

7. Inform the user that they need to click on the link in BOTH email messages that were sent within .

8. When server receives web request with a nonce:

• IF (a) the nonce is a known nonce for changing a registered email address AND (b) nonce is within the expiration time AND (c) the change-registered-email-address process for that nonce is NOT YET COMPLETE,
• THEN:
• (a) update data store to note which nonce link was clicked within time, and
• (b):
  • IF still waiting on the other nonce link to be clicked, THEN notify the user that you're still waiting for the other nonce link to be clicked
  • ELSEIF this signifies that both nonce links were clicked, THEN
    • (a) in the datastore, change the currently-registered email address to the requested-new email address
    • (b) clear out the nonces for this request to change the requested email address
    • (c) log the user out of the system (juuuust to be safe)
    • (d) inform the user that their registered email address has been successfully changed
    • (e) inform the user that they have been logged out -- and now should log in with their new email address

OTOH:

• IF the nonce is NOT a known nonce for changing a registered email address

  • THEN show "bad link" message

• IF nonce IS known, BUT is outside the expiration time OR the change-registered-email-address process for that nonce IS complete:

  • THEN show "link no longer valid" message

(this could be written better, apologies, rushing as I'm under time pressure)

Q's that people might have:

• WHY send any email address to the currently-registered email address?

  • Answer:
    • IF that email address inbox IS valid and IS accessible, that means the user is proving identity
    • IF that email address IS NOT valid -- OR IS NOT accessible -- then the user needs to prove identity more than just knowing a password (or being a good guesser). Hence, the fallback is to call Customer Service
    • NOTE: Google thinks differently. Google merely sends a notification email message -- no click required to continue the process -- to the currently-registered email address -- with a link for "I didn't request this email address change". This is risky; as mentioned above, just knowing / guessing a user's password should not be enough proof of identity to change an email address.

• WHY require the user to click a link in an email sent to the requested-new email address?

  • Answer:
    • FIRST this proves the user has typed the requested-new email address correctly
    • SECOND this proves the user has access to the requested-new email address

[jmanico]

I like this general direction

[Zargath]

I suggest it be located in its own sheet. The primary email on a users account could not be used for authentication. Not to mention that the authentication sheet has more to so with the second part of the authentication. Ex. Secrets

A few things I would challenge are:

• The double link clicking by the user with the old and new email. This would cause a lot of user friction. I also feel the risk is relatively low with the active user session and current password/identity validation.
• A section should be added for when "customer support" or admin changes a users email address. How would this flow look and what notifications should be sent. Should they be allowed to change their own email?

I general, I think this would be a great addition and something I feel we don't have enough resources available for.

[jmanico]

Step three where the password or MFA check is needed is the most crucial step. I like this direction. Maybe you can add this under re-authentication?

[philCryoport]

@jmanico @Zargath thank you both for your feedback. Going to try to merge both of your suggestions here. Please respond to relevant questions?

1. Edouard proposes that this should be in its own sheet

Note

Jim, do you concur?

--

2. Jim's comment about using MFA to prove identity

• IF MFA is enabled
• AND IF the user proves identity via MFA when stating the proposed-new email address
• THEN that MFA is strong-enough proof that this is most-likely the actual user
• AND THUS the system sends the following email messages:
  • A notification-only email message to the currently-registered email address with a "click here if you didn't initiate this" link
  • A confirm-registered-email-address-change-by-link-click email message to the proposed-new email address
• AND IF that confirm-registered-email-address-change-by-link-click is clicked within the time expiration
• THEN the system changes the registered email address
• ...and then log the user out, forcing them to use the new email address with MFA
  (Jim I'm guessing this is what you mean by "Maybe you can add this under re-authentication?")

Note

Edouard, you ok with this particular process when MFA proves identity?

--

3. Separately: what if no MFA and only have a password as proof of identity?

• Edouard suggests that -- even with the risk of a guessed password / re-used password -- that the risk is low enough so that the process would be:
  • The user proves identity via typing in the current password when stating the proposed-new email address
  • The system then sends the following email messages:
    • A notification-only email message to the currently-registered email address with a "click here if you didn't initiate this" link
    • A confirm-registered-email-address-change-by-link-click email message to the proposed-new email address
  • AND IF that confirm-registered-email-address-change-by-link-click is clicked within the time expiration
  • THEN the system changes the registered email address
  • ...and then log the user out, forcing them to use the new email address

...instead of forcing user friction by requiring this non-MFA / password-only user to additionally prove identity by showing they have access to the currently-registered email address's inbox

Note

Jim do you concur with Edouard?

--

4. Documenting a process for the helpdesk / admin when handling requests from users to change the registered email address

Edouard wrote:

A section should be added for when "customer support" or admin changes a users email address. How would this flow look and what notifications should be sent. Should they be allowed to change their own email?

My take:

It depends on the system.

• My company is B2B: the repeat-external-users at my company belong to our clients. My company has phone numbers for higher-ups at our clients...so if a user contacts helpdesk or an admin and says "change my email address", we can verify with a pre-declared person in the client's leadership
  ...assuming we don't have somebody pulling a "The Secret of My Success" scam on us

• OTOH if the helpdesk / admin doesn't have this type of B2B relationship

  • THEN WHEN somebody contacts helpdesk / admin electronically (or by phone) and says "I need to change my registered email address and I don't have access to the current email address inbox", that requires social engineering protections -- which I think will require a massive cheat sheet all to its own

Note

Jim / Edouard, can we please write that AFTER this cheat sheet creation / update is completed?

[jmanico]

I think a relatively small update to the current authn cheat sheet will be enough!

[philCryoport]

I think a relatively small update to the current authn cheat sheet will be enough!

@Zargath you ok with that?

[Zargath]

Yes, I'm good with that.

[philCryoport]

PR merged, so closing this Issue