There is a convention to always prompt for the old password on the same page as the one where the old password is being changed as shown below.

Is it acceptable from a security perspective to allow a user to log in, and then change the password on a separate page that doesn't require the old password?

I'm asking because I'm trying to streamline a mobile application, and am considering making the standard web application have the same workflow.

Example of an "annoying" workflow for the user:

  1. User authenticates

  2. User is notified PW is expired or must be changed (immediately)

  3. User is directed to the screen below. The additional prompting for "current password" is annoying and I wonder what benefit it provides...

enter image description here

  • It seems pretty much time based to me. If the user was changed for their password in ~15 seconds ago, then the risk that someone stole their session or device seems pretty minimal. The longer the interval between the last password challenge and updating the password, the riskier it becomes.
    – Zoredache
    Feb 1, 2013 at 2:15

3 Answers 3


The reason you're made to enter your current password when you choose a new one is to ensure that the person doing the changing is the "real" account owner.

If you can directly change your password once logged in, the following attacks are possible:

  1. You walk away from your computer for a moment, I go to the website
    and change your password
  2. I steal your login cookies, load the website as you, and change your password

Edit: If you're suggesting the following sequence: Login using old password, then the next page immediately prompts for a new password, then you probably do have the same level of protection, assuming the "change" screen times out after some time.

I don't think it matters how many screens the process takes. I think the key is that the shorter the duration between when you can be sure the "real" owner interacted with the site, and when the password change request is issued, the greater the security.

Since you can set the elapsed time to zero by putting the old and new password fields on the same page, with (IMHO) little change in UX, that's probably why it's often done that way.


The goal of doing this is to prevent a user from walking away from the session, and an attacker taking control of the session and change the password on the user.

So if you think about it from an attack mitigation perspective, the attack is someone hopping onto an existing session and changing credentials. The mitigation is to require a point in time authentication before changing the credential.

In the mobile scenario, the theory is that the user will always have their phone with them, and the session likely won't be abandoned (long enough) for an attacker to do anything harmful.

However, in practice that doesn't really work because an attacker could theoretically convert a non-mobile session to a mobile session (e.g. hopping onto a desktop session, stealing the cookies, attaching the cookies to the mobile session) and bypass the point in time authentication check.

It's a trade off between feature/experience and security countermeasures. To get the second scenario to work securely you need to be confident (have mitigations for these attacks) an attacker can't convert the session or inject themselves into an existing mobile session.

  • What kind of mitigation would be sufficient? User-agent matching? Mar 18, 2016 at 18:38
  • Whoever can steal cookies and inject them into a different session would be able to easily fake user agent as well. Best way would be to simply apply differences to the cookies themselves, which differentiate a desktop and a mobile session. JWT has claims, that can be used for such, but if you generate the cookies in other ways, you can also encode the session type into them. Just make sure it is cryptographically secure, otherwise the attacker could just change that part of the cookies too. Mar 9, 2021 at 9:03

In my opinion, no, that wouldn't b acceptable. The reason is that a password change is a transactional event, and you need to verify hat the user changing the password is the user authorized to perform that transaction, and you authenticate them by confirming that they know the current password.

You must log in to answer this question.

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