At least not 20 characters. My generated password isn't insane. It is 4 words with delimiters, so the length varies between 20-28 characters.

> I guess I don’t really understand the reasons any engineering team would limit password length

The bcrypt hashing algorithm doesn't work on inputs above ~60* characters or so. It will just silently trim your input. Better to do it yourself

*72 bytes

Well, in the USA as it is, they are already accountable under Reg E for any fraud losses due to a failure of an "access device" aka password. I'm not sure what else you would want.

> they make this as difficult as possible to do.

They provided password requirements which he ignored.

> Finance needs to be held accountable.

Accountable for what, exactly?

And if someone gets into your account and robs you, that's your problem too!

TFA says the mobile app works (so presumably the backend accepts long passwords fine). Looks like it's just a frontend issue. I wonder if deleting the maxlength attribute before submitting the form works fine?

bcrypt famously only looks at the first 72 bytes of the input. There are ways around that - don't use bcrypt, or do bcrypt(sha256(password)), or whatever, but it is not the case that "just feed the input to the hash" removes all length restrictions

    CREATE TABLE passwords (
      email VARCHAR(MAX),
      password VARCHAR(20) UNIQUE -- unique passwords are more secure.
        -- NOTE: "20" here because we used to use SHA1 hashes
        -- but there was an issue with storing binary in CP437
        -- so we just renamed the field.
    )

At some point you don't want people to enter the bee movie script, but where the word "bee" was replaced with the entire bee movie script again, recursively three times, all into the password field and tie up servers with extremely long requests.

But 20 characters is simply ridiculous.

It's a good habit to always create an upper bound on things (input max length, queue size, etc).

The person who wrote it just came up with 20 in the moment and forgot to go check, something everyone has done a hundred times.

I've probably never worked on a single system where the html validation, http server validation, and database constraint were synchronized on username max length. You choose a placeholder, an even number between 10 and 16, then forget to ever check.

It had to be restricted after someone started using a complete Wikipedia database dump as a password.

Are you looking for the technical reason or the political one?

You are right about high entropy short-ish passwords but almost nobody does that. Virtually everybody chooses something not just low entropy but often easily crackable with good search heuristics. Why not give people another way to produce passwords that are harder to crack? With luck, at least a few people will choose a correct-horse-battery-staple.

It costs me nothing to use a 20+ character password. The questions isn't why should you, the question should be "why shouldn't you?"

https://xkcd.com/936/

> For the Americans who might not be aware of what BMO is

Maybe news hasn't traveled north and broadcast on the CBC, so maybe you haven't heard, but BMO has branches all over the US.

I mean that could still be encrypted. But passwords should never be reversible. It should be hashed with scrypt or apparently now Argon2id.

Can you elaborate how this sanitizes input on a password field? What unsanitary password input does it prevent?

I think statement from TFA basically boils down to "stop enforcing maxlengths on passwords, neither in the form field nor the DB". I'm no security expert but I'm a `correct horse battery staple`-adherent so if anything, password fields should have a minimum length, not maximum. Short passwords should be what's considered dirty.

[dead]

One of my most favorite things in the world was when an org with an outdated security program told me we'd have to rotate our passwords monthly. Then I'd get to tell them that no, we wouldn't, and due to modern security practices, we couldn't without causing a compliance exception.

Sometimes I ended up explaining that to a well-meaning but overworked person who just wasn't aware of the "new" (cough 2017) standard, but they'd ask me for the citation and giggle gleefully, thrilled that they could show their boss that they could knock off that obsolete ritual.

Sometimes I ended up with someone a little smug, because they were at a megacorp and I wasn't, and you'd see the momentary flicker of surprise and uncertainty as they started to wonder if maybe they'd missed something, something very important. I took an unreasonable amount of joy from those interactions.

Don't forget blocking paste!

It baffles me why so many sites block paste on bank account number inputs like it is 1995 and we are typing it from checks.

There's an inherent insularity to security groups or fraud teams; they have to have a professional suspicion of everything. This can go wrong and end up being NIH or gratuitously customer-unfriendly.

Also, for finance specifically : " A sound banker, alas, is not one who foresees danger and avoids it, but one who, when he is ruined, is ruined in a conventional way along with his fellows, so that no one can really blame him." - Keynes

Don't be so hard on them. Their COBOL program is probably limited to 80 character records, so they'll fit on a punched card.

+1, plus Ticketmaster for some reason.

I think they use some cursed (or secure I guess) combo of stringent special character requirements, no reuse of old passwords, and automatic resets after incorrect guesses.

It actually hasn’t been an issue after finally using a password manager, but I remember it being a regular headache before that.

Fear of the Compliance monster.

Compliance over action.

Ass covering instead of responsibility.

Security theatre, in other words.

When the consequences for failure are very high but personal reward for success is very low, everyone does everything they can to avoid being held responsible for the consequences.

Note that I didn’t write “avoid consequences”!

That’s different.

In Argentina our password is called username, it gets the password treatment, but the UIs call it login.

I think it has to do with the fact that Banks are heavily driven by nation law and regulation, so it's not engineering folk that are at the helm, rather it's driven by natural language source code written by non technical people that compiles to target code through engineering lackeys. It works for the most part, but you get very weird failure modes.

Probably PCI and other regulations making it difficult to use and thus learn good software, so they develop entire ecosystems in-house

Don't get me started on passkeys, where it seems it was made for people who literally only use one device: their phone.

Every time I prodded for a passkey I have to run a grep in my brain, what app did I use, or what it an extension, under my personal or work email?

A NIGHTMARE, and for what.

I commented elsewhere in this thread about how a major Canadian bank used to require exactly 6 character passwords. Makes me think some of these finance industry dinoaurs had (have?) some of the same ancient back-end systems where they're storing it.

Their website isn't great (and the new modern one is worse, IMHO), but it doesn't seem significantly harder to sell there than any of the other brokerages I've used. But I haven't used any of the new school party brokerages with confetti effects and whatever.

It's way better than doing anything with computershare.

This would be funny if it were true, but the buy/sell/exchange is right by each asset listing.

Sorry, your password must not contain characters other than “a”. Also there is a 6 character limit.

The why is people who don't actually understand security but once took a class that taught them about SQL injection and used that to parlay themselves into a role that weren't qualified for as a "security expert". That's the basic why.

[flagged]