ASVS V6.2.2 requires that users can change their password. It is a Level 1 requirement, and it is short because the failure is simple: an application with no change function leaves people with no way to respond to a suspected leak.
Why it matters
Users learn about breaches from news and from notification emails. The first thing they want is to rotate the credential. If the only route is a support ticket, many will not bother.
There is also a quiet benefit. Users who can rotate easily after a scare are more likely to do it, and every rotation after a breach cuts the useful life of stolen data. Make the option easy to find, not buried three screens deep.
How to implement it
Offer a change option in account settings. Pair it with the rules in V6.2.3 (ask for the current password) and the same strength checks used at registration. After a successful change, end other sessions and notify the user.
def change_password(user, current, new):
if not verify(user.hash, current):
raise AuthError("Current password is incorrect")
check_policy(new) # length, breached list
user.hash = hash_password(new)
revoke_other_sessions(user)
send_notice(user, "Your password was changed")
How to test it
Sign in, change the password, then confirm the old one fails, the new one works, and a second browser session is signed out. Check that a notice email arrived.
Also test the unhappy path. Submit a change with the wrong current password, a weak new password and a reused old password, and confirm each is refused with a clear message and no partial update.
Common mistakes
-
No change option for SSO fallback accounts.
-
Leaving old sessions alive.
-
Silently succeeding without a notification.
-
Hiding the option for users who sign in with a social provider but also hold a local password.
Quick check
What should happen to other sessions after a change?
They should be revoked. Otherwise an attacker who already has a session keeps access.
