ASVS 5.0 V7.5.1 (Level 2) requires full reauthentication before the application allows changes to sensitive account attributes that can affect authentication, such as the email address, phone number, MFA configuration, or any information used in account recovery.
Why it matters
A valid session is not proof that the legitimate owner is at the keyboard. It might be a hijacked cookie, an unlocked laptop or a malicious browser extension. If a session alone can change the recovery email, an attacker turns a temporary foothold into permanent ownership: change the email, trigger a reset, and the real user is locked out.
Reauthentication puts a checkpoint exactly where the damage becomes durable.
How to implement it
Track when the user last proved who they are, and require that proof to be recent for protected actions.
from datetime import datetime, timedelta
REAUTH_WINDOW = timedelta(minutes=5)
def require_recent_auth(session):
last = session.get("last_auth_at")
if not last or datetime.utcnow() - last > REAUTH_WINDOW:
raise ReauthRequired() # handler redirects to a password and MFA prompt
@app.post("/account/email")
def change_email(req, session=Depends(get_session)):
require_recent_auth(session)
...
On the reauthentication prompt, verify the password and, where the account has MFA, a second factor. Then update last_auth_at and rotate the session token (see V7.2.4). A confirmation click that only checks the existing cookie does not count.
Apply the check to:
- Email and phone changes.
- Adding, removing or resetting MFA devices.
- Changing recovery questions, backup codes or trusted devices.
- Linking or unlinking a federated identity provider.
- Password changes.
Also notify the old email or phone about the change, with a way to report it. Delay the activation of a new recovery contact where your risk policy supports it.
For SSO users, ask the identity provider for a fresh authentication, using the max_age or equivalent parameter, and check the auth_time claim in the response.
How to test it
- Sign in and wait past the reauthentication window. Try to change the email through the interface and expect a prompt.
- Call the underlying API directly with the stale session. It must also refuse, since the UI is not the control.
- Complete the reauthentication and confirm the change succeeds exactly once.
- Try with a session created by "remember me" and confirm the prompt still appears.
- Check that the notification email arrives at the old address.
Common mistakes
- Enforcing the check in the user interface only.
- A reauthentication window measured in hours, which is just a long session.
- Accepting the password but skipping MFA for a user who has it.
- Forgetting secondary paths such as a mobile API or a support tool.
- Protecting the email field but not the "add a backup phone" field.
Quick check
Is a confirmation dialog the same as reauthentication?
No. A dialog proves the user clicked. Reauthentication proves the user knows a credential.
