# Vanguard Accepted a Password Reset, Then Rejected the Password

**Summary:** Tanin Na Nakorn reports that Vanguard's reset form silently cut his password to 20 characters while login submitted the full value. I would require an explicit length error and a successful next login before calling account recovery complete.

- Canonical: https://markhuang.ai/news/vanguard-password-reset-silent-cutoff
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-10-03
- Section: News
- Tags: Vanguard, Password Managers, Account Recovery, Web Security, Form Validation
- Source: [Tanin Na Nakorn](https://tanin.nanakorn.com/input-type-password-maxlength-20-is-considered-harmful-and-why-i-couldnt-login-into-vanguard/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![A row of glass password beads is interrupted by a narrow gate, leaving part of the credential outside a closed vault](https://cdn.markhuang.ai/news/vanguard-password-reset-silent-cutoff/hero.webp)

*A conceptual illustration of the reported failure: the reset form accepts a shortened credential while its owner keeps the original.*

[Tanin Na Nakorn](https://tanin.nanakorn.com/about/)'s [October 2, 2026 account of trouble logging into Vanguard](https://tanin.nanakorn.com/input-type-password-maxlength-20-is-considered-harmful-and-why-i-couldnt-login-into-vanguard/) describes a password reset that succeeded and still left him unable to log in with the password he had copied. His diagnosis was a mismatch between forms: the reset page's password fields had a 20-character limit, while the login page did not apply that same limit.

The success message bothers me more than the small limit. After a reset, I expect the password I chose to work at the next login. In the flow Na Nakorn describes, the form silently changed what he pasted, then reported success. The login page then reported an incorrect password, leaving him to figure out that the reset had submitted a different value.

This is his report about his account's web flow. It does not establish how many accounts are affected or whether Vanguard has since changed the forms. It does give developers a specific failure to look for: two password fields can agree with each other while both disagree with the password their owner saved.

## Both confirmation fields can be wrong together

Na Nakorn says he used 1Password to generate a password longer than 20 characters, then copied and pasted it into both the new-password and confirmation fields. Chrome limited the pasted input to the field's `maxlength`. The two shortened values matched, and the reset succeeded. At login, he pasted the full password into a field without that limit and received an incorrect-password response.

[MDN's password-input documentation](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/password) describes `maxlength` as the maximum input length, measured in UTF-16 code units. A field without the attribute has no maximum imposed by that attribute. That fits Na Nakorn's explanation of why the two forms received different values. It tells us nothing about how Vanguard stores passwords.

```mermaid

flowchart TD
    A[Original password longer than 20 characters] --> B[Paste into reset and confirmation fields]
    B --> C[Both fields keep shortened values]
    C --> D[Reset reports success]
    A --> E[Paste original password into login field]
    D --> E
    E --> F[Login submits the full value]
    F --> G[Incorrect-password response]
```

The diagram follows his reported sequence. An HTML attribute does not reveal Vanguard's hashing algorithm or establish that it stores passwords in plaintext. Na Nakorn also says he could sign in by scanning a QR code with the mobile app, but that is a separate route into the account. It does not show whether the app accepts longer passwords.

## A sensible limit still needs an honest rejection

The [Hacker News discussion of the post](https://news.ycombinator.com/item?id=49939773) has a useful disagreement. Some commenters question why a generated password needs to be so long. Others defend an upper bound on input while criticizing this limit and how the form communicates it. I agree that a service needs to control the input it processes. I do not think that answers the complaint.

The [OWASP Authentication Cheat Sheet](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md) recommends a maximum password length of at least 64 characters to accommodate passphrases. It also notes that some hashing implementations can expose a service to denial of service from very long passwords. Those recommendations allow a practical bound. The same guide explicitly says not to silently truncate passwords and recommends allowing paste into authentication fields.

I do not need to settle how long his password should have been to see the problem. He chose one credential, kept it, and submitted it through a form that changed it. A visible rejection would have let him choose an accepted password and save that value. Silent truncation let him believe he had already done so.

I would prefer the form to preserve the pasted input and explain a length error before submission, with the server enforcing the same policy. Removing `maxlength` alone would not establish that consistency. Creation, reset, and login need to apply the same policy to the password the user actually entered.

## I would test the login after the reset

If I were reviewing this flow, I would include the next login in the checks for account recovery. Stopping at the success screen would miss the failure Na Nakorn describes. The password the user chose and saved needs to work through the ordinary login path afterward.

That means checking pasted input around the documented length boundary, including a value just over it. The over-limit attempt should produce an explicit refusal rather than a successful reset with a shortened password. Password-manager autofill also deserves its own check; I would not assume it behaves exactly like paste. These are proposed checks. I have not run them against Vanguard.

For an account holder facing this symptom, I would check the site's stated password requirements before repeating the reset. If the chosen value exceeds an advertised limit, generate a fresh password within that policy, save it in the password manager, and confirm that it works at the next login. If the mismatch persists, contact support. The user should not have to edit the page or guess which part of a credential survived.

I raised a related concern in [my analysis of passkey custody and recovery](https://markhuang.ai/news/passkeys-stop-password-phishing-key-custody): people need to know how they get back into an account when the expected login route fails. For this case, my expectation is simpler. When a password reset says it worked, the password its owner kept should be the one that works.