I tried changing my bank password to a 27-character password generated by my password manager, but the site rejected it and said the maximum was 16 characters. Shortening it worked, so this does not appear to be a copy-and-paste issue.
Is there a technical or regulatory reason banks still impose this limit, and should I use a random 16-character password or handle this another way without weakening the account?
There’s no good security reason for a 16-character maximum. It’s usually a legacy system or database limitation, not a regulatory requirement. Use a unique, randomly generated 16-character password and store it in a free password manager like Bitwarden. That is still extremely strong, especially with the bank’s multifactor authentication enabled.
The 16-character limit does not necessarily mean the bank stores passwords in a 16-character database field. It may be an old authentication layer, but you cannot tell from the limit alone whether the password is being hashed properly.
@jeff is right that a random 16-character password is plenty strong. The bigger practical concern is whether the bank handles it consistently. Use exactly 16 characters, avoid unusual Unicode characters unless the site explicitly supports them, and test the new password by signing out and back in before relying on it.
Keep it unique to that bank and enable the strongest second factor offered. An authenticator app or security key is preferable to SMS when available.
The hidden risk is that another part of the bank’s system may silently truncate the password instead of rejecting it. The website might accept 16 characters, while the mobile app, phone support system, or an older login screen processes fewer. That kind of inconsistency is more concerning than the limit itself.
@jeff is right that 16 truly random characters provide plenty of strength, but the limit still points to legacy design or compatibility constraints. It does not prove poor storage, though it is fair to expect a bank to modernize its authentication stack.
Set Bitwarden to generate exactly 16 characters, stick to characters the site clearly accepts, and verify the result on both the website and app. If the bank offers passkeys, hardware keys, or app-based two-factor authentication, those matter more in practice than extending an already-random password from 16 to 27 characters.
If the bank’s account-recovery process can bypass the password through email, SMS, or phone support, then the difference between 16 and 27 characters is probably not the weak point that deserves the most attention.
The limit is still outdated. My cautious guess would be that the bank has several systems sharing the same credentials: the website, mobile app, older account software, fraud tools, and possibly telephone banking. Increasing the field on the visible website may be easy, but the bank has to confirm that every system handles the longer value correctly. Institutions tend to leave restrictive rules alone rather than risk locking customers out during a migration. That explains the limit, though it does not excuse keeping it forever.
I agree with @foxking that the limit alone tells us very little about storage. A properly designed system can reject anything over 16 characters and still hash accepted passwords correctly. A badly designed system can accept 100 characters and mishandle them. The size of the input box is not an audit of what happens behind it.
A unique, manager-generated 16-character password is a reasonable response, but I would check the surrounding security too. Make sure the email account used for recovery has its own strong password and MFA. Review which phone number the bank has on file, save any recovery codes somewhere protected, and turn on alerts for password changes, transfers, new payees, and contact-detail changes. Those controls may catch or prevent attacks that a longer password would not.
I would be reluctant to experiment with unsupported characters just to squeeze more variety into the allowed length. Use the full 16 characters, stick to the character set the bank documents or clearly accepts, and confirm that the password works after a complete logout. Then test the app separately if you use it. If either channel treats the same password differently, report that to the bank, because inconsistent processing is a much more concrete warning sign than the 16-character cap by itself.
Do not replace the rejected 27-character password with a “clever” 16-character phrase you can remember. Let the password manager generate the full 16 characters. The site has already chosen an arbitrary ceiling. There is no prize for making the result easier to guess.
The limit probably comes from an old vendor requirement, an authentication component, or a compatibility rule carried forward during upgrades. It may have nothing to do with the database column. Banks buy plenty of software rather than building one neat login system, so a restriction can survive simply because changing it requires testing several expensive systems and nobody wants to own the resulting lockouts.
A random 16-character password is not the realistic weak point. Online guessing should be rate-limited, and offline cracking should be impractical if the bank stores passwords properly. Unfortunately, the length limit tells you nothing about either control.
Phishing is the more ordinary problem. A 27-character password entered into a convincing fake bank page is exactly as stolen as a 16-character password. Use the manager’s normal autofill feature rather than routinely copying the password by hand. If it refuses to recognize the site, stop and check where you are. That warning is more useful than the extra eleven characters would have been.
I would use a unique 16-character generated password, confirm that it works on the bank’s actual website and app, and leave it alone. If the bank accepts app-based MFA, a security key, or a passkey, enable the best option available. The limit is dated and mildly embarrassing, but it is not by itself evidence that the bank is storing passwords in plain text or trimming them to fit a tiny field.
Realistically, the bank is probably treating login as an account-fraud problem, not a password-strength contest. Unlike a password-manager vault, a bank can rate-limit attempts, flag unfamiliar devices, block transfers, and freeze suspicious activity. Those layers reduce the practical benefit of going from 16 random characters to 27.
That does not make the cap sensible. It mainly shows the difference between “adequate within this system” and “good modern password policy.” A 16-character ceiling would bother me much more on an encrypted vault, where the master password may be the main defense against offline cracking.
So I would accept a unique random 16-character password here, but I would not use the bank’s limit as a general standard. @stackhacker9150’s point about recovery and alerts matters because those controls are part of what makes the shorter password less consequential. The cap is still dated. It just is not automatically the biggest security problem on the account.
Skip the temptation to store the rejected 27-character version in your manager and then paste in a trimmed copy by hand. That’s how you end up with two entries for one bank and a login that fails half the time. Generate fresh at 16 and be done with it.
Here’s the thing nobody’s said plainly: at 16 truly random characters you’re already past the point where length matters. A full-set 16-char password sits somewhere around 100 bits of entropy, which no offline attack is chewing through in any human timeframe. Going to 27 doesn’t make you meaningfully safer, it just makes you feel safer. So the annoyance is real but the security gap is basically zero. @goldenadmin framing it as an account-fraud problem rather than a strength contest is the closest to how banks actually think, and I’d lean on that.
Where I’d push back a little is all the caution around unusual characters. It’s not wrong, but people read it and quietly drop to letters and digits only, which does cost you real entropy. Better move is to let the generator use symbols and just avoid the two or three the site chokes on, usually spaces or angle brackets. Bitwarden lets you toggle character types per generated password, so set it once for that bank and forget it. Test the login on the app too before you trust it, since @serg_ux’s silent-truncation worry is the one genuinely scary scenario here. If the app and site disagree on the same password, that’s your signal something’s mishandled, not the 16-char cap itself.
If the bank’s login field blocks pasting, everything above changes, because then a 16-character random string stops being convenient and starts being a chore you’ll be tempted to shorten. Some banks still do this, usually the same ones clinging to a 16-char cap. Check that first. If paste and autofill both work, generate the full 16 and move on. If they don’t, that’s a bigger daily-use problem than the missing eleven characters, and it’s worth a complaint to the bank.
I’m with @novabyte5997 that at 16 random characters you’re done arguing about length, but I’d sharpen one thing. The entropy math only holds if the generator is actually using a wide character set. People hear ‘avoid weird symbols’ and quietly flip their generator down to letters and numbers, which drops you well below that comfortable margin. Keep symbols on, just prune the two or three the site rejects. The tool that keeps getting named here handles per-site symbol toggles fine, so set it once and forget it.
The truncation worry from @serg_ux is the only part I’d actually lose sleep over, and it’s easy to test. After you set the password, log out and back in on the website, then do the exact same thing in the app. If one channel accepts a password the other rejects, or worse, both accept it but you’re not sure why, you’ve found real evidence of mishandling. That’s a report-it moment. The 16-character cap on its own is just dated housekeeping.