Changing password: Verify with old password, verify by email, or don't verify?

Question

Scenario

I want to change my password.

I have access to my account, this is not a forgotten password journey.

I've seen three approaches to this.

Method 1: Re-verify with old password

1. Log on
2. Navigate to my account panel
3. Choose "Change password" option
4. Enter my current password (verifying I know the account details)
5. Enter my new password
6. Submit, password is changed

This is probably the most common, and the most secure, as you have to verify immediately before changing the password.

If you gain access to someone else's account when they're already signed in (perhaps because they opted to save their log in details) you can't change their password.

Method 2: Re-verify by email

1. Log on
2. Navigate to my account panel
3. Choose "Change password" option, the system emails me a password reset link
4. Open email client and locate the message
5. Follow the link (verifying I have access to the email account)
6. Enter my new password
7. Submit, password is changed

This is easiest for users who have quick access to their email on their device. Presuming you have email set up in a local email client, you open the client, open the most recent email, and follow the link, skipping the "enter current password" step. You might even get a push notification, which would make this even faster.

However this is probably slowest for users who don't have quick access to their email.

Method 3: Don't re-verify

1. Log on (verifying I know the account details)
2. Navigate to my account panel
3. Choose "Change password" option
4. Enter my new password
5. Submit, password is changed

This is the quickest method, with the lowest interaction cost.

Arguably the user is already logged in, and therefore verified, so shouldn't need to reverify.

This assumes scenarios where an unauthorised user has gained access to the account panel are too rare to justify complicating the process.

Weighing up the options

Is there anything I've not considered?

I'd like to go with option 3, but the fact it's so rarely seen makes me think there's something I'm missing.

If it was only between options 1 and 2, I suppose I'd go with option 1, since we can't know if the email is readily accessible.

Answer 1

There is an intrinsic conflict in this question. UX attempts to remove hurdles from the user; to make things easier.

Security exists to prevent unauthorized access to information and it must deal with all contingencies raised by bad actors.

The UX, even for the most secure of networks, will start by making the process of changing passwords as clear as possible. Users should be able to easily find where to start the password changing process and have the steps clearly explained.

(Even if the process is arduous and time consuming:

You cannot change passwords online.
To change your password you need to:

1. Go to ...
2. Get ...
3. Do ...

Assuming that you're not securing nuclear launch codes the question is how to balance security and ease of use.

The security requirements must be met and unauthorized use of logged in account must be taken into consideration.

Method 1 verifies that user of that account knows the password.

Method 2 forces a two-factor authentication. Not only must the user know the account but he must have access to another user account as well.

Method 3, as you can see, is open to all sorts of fraud. It may be useful in a few situations.

Example: Access to an intranet that can only be reached if the client is within the local network AND the user has read-only access AND the data is of minimal value (meaning that dissemination of said data will produce minimal harm).

TL/DR - Security of data comes first. When those requirements are met you can concern yourself with the UX.

As an aside - I would be more concerned with making certain that the password requirements are useful. For instance allow people to use all lower case but then increase the minimum set of characters - from (say 12) to (say 24).

Answer 2

So, something I didn't see mentioned in the answer above (excellent as it may be) is the actual security purpose of the methods requiring additional user input.

Consider the case of a web app that has a vulnerability that allows arbitrary JavaScript to be executed (this type of vulnerability actually shows up a lot). If there is no need to re-verify a password/email - something that should not be exposed on the page, by design - then malicious code may be able to reset the user's password and send the new one to the attacker's server, all without the user knowing anything happened.

The extra step is not only verifying the user's knowledge of his/her account (as well as another account in the case of email verification), but it's also minimizing the damage of potential exploits, because no malicious code should be able to scrape your password or email from the page.

Web apps are not the only programs subject to this problem. Native apps have been known to expose very similar vulnerabilities due to programming errors. Nothing is bug free, so it pays to be paranoid.