Bypassing Password Reuse Restriction A Security Flaw.

Let’s Flow into the article🙂

When testing a password change functionality, I encountered an interesting feature implementation and discovered a potential vulnerability. Here’s a breakdown of what happened-

The Scenario

The password change functionality was designed to enforce the following behaviours:

1. Password Update Allowed: Changing the password from Admin@123 to Admin@1234 was successful. After the change, the system forced a logout and redirected to the login page.
2. Password Reuse Restriction: If the current password (Admin@123) was reused as the new password, the system displayed an error: "You cannot use your previous password." This behaviour is a standard security feature to prevent password reuse.

The Experiment

Curious about the implementation, I decided to analyze the password change request using Burp Suite, a popular web application testing tool.

Step 1: Capturing the Request

I intercepted the password change request where both the old and new passwords were set as Admin@123. The captured POST request body contained the following parameters:

{
  "oldPassword": "Admin@123",
  "password": "Admin@123",
  "mustBediffrent": true
}

Step 2: Identifying the Key Parameter

The mustBediffrent parameter caught my attention. This Boolean value (true) appeared to enforce the restriction against password reuse.

The Exploit

Step 3: Modifying the Request

I altered the mustBediffrent parameter's value from true to false and forwarded the modified request to the server.

Step 4: Handling the Response

Upon sending the modified request, the server responded with a 400 Bad Request. I intercepted this response and manually changed the status code to 200 OK, then forwarded it to the client.

Step 5: Observing the Outcome

Surprisingly, the system:

1. Accepted the Previously Used Password: Despite the restriction, the password change request was successful.
2. Forced Logout: The system logged me out and redirected me to the login page.
3. Allowed Login with the Same Password: After logging in, I could successfully use the previous password (Admin@123) without any issues.

Insights and Takeaways

Key Observations

• The mustBediffrent parameter directly dictated whether the password reuse check was enforced.
• Modifying the server’s response from 400 Bad Request to 200 OK bypassed the application's validation logic.

Security Implications

This behaviour highlights a critical vulnerability: client-side trust. The application relied on parameters from the client-side request without adequately validating them server-side. Additionally, the server’s failure to handle tampered responses exposed a weak point.

Recommendations

1. Server-Side Validation: The server must independently verify that the new password is different from the old one, regardless of client-side parameters.
2. Strict Response Handling: The application should ensure that tampered responses (e.g., changing 400 to 200) do not lead to unintended behaviour.

Thanks For Reading.

Linkedin — https://www.linkedin.com/in/aman-hasan/

X — https://x.com/Aman_Hasan01