Disclaimer: The techniques described in this post are intended for educational purposes only, and specific details have been intentionally omitted.
These methods should only be used on systems you own, manage, or have explicit permission to access. Unauthorized access to computer systems is illegal and unethical. Always obtain proper authorization before performing intrusive or manipulative actions on a web application. I assume no responsibility for any misuse of the information provided!
Background
Recently, as part of my client’s periodic password change activities, they encountered a problem where the Password field on the web interface’s login screen supported fewer characters than what the password was set to, locking them out of the device.
To make matters worse (for reasons I can’t get into here), the web browser and a text editor were the only tools available to investigate, troubleshoot, and bypass the interface’s limitations.
Investigation and Troubleshooting
Using the web browser’s Developer Tools, I was able to inspect the Password input field to better understand what was happening:
<input name="pass" type="Password" size="16" maxlength="16" value="">
Looking at the last password vault entry, I saw that the password was 29 characters long, so I tried entering the same password truncated to 16 characters, but it wasn’t accepted.
Luckily, there were other identical devices in the environment, so I logged into another one and inspected the Change Password field on a hunch. Sure enough, it was longer!
<input name="passChange" type="Password" size="20" maxlength="20" value="***">
This told me that when the password was changed, it was truncated to 20 characters, not 16!
Getting Warmer…
Now that I had a clear[er] understanding of the problem and the correct password, I tried to manipulate the client-side HTTP by increasing the size and maxlength values to 20, but encountered server-side code calling a form validation function, preventing me from submitting password greater than 16 characters:
if (pass.value.length > 16) err.addError (pass, "Invalid or Missing Password");
err.showError();
return !err.hasError();
In order to get around the script, I tried bypassing the form using the browser’s console to manually set the user name and password and then submit the form without clicking on the submit button, triggering the validation function:
document.getElementsByName("user")[0].value = "[myUsername]";
document.getElementsByName("pwd")[0].value = "[myTruncatedPassword]";
document.forms["[myLogonForm]"].submit();
…and…
It Worked!
This got me back into the device, so I first navigated to the password change setting and reset it to an acceptable length, then verified that I could get back in using the new password.
Lastly, I wrote a detailed summary for the client to share with the device’s manufacturer so [hopefully] they’ll update future revisions to use consistent password lengths.