# Password Reset Flaws > 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. - Skill: `shulkwisec/password-reset-flaws` (Agent Skill) - Install (CLI): `npx skillmds add shulkwisec/password-reset-flaws` - Raw SKILL.md: https://api.skillmd.com/api/skills/shulkwisec/password-reset-flaws/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - License: MIT - Author: ShulkwiSEC (https://skillmd.com/u/shulkwisec) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/shulkwisec/password-reset-flaws --- # 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 1. **CSRF check on reset form**: Capture reset/change request; remove or replay CSRF token; confirm if server accepts. 2. **Cross-user modification**: On password change endpoint, swap the `user=`, `username=`, or `account=` parameter to a different account while authenticated as another user. 3. **Token analysis**: Request multiple reset tokens; compare for patterns (sequential integers, Unix timestamps, MD5 of email+time). 4. **Token lifetime**: Use a reset token after 1 hour, 24 hours, 1 week; note if still valid. 5. **Plaintext password detection**: Trigger "forgot password" flow; if response contains the actual current password, storage is reversible. 6. **Missing current-password gate**: Submit password change request without `currentPassword` field or with an incorrect value; observe if accepted. 7. **Workflow manipulation**: Intercept multi-step reset flow; skip steps or replay confirmation tokens against a different account. 8. **Password policy audit**: Test minimum/maximum length, character class requirements, common password blocking, history enforcement. ## Payloads & Tools ```bash # 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' 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]].