When changing a password using a WebPage, must the old password be entered on the same screen?

Question

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...

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

When using javascript based encryption (when SSL is not an option, or as an extra layer of security), the old password could be used to construct an encryption key for the new password.