I am developing an ASP.NET Core web application with user management functionalities. My question is about the email address changing algorithm. Almost every web app I saw before have the following flow:

1. User authorized
2. User requested an email address change
3. User received a message on the new mailbox with the confirmation link
4. User clicks the link and the email address updates

But I think, this algorithm might be a bit insecure and that is what I want to discuss here.

How about this flow:

1. User authorized
2. User requested an email address change
3. User received a message on the old mailbox with the confirmation link
4. User received a message on the new mailbox with the second confirmation link
5. User clicks the link and the email address updates

With this additional step in the middle of the algorithm, things may be much better from the security perspective, but would it be too complex or not? How do you think what algorithm I should implement? And what would you prefer if you will be in my shoes?

CodePudding user response：

The second options might sound great, and it's not too much headache to implement too. But I'll stick with the first approach due to some reason:

Common work flow pattern.

As the backend side can be wrote by many language, by various developers, so common pattern would make things more standard when we need some kind of migration, and even maintaining by new developer. If the project doesn't require ultra-secure authentication flow, the simplicity of first approach was enough.

From user convinient pespertive

Let's just imagine when changing an email address, what case the user likely want to change email address ? I was register my facebook account long ago using yahoo mail, that's no-longer active, and i need to switch to a gmail one. What's the point of sending the email back to the old one ? Cumbersome... and i can do nothing in this case except get some help from the staff.

I totally aggree with the second approach on security angle. But that's not suitable for most of the case, only implement if the project have some requirement. And even in that case, I suggest don't even do that too, build some thing like sub-admin account role and grant permission to someone have responsible. Like Google enterprise email organize some account called admin if anything wrong happen to user account. As long as it has this kind of security level requirement, it's not gonna serve massively user.

The intension of all the flow

The User got authorized first, right, that's mean we Identified what the user are, and what she capable to do. Imagine when we hide a hotel room then request to change to another due to some reason. What's the point of proving that's I booked my own room, since we all know that's the fact ? Kinda weird... right ?

To conclusion, I think we shouldn't mess with something that's become common pattern that widely acknowledged, except we have some special requirements and the project have something uniquely to satisfy, and we consider ourself, as developer that's reasonable.

CodePudding user response：

The main problem with this approach is: what happens if the user no longer has access to their original email account? Perhaps it was a work/school/uni account that they no longer have, or perhaps they've just forgotten their password or otherwise lost access to it.

With your second approach, they are not going to be able to update to the new account, because they'll never receive the first confirmation link.

How about the following approach instead:

1. User requests an email change.
2. Require the user to re-authenticate with their current password (just like when they change their password).
3. Send a confirmation link to their new email.
4. Send a notification to their old email, with the details of the change, and instructions of what to do if they didn't initiate the change.
5. User clicks the link to update or contacts your support to say their account has been compromised.

This way you still provide them with an alert that someone is trying to change their email (and potentially a means to stop it), but a user who has lost access to their old account will still be able to update their email.