Rendered at 13:20:53 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
Sohcahtoa82 14 hours ago [-]
I got bit by a similar issue with another service.
I could log into the website just fine, but the app kept saying my password was wrong. I reset my password, and when I was generating a new password, I found the root cause:
At some point, they changed the password policy to have a maximum length of 16 characters. My existing 20 character password worked fine in the website which didn't actually enforce a 20-character limit in the password field, but the app was silently truncating the last 4 characters when BitWarden was filling in the field.
Limiting password length to only 16 characters scares me. It makes me think they're not hashing passwords in the back end.
40four 11 hours ago [-]
I’ve ran into this same issue numerous times on different platforms. They silently enforce a max length, unannounced to you, then you can’t log in later until you figure out the correct length.
I guess I don’t really understand the reasons any engineering team would limit password length, but at least implement in a way that is apparent to the user. Successfully saving a password that is different than the user expects is wild.
Moreover, in the case of a financial institution like Vanguard, limiting password length feels particularly offensive.
tanin 11 hours ago [-]
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.
efilife 7 hours ago [-]
> 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
Atheros 7 hours ago [-]
In case any programmers read this, the better procedure, if you want to use bcrypt, is to hash the password with something else first, like SHA512, then feed the output into bcrypt.
efilife 6 hours ago [-]
what's the point in using bcrypt then? I researched this years ago and nothing ever convinced me it's not redundant
Atheros 6 hours ago [-]
to slow down attackers who want to brute force your password hash. At least that was the idea. I guess it also includes the salt stuff built in so that it's harder for implementers to screw up.
Is a 9-order-of-magnitude slow down worth the trouble? I dunno. Maybe.
vegetablepotpie 14 hours ago [-]
These are the same companies that state that users are responsible for choosing secure passwords… and then they make this as difficult as possible to do.
Finance needs to be held accountable. They’ve skim off far too much wealth for the value they produced.
alright2565 13 hours ago [-]
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.
sippingabonedry 14 hours ago [-]
> 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?
nemomarx 14 hours ago [-]
if the requirements make it less secure, isn't that the issue op is complaining about? max lengths are an anti feature.
sippingabonedry 14 hours ago [-]
Do you believe a 64-character password is magically more secure than a 20-character when they lockout your account after a few wrong tries? Delusion.
altermetax 14 hours ago [-]
Locking you out after a few wrong tries only protects against online attacks. If someone gets access to the database, they have as many attempts as they want.
phatfish 13 hours ago [-]
Brute force a strong 20 character password? Won't the sun have burnt out by the time that is done?
I use strong 12 character passwords at work, on the off chance i have to type them out. And as a favour to anyone else that might have to.
altermetax 9 hours ago [-]
Are there disadvantages in allowing users arbitrarily long passwords (or with a very high limit, e.g. 256 bytes)? No.
Are there advantages? Yes: the longer the password is, the stronger it is. It doesn't matter if there's a specific point after which cracking takes time till the death of the universe. So there's no point in imposing a limit.
Besides, too many websites limit password length to ridiculous lengths like 12.
sippingabonedry 8 hours ago [-]
You should reach out to the developers of all the major operating systems and explain how they've been doing it wrong all these years because they all set hard limits.
xigoi 6 hours ago [-]
For a 20-character password to be strong, you pretty much need to use random characters; you cannot use the superior “correct horse battery staple” approach as you’d be limited to two words, which isn’t very secure.
phatfish 15 minutes ago [-]
True, a pass phrase is a reasonable use of "passwords" >20 characters.
altruios 14 hours ago [-]
> 64-character password is magically more secure than a 20-character
Not magic there, just information theory. but yes, I hear what you are trying to say. It is more cumbersome.
yjftsjthsd-h 14 hours ago [-]
If an attacker compromises the server and gets hashes, yes it could matter.
sippingabonedry 13 hours ago [-]
Sure give or take a few million years.
A 20 character password is for all practical purposes mathematically immune to being brute forced.
Atheros 6 hours ago [-]
Allowing extremely long passwords makes everything more secure because it teaches users to use better passwords.
> They provided password requirements which he ignored.
No, you misunderstood what happened: "Chrome inputs only abcdefghijklmnopqrstu (20 characters) as shown below"
1Password generated a password longer than 20 characters. When pasted, Chrome silently truncates the paste to the input maxlength!
Look at the screenshot: The requirement "Between 8 to 20 characters long" has a green checkmark, because the requirement is satisfied.
techgnosis 14 hours ago [-]
And if someone gets into your account and robs you, that's your problem too!
14 hours ago [-]
bootlooped 14 hours ago [-]
My biggest question here is are they not just feeding the input into a hash function, why can't it be longer than 20 characters?
frenchtoast8 14 hours ago [-]
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?
arkadiyt 14 hours ago [-]
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
matja 13 hours ago [-]
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.
)
kstrauser 13 hours ago [-]
That just made me twitch so hard that I have a crick in my neck.
coaksford 14 hours ago [-]
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.
shermantanktop 14 hours ago [-]
<input type="password" maxbeemovierecursions="2">
hombre_fatal 14 hours ago [-]
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.
zetanor 14 hours ago [-]
It had to be restricted after someone started using a complete Wikipedia database dump as a password.
Sohcahtoa82 14 hours ago [-]
If your web server isn't throwing a 413 Content Too Large immediately after seeing a "Content-length: 20000000000" header, or bailing out after enough chunks from a "Transfer-Encoding: chunked" header, you configured it wrong.
jagged-chisel 12 hours ago [-]
But that upper limit has to indicated somewhere
margalabargala 14 hours ago [-]
Are you looking for the technical reason or the political one?
happyopossum 14 hours ago [-]
> Of course, my generated password is longer than 20 characters
Ok, yes - an undisclosed max length that doesn’t throw an error is horrible, *and this is entirely Vanguard’s fault* but what’s with the “of course”?
There’s virtually no reason to use a randomly generated password that long, and there have been more than enough stories, anecdotes etc about sites failing on long passwords that throwing an “of course” here is a little overboard.
A high entropy random password with 62+ potential characters before including “special characters” with a length of 16 characters is basically un-bruteforceable. It would take 4.6 billion years to brute force at 164.1 billion guesses per second, and vanguard (or anyone else) is gonna notice if you try the 4.77 × 10^28 possible combinations.
raddan 13 hours ago [-]
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.
malfist 13 hours ago [-]
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?"
doubletwoyou 12 hours ago [-]
1. For whatever reason, and a reason will come, typing out those extra characters will be an extra pain.
2. Stupid choices by services (like Vanguard!) making those extra characters a liability.
3. What are you protecting against? Even 16 characters with ~60 combinations is more than enough entropy.
4. It’s just cumbersome. And that, frankly, is the reason why the question is “why should you?”
tzs 11 hours ago [-]
> For whatever reason, and a reason will come, typing out those extra characters will be an extra pain.
The possibility of having to manually enter a password is actually why I used to want very long passwords to be allowed.
Say I have a streaming account, which I use from my desktop and maybe my phone or tablet. I never have to enter it manually on those devices because my password manager runs on all of them.
But then I want to use that service's streaming app on my TV. Nowadays most services have figured out a way for you to enter your credentials on their website or in the app on your phone or tablet and link that to your attempt to set it up on the TV, but back in the day most did not.
What we had to do back then is manually enter the password using the on-screen keyboard on the TV, navigated using the up/down/left/right buttons on the remote.
Worse, any time your password switched between symbols, numbers, lower case letters, and uppercase letters you needed to press some kind of shift key.
If long passwords were allowed I could pick a password that only uses say lower case letters from a small group that are right next to each other on the virtual keyboard, like qawe, and make up for the small character set with length. 40 random characters from qawe is 80 bits of entropy which is fine for a streaming account.
My 1password actually generates 4 random words with symbols and numbers as delimiters. A generated password is often ~24 characters.
walrus01 14 hours ago [-]
Until just 8 years ago one of the major Canadian nationwide banks was provably storing peoples' online banking logins in plaintext in some ancient mainframe database system. If you got to a sufficiently high level of customer service people in an account recovery process (like executor/probate process for the deceased) they could literally read back to you the entire password letter for letter.
> 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.
walrus01 13 hours ago [-]
Yes, as the result of certain acquisitions, much as you can see the banks that TD acquired and rebranded particularly on the US east coast. But not everywhere and not as prevalent as like a Bank of America or Wells Fargo or Citibank. There's huge swathes of the US that have zero BMO brand name presence.
Additionally First Citizens acquired a bunch of "BMO" branchs and is presumably converting them back to their branding.
I mean that could still be encrypted. But passwords should never be reversible. It should be hashed with scrypt or apparently now Argon2id.
walrus01 14 hours ago [-]
I mean literally like if the person's password was "potato##!" the customer service person would read back "potato##!". They weren't reading the encrypted contents of a pw field.
unsnap_biceps 13 hours ago [-]
their point is it could have been stored encrypted and then decrypted for the customer service person to read back to you. Access to plain text != storing it as plain text.
Atheros 6 hours ago [-]
The only way three people can keep a secret is if two of them are dead.
If the data can be read by so many people in the company that even the customer service people have access, it's functionally not encrypted.
UqWBcuFx6NV4r 13 hours ago [-]
That doesn’t mean that it is stored as plain text. It just means that it isn’t hashed.
I agree that it any system that allows this IS almost certainly just storing as plain text, and that it’s bad regardless.
flufluflufluffy 13 hours ago [-]
> This is one example why we shouldn't use the maxlength attribute on the password field.
While I acknowledge your issue is incredibly frustrating, it is still good practice to use the maxlength attribute. Yes, it can be bypassed. Yes, you should still check the length on the backend. But it’s one more layer of ensuring sanitary input. Obviously, companies should do a better job of communicating the maximum password length to the user, properly setting the attributes on all inputs, AND if they do enforce a max length, having it be large enough that it ensures a secure password, but we shouldn’t just abandon using the HTML attribute altogether.
yallpendantools 13 hours ago [-]
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.
flufluflufluffy 13 hours ago [-]
I meant sanitary in a general sense. Maybe a better word would be “unexpected.” You want to minimize the possibility of receiving unexpected input. Though not perfect, the maxlength attribute is one way of getting there.
For example, a password value of a million characters, to me, would be unsanitary, or unexpected. Of course it’s possible somebody might want to use that as their password, but more likely it’s an attempt at a buffer overflow. I’m not saying there is a specific number where it changes from sanitary to unsanitary, but choosing some reasonable value to limit the length at would be a good idea. Even outside of security, from a purely utilitarian perspective, it would make sense to have some limit on the length of any data you’re storing/processing.
Re: security, yes, there should be a reasonable minimum length as well.
Atheros 6 hours ago [-]
Servers usually accept data in a thousand ways in a thousand endpoints. Anyone who tries to prevent buffer overflow or slowloris attacks by limiting password length specifically is doing it wrong. An absurdly long password is surely one of the least likely places where a resource-use vulnerability would pop up since the data usually gets sent straight into a 20 year old hash implementation.
geraldwhen 14 hours ago [-]
Vanguard needs a full tech overhaul, a clean sweep. The website is legitimately amateur hour and has been for decades.
breput 13 hours ago [-]
[dead]
Gud 2 hours ago [-]
I have a similar, just as frustrating issue with OVH.
When I got a new laptop because my old one broke, I no longer had access to my password. So I go to OVHs website, and try to recover my password. Recovery email has been sent, but no such email arrives.
Apparently I had made an account with OVH Canada and not OVH Europe(what's the difference? who the fuck knows. I just wanted to be billed in dollars).
So despite the fact that the "Recovery email has been sent", no such email was actually sent. So I now have to use OVH Canada(again, what's the difference?) every time I login.
xdavidliu 13 hours ago [-]
recently i noticed logging into vanguard that if I use firefox autofill password, vanguard always says my password is incorrect, but typing it manually it works. I could clear my password from firefox, type it correctly and login, select "remember my password", log back out and back in, and then have it rejected.
so I figured that the way to make it work is to have it autofill, then select my username and press space then backspace, which is a no-op. That way, the javascript knows i've entered something, and then it works.
bogometer 13 hours ago [-]
There are more of these than you think and its usually financial institutions. I started running into it years ago when I started using a password manager which allowed to generate strings > 20 chars. Most sites worked, but a few key financial sites not so much. I went through the same frustration cycle as, you finally looking at the html. What is even worse is when someone uses DIFFERENT limits for their app vs web.
Garlef 11 hours ago [-]
My favorite security feature is when pasting into the set-password field is disabled...
quasarj 14 hours ago [-]
I had the opposite issue with my power company for a while. The login page had a maxlength but the reset page didn't, so I had a password set that I couldn't enter... at least without modifying the page
dk404930 14 hours ago [-]
I should have kept track of how many times I’ve run into this exact issue. I can’t recall which ones specifically, but I am confident it’s been at least three separate services.
coaksford 14 hours ago [-]
All my worst experiences with password length have been banking and finance and it boggles my mind that they all get something so incredibly basic so incredibly wrong. What is it about this sector that makes it so?
kstrauser 13 hours ago [-]
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.
madamelic 14 hours ago [-]
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.
pwg 11 hours ago [-]
With Firefox, if one sets the dom.event.clipboardevents.enabled about::config setting to false, then websites can no longer block paste. Your pastes will work, despite their trying to intercept and block them.
ajb 14 hours ago [-]
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
pulvinar 14 hours ago [-]
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.
cyode 14 hours ago [-]
+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.
airstrike 14 hours ago [-]
Fear of the Compliance monster.
jiggawatts 14 hours ago [-]
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.
TZubiri 13 hours ago [-]
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.
pphysch 14 hours ago [-]
Probably PCI and other regulations making it difficult to use and thus learn good software, so they develop entire ecosystems in-house
sergiotapia 14 hours ago [-]
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.
winkelmann 13 hours ago [-]
At least let me actually use a security key! PayPal already lets you use security keys for 2FA, but it appears they only allow for smartphone based passkeys for some reason. I'm sure these are behind all the TPMs and Secure Enclaves and whatnot, but a security key is still orders of magnitude safer.
esseph 13 hours ago [-]
My passkey is stored in my password manager and is available across devices with no hassle.
xigoi 6 hours ago [-]
Until you need to log in on some random device. Or inside an in-app browser popup.
esseph 57 minutes ago [-]
Huh? Do you not understand how this works?
So passkey is saved to my account. Account is logged in on multiple devices, secured with an additional pin.
It doesn't matter what device I'm on, I can either use the app on a mobile device or a browser.
It's fast and easy to use.
pton_xd 14 hours ago [-]
I remember a while ago (~2013?) Schwab used to silently! truncate all passwords to 8 characters. Incredible stuff.
walrus01 14 hours ago [-]
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.
nly 13 hours ago [-]
My hot take is that almost nobody should be setting _any_ length or complexity requirements on passwords. Instead just enforce the need for at least some kind of second factor, even if it's SMS, TOTP or a magic link by email.
If your password hash database is compromised you're screwed anyway, because dictionary attacks scale horizontally, even with slow hashes designed for passwords 'LickMyLiver123!!' isn't necessarily going to hold up just because it's 16 characters.
The average vocabulary of a 20 year old native English speaker is perhaps ~50,000 words and I bet when you apply some basic grammar rules, and pragmatic search paths like relying on tonnes of people just smashing !'s on the end of their usual password when a minimum length is enforced, those hashes start to fall quickly.
14 hours ago [-]
thrance 4 hours ago [-]
Exact same issue with Chronopost. Such clowns.
greenavocado 14 hours ago [-]
Any they don't support TOTP but support passkeys and SMS for 2FA. WTF
aresant 14 hours ago [-]
I had a financial advisor tell me once that he loves Vanguard because once he sends people there to buy index funds the web interface is so utterly TERRIBLE that people can't ever figure out how to sell :)
toast0 14 hours ago [-]
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.
fn-mote 14 hours ago [-]
This would be funny if it were true, but the buy/sell/exchange is right by each asset listing.
greenavocado 14 hours ago [-]
The wording is such that it doesn't have "sell for cash" or "cash out" language so the hoi polloi with room temperature IQ can't figure it out without paid guidance. Instead it asks you to go to click on your account, transact, (assuming you have e.g. VOO) trade ETFs and stocks, cross reference your securities of choice by typing them in (you have to look up their code from the Holdings tab and note it down or remember it), put in how many shares, or calculate how many dollars worth you need. Finally, there are four scary looking sell order types with no default. You have to actually understand what each means to determine if you want it.
> As it turns out, the password field on the login page doesn't set maxlength to 20.
This is the real problem. They let him set a password they did not accept.
fnord77 14 hours ago [-]
The thing that always gets me is when certain characters are not allow. Whyyy
xigoi 6 hours ago [-]
Sorry, your password must not contain characters other than “a”. Also there is a 6 character limit.
gustavus 13 hours ago [-]
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.
I could log into the website just fine, but the app kept saying my password was wrong. I reset my password, and when I was generating a new password, I found the root cause:
At some point, they changed the password policy to have a maximum length of 16 characters. My existing 20 character password worked fine in the website which didn't actually enforce a 20-character limit in the password field, but the app was silently truncating the last 4 characters when BitWarden was filling in the field.
Limiting password length to only 16 characters scares me. It makes me think they're not hashing passwords in the back end.
I guess I don’t really understand the reasons any engineering team would limit password length, but at least implement in a way that is apparent to the user. Successfully saving a password that is different than the user expects is wild.
Moreover, in the case of a financial institution like Vanguard, limiting password length feels particularly offensive.
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
Is a 9-order-of-magnitude slow down worth the trouble? I dunno. Maybe.
Finance needs to be held accountable. They’ve skim off far too much wealth for the value they produced.
They provided password requirements which he ignored.
> Finance needs to be held accountable.
Accountable for what, exactly?
I use strong 12 character passwords at work, on the off chance i have to type them out. And as a favour to anyone else that might have to.
Are there advantages? Yes: the longer the password is, the stronger it is. It doesn't matter if there's a specific point after which cracking takes time till the death of the universe. So there's no point in imposing a limit.
Besides, too many websites limit password length to ridiculous lengths like 12.
Not magic there, just information theory. but yes, I hear what you are trying to say. It is more cumbersome.
A 20 character password is for all practical purposes mathematically immune to being brute forced.
https://xkcd.com/936/
No, you misunderstood what happened: "Chrome inputs only abcdefghijklmnopqrstu (20 characters) as shown below"
1Password generated a password longer than 20 characters. When pasted, Chrome silently truncates the paste to the input maxlength!
Look at the screenshot: The requirement "Between 8 to 20 characters long" has a green checkmark, because the requirement is satisfied.
But 20 characters is simply ridiculous.
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.
Ok, yes - an undisclosed max length that doesn’t throw an error is horrible, *and this is entirely Vanguard’s fault* but what’s with the “of course”?
There’s virtually no reason to use a randomly generated password that long, and there have been more than enough stories, anecdotes etc about sites failing on long passwords that throwing an “of course” here is a little overboard.
A high entropy random password with 62+ potential characters before including “special characters” with a length of 16 characters is basically un-bruteforceable. It would take 4.6 billion years to brute force at 164.1 billion guesses per second, and vanguard (or anyone else) is gonna notice if you try the 4.77 × 10^28 possible combinations.
2. Stupid choices by services (like Vanguard!) making those extra characters a liability.
3. What are you protecting against? Even 16 characters with ~60 combinations is more than enough entropy.
4. It’s just cumbersome. And that, frankly, is the reason why the question is “why should you?”
The possibility of having to manually enter a password is actually why I used to want very long passwords to be allowed.
Say I have a streaming account, which I use from my desktop and maybe my phone or tablet. I never have to enter it manually on those devices because my password manager runs on all of them.
But then I want to use that service's streaming app on my TV. Nowadays most services have figured out a way for you to enter your credentials on their website or in the app on your phone or tablet and link that to your attempt to set it up on the TV, but back in the day most did not.
What we had to do back then is manually enter the password using the on-screen keyboard on the TV, navigated using the up/down/left/right buttons on the remote.
Worse, any time your password switched between symbols, numbers, lower case letters, and uppercase letters you needed to press some kind of shift key.
If long passwords were allowed I could pick a password that only uses say lower case letters from a small group that are right next to each other on the virtual keyboard, like qawe, and make up for the small character set with length. 40 random characters from qawe is 80 bits of entropy which is fine for a streaming account.
And just ten years ago BMO required passwords to be exactly 6 char, no more, no less: https://www.reddit.com/r/PersonalFinanceCanada/comments/4t0m...
For the Americans who might not be aware of what BMO is (it's not some podunk small town bank): https://en.wikipedia.org/wiki/Bank_of_Montreal
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.
Additionally First Citizens acquired a bunch of "BMO" branchs and is presumably converting them back to their branding.
https://www.google.com/search?client=firefox-b-d&q=first+cit...
If the data can be read by so many people in the company that even the customer service people have access, it's functionally not encrypted.
I agree that it any system that allows this IS almost certainly just storing as plain text, and that it’s bad regardless.
While I acknowledge your issue is incredibly frustrating, it is still good practice to use the maxlength attribute. Yes, it can be bypassed. Yes, you should still check the length on the backend. But it’s one more layer of ensuring sanitary input. Obviously, companies should do a better job of communicating the maximum password length to the user, properly setting the attributes on all inputs, AND if they do enforce a max length, having it be large enough that it ensures a secure password, but we shouldn’t just abandon using the HTML attribute altogether.
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.
For example, a password value of a million characters, to me, would be unsanitary, or unexpected. Of course it’s possible somebody might want to use that as their password, but more likely it’s an attempt at a buffer overflow. I’m not saying there is a specific number where it changes from sanitary to unsanitary, but choosing some reasonable value to limit the length at would be a good idea. Even outside of security, from a purely utilitarian perspective, it would make sense to have some limit on the length of any data you’re storing/processing.
Re: security, yes, there should be a reasonable minimum length as well.
When I got a new laptop because my old one broke, I no longer had access to my password. So I go to OVHs website, and try to recover my password. Recovery email has been sent, but no such email arrives.
Apparently I had made an account with OVH Canada and not OVH Europe(what's the difference? who the fuck knows. I just wanted to be billed in dollars). So despite the fact that the "Recovery email has been sent", no such email was actually sent. So I now have to use OVH Canada(again, what's the difference?) every time I login.
so I figured that the way to make it work is to have it autofill, then select my username and press space then backspace, which is a no-op. That way, the javascript knows i've entered something, and then it works.
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.
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.
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
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.
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.
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.
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.
So passkey is saved to my account. Account is logged in on multiple devices, secured with an additional pin.
It doesn't matter what device I'm on, I can either use the app on a mobile device or a browser.
It's fast and easy to use.
If your password hash database is compromised you're screwed anyway, because dictionary attacks scale horizontally, even with slow hashes designed for passwords 'LickMyLiver123!!' isn't necessarily going to hold up just because it's 16 characters.
The average vocabulary of a 20 year old native English speaker is perhaps ~50,000 words and I bet when you apply some basic grammar rules, and pragmatic search paths like relying on tonnes of people just smashing !'s on the end of their usual password when a minimum length is enforced, those hashes start to fall quickly.
It's way better than doing anything with computershare.
Its probably for the best.
Allegedly the new website is coming https://investor.vanguard.com/new-vanguard-experience
This is the real problem. They let him set a password they did not accept.