My webapp has "password reset" and "password change" functionality.

Password "reset" is typical: user clicks "I forgot my password", enters his email, one-time link emailed there, he visits a form to choose a new password.

Password "change" is more complicated. There are two approaches:

  1. Some sites use a one-step process: user logs in, clicks "change password", enters old password, chooses new password.
  2. Other sites use a two-step process with an email loop: user logs in (HTTPS), clicks "change password", link mailed to his email, he visits a form that asks for a new password. His current password is not requested. This is done (possibly) without even logging in!

These two are very similar, but there are tradeoffs.

Option (1) is simpler. BUT, if the user's device is stolen (or let's say he just steps away from his desk for some coffee), and he uses a browser with a password manager, then the attacker doesn't need to know the password.

Option (2) doesn't even ask for his current password, because it verifies him via email. BUT, if the attacker has his device, then he probably has access to the email anyway. And if I ask for the current password, and a password manager is installed, then the email loop accomplishes nothing anyway.

Also the "reset" workflow is so easy to use, that if I over-engineer the "change" workflow then the user (and an attacker) could use the reset form instead.

So it seems to me that this is not a security problem, but an UX problem only. The two-step "feels" more secure, but I think that is an illusion.

Which is better for security (rather than UX)? Are there considerations I've neglected?

3 Answers 3


The problem that I see with your question is that both the threats that you talk about in option (1) and option(2) are the threats where an attacker has physical access to your system .When you are developing a web application these are not the threats you should be worried about.

Always remember:-

If an attacker has physical access to your device it is not your device anymore.

If an attacker has physical access why would an attacker try and change passwords at all? Why wouldn't the attacker just backdoor you instead of wasting time on changing passwords?

Now when it comes to password change/reset. Both the work flow that you wrote of are secure in and of itself. The threat arises only in weaknesses of the implementation. For example, in the case of:

  1. The attacker here would have to not only login but also know the old password, or
  2. The attacker here would have to compromise your email account.

In both cases it would be game over if it happened.

Just to emphasize my point

The workflow you wrote is secure IF it is implemented correctly without any additional vulnerabilities.

  • So your opinion is they are both equally secure or equally insecure? And one is not preferable to the other?
    – lonix
    Commented Aug 4, 2019 at 7:14
  • equally secure in its workflow
    – yeah_well
    Commented Aug 4, 2019 at 12:32
  • @VipulNair: "Its not you device anymore" - this does not necessarily means that an attacker can control the account, for instance, if user uses hardware token, the loosing smartphone, laptop or other device is not critical. Also if the system uses other authentication factor like fingerprint reader or video authentication, getting access to the device does not compromise the account.
    – mentallurg
    Commented Aug 4, 2019 at 15:47

To "Option (2) doesn't even ask for his current password": I don't understand how can it be. To request password change, user has to log in into his profile. For this a password is required. May be you mean that user doesn't use master password in the password manager and effectively log in without entering any password. If this is your case, then you are right saying "but I think that is an illusion".

What should you consider?

Use multi-factor authentication. A popular 2-factor authentication is based on a password (what user knows) and on the usage of the smartphone (what user possesses). Usage of smartphone can vary: this can be SMS, push notifications that request confirmation, OTP generator, photo-TAN. Smartphone should secured, via PIN or fingerprint or face-ID.

Actually you do have 2-factor authentication. But if user compromises it (by not using password or by not caring about locking the smartphone), it is useless.

Instead of one of these factors you can use hardware token like Google Titan or Yubikey, e.g. [password + hardware token] or [smartphone + hardware] token. But again, if user does not care about the token, he is not in safety.

When choosing the solution, compare the price of compromising user account with the price of implementing a particular security. If you are developing a web site for local bowling club, may be simple 1-factor password authentication is sufficient. If you are developing an online banking application, then you may want to allow critical operations like password change only after user is authenticated by service desk via video. Compare price and value.

  • Regarding the not asking for password: he is not asked for his password after clicking the link in his email. The "step 2" of the two-step process :)
    – lonix
    Commented Aug 4, 2019 at 15:45
  • OK. But now you see what options you can consider :)
    – mentallurg
    Commented Aug 4, 2019 at 15:49

As highlighted by @lonix the Password Reset workflow and Password Change workflow are similar and do have intersections but they must be well segregated on execution level. Hackers are interested in grabbing credentials and any bug/loophole in the credential handling process will be exploited for sure. As we have seen additional information about the login process must be captured with likes of location based access control and verification of last reset. Also some sensitive SaaS applications give limited functionality of application operation till a specific time period after a password reset has occurred.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .