Bypassing Password Reuse Restriction A Security Flaw.

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 password change functionality was designed to enforce the following behaviours:

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.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.

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

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
}

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

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

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.

Surprisingly, the system:

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

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.

Server-Side Validation: The server must independently verify that the new password is different from the old one, regardless of client-side parameters.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