Hacker News Reader

> Silent truncation of the the password without telling you

Bonus points for truncating the password differently in the login form and the password change form. Now you can't login anymore!

> Failure because the password is too long, but the error says something else (like missing symbol)

A few years ago the local City government in Paris put out some new app to pay for parking. You'd have to create an account and give them your credit card[0]. When I say they had some ridiculous maximum password length, something like 8 characters, I decided that I could actually take the five minutes to pay in person.

I haven't tried the app ever since, so no idea if this crazy limitation is still in effect.

---

[0] There was no option to give the credit card on each payment, they had to save it on file. Of course, they weren't aware that local banks were rolling out credit cards with changing verification codes, so some cards would've had to be re-entered anyway...

Speaking about France, my bank (Boursorama) requires an 8 DIGITS password.

And they add the horrible on-screen pad you have to click through (everyone can memorize it).

People working in bank regulations are truly incompetent.

> Bonus points for truncating the password differently in the login form and the password change form. Now you can't login anymore!

Yes, when I setup my first password manager one of my banks said "max length 32" so I updated to a 32-character password. Then, when I next went to login, I found the login form had an off-by-one error and Javascript would truncate the password down to 31 characters.

I was lucky and knew just enough to be able to use the console to patch the Javascript on the fly. I complained to them and they said they'd look into it; a month later I went down to a 30-character password, to stay far away from any further off-by-one issues.

>I went down to a 30-character password, to stay far away from any further off-by-one issues.

Heh...

Developer: Shoot, we've got an off by one error here. No problem, I'll just add one. Or should I subtract one?

*10 min later*

OP: That's weird, my 30 character password is now failing.

Even bigger brain: I'll just x by 2 and change the DB type to LONGTEXT.

A big EU bank that I have my account (and an online account) with, cannot change customers OTP mobile phone number if they no longer have access to the old number (they require to send an OTP when number is being changed). The reason I know this is after several visits and calls over many months, all with a lot of effort put in. I am assuming they have zero CRUD that doesn't send OTP to the old number. A bank with billions should know better.

> A bank with billions should know better.

A bank with billions should have a manual process that may involve checking your identity in 20 different ways and maybe even pre-registering your whereabouts with the police, but ultimately resulting in giving you access to your account back.

I'm guessing it might take sending them a strongly-worded legal letter to make further progress.

This has happened to me so many times that I’ve started presumptuously subtracting 2 from any max length a website gives me.

But then it's in a single-sign-on system with some other services... Where that same maximum length is also the minimum length for at least one sub-system.

(I mean, hey, that's if you're lucky -- otherwise System A maximum allowed PW length is less than System B minimum required PW length.)

Schwab used to do the "silently truncate to 8 chars" fail, but they _also_ silently changed all chars to upper/lower so the password was case insensitive.

Still can't believe they were allowed to have such a bad and secret password policy for so long.

This is the second post in this thread where people for some reason expect banks to be better than others at tech.

I've worked at a bank, in software.

They are significantly worse at tech than other industries. They're propped up by usury, overdraft fees, slow, antiquated systems. Why does it take 3 business days to get a refund? The information moves in milliseconds today, yet it still takes 3 business days to get your money back.

> people ... expect banks to be better than others at tech.

Banks hold people's life savings among other things and thus, I would think, should absolutely be putting the best security to practice. Both physical (like safes and so forth) and technical.

It’s another case of having to wait for the right people to die, probably.

I disagree. the 3 day delay is not because they want to put best security practice. If that's the case how does apps like Zelle transfers money instantaneously? I know in India, bank transfers are instantaneous and the receiver gets notified instantaneously. Some merchants even put their account number so people can transfer money to purchase goods.

Should. But aren't.

Honestly the case thing makes total sense to me. The odds that someone knows the my password but not the casing is vanishingly low.

For pw manger based passwords sure you just cut your search space down by a lot but for human typed passwords that are words / sentences ehhh

Reducing the key space makes brute forcing easier. Nobody should accept such outdated password policies rooted in 50 year old practices that can't be safely used in a world with external threats.

The trouble is some of these passwords are stored on 50 year old systems!

I think I'm more worried about the lack of complexity than the guessability. It removes a huge amount of potential variance in any sort of brute force attempt.

Online brute force basically doesn't happen and can be managed by sane traffic filtering.

It does make passwords weaker. But 26^8 is still 200B. People aren't making 100B login attempts to break your case-insensitive alphabet-only eight character password.

Sure, brute force doesn't online typically, but isn't the reason we have most password requirements generally for the scenario where someone gains offline access to password hashes?

Sort of.

You really don't want to rely on a breach being just the password hashes and nothing else. In the case where the adversary was able to do literally nothing other than exfil the hashes, a stronger password will help you. But is this actually a common threat model?

And if you have SMS-2FA enabled, an adversary with your password needs to sim-swap you anyway, which is doable but scales very badly.

Easier just to phish people.

I think FB does this?

Though it's a little bit different when it's an intentional tradeoff decision vs. just being bad at software.

In FB's case with billions of non-technical users the tradeoff is probably valid.

FB does case-inversion of the password. If at first the password hashes don't match, it inverts the case (not all upper or all lower, but passWORD <-> PASSword) to solve if the capslock is on or not.

They should do the CAPSLOCK variant (ie, passWORD -> PASSWORD). Why would inversion even make sense? If I type passWORD with all caps, and shift the last 4, it does PASSWORD, not inverted.

If I type passWORD with capslock on, I get PASSword when I apply the identical shift pattern (I literally just did this in this box!). This way if I have capslock on when typing my password, but I got the shift pattern the same, it'll still go but it doesn't wipe out my case changing patterns in terms of password security.

I'm pretty sure this behavior of capslock is pretty common across most platforms, I can't think of a platform it didn't do this on. It worked just now on a few distros of Linux and Windows, I don't own a Mac so I cannot test that for you. What platform does shift not invert the case to lowercase if capslock is on?

Yes, Mac does passWORD->PASSWORD if capslock is engaged. It's possible FB detects this based on your platform - but I can't test as I don't use FB.

That's interesting, thanks for sharing. I don't use Macs too often so I wasn't aware that was the behavior on the platform.

Ah - that is what I remembering, thanks for the clarification.

Many banks have case insensitive passwords, AMEX, Chase and Wells Fargo are others. (This might have changed very recently)

I've heard that the reason is interaction with legacy systems.

Who in the right mind thought that would be a good idea? It seems like the type of case where some executive though that failed password attempts would increase customer support load by 0.1% and therefore decided to make it a lot easier to log in. But in that case, why did they decide to stop at 8? I feel like they would have made passwords a 4 digit pin if they had their way.

Probably someone working on a limited mainframeish type computer in 1964 when many terminals didn't support lower case and the memory to store passwords was expensive. The idea of encrypting the password probably didn't exist in those days either. None of this mattered because all the terminals were inside their building so you had to get by the guard to get in. Best practices have moved on many times since then.

This was my guess too. Last mainframe I used still used 8 character, non case-sensitive passwords.

> Who in the right mind thought that would be a good idea?

Someone who doesn’t care or know or care to know. If the company (or manager in some cases) doesn’t treat people right they may not do anything above the bare minimum to survive.

So the next time a problem comes up, e.g. the old password field in the database only holds 8 characters but someone sent a memo around requiring users to provide passwords of a certain length, they might just truncate the input - problem solved, now back to lunch. Or if they would have to argue or fill in a form for a new database, they might just not do it. It could even be that they have incentive for this, e.g., easier to get raise if they don’t ask for new task related things all the time.

Whenever something stupid happens I’m reminded of the movie Office Space, this happens even at FAANGs.

> they would have made passwords a 4 digit pin if they had their way

There’s a well-known bank in Australia that has been doing this for years [1]. It’s very convenient, and if there was a significant fraud risk associated with it, you’d think they would have changed their policy by now.

[1] https://www.ing.com.au/securebanking/

You need a client number for that which is an additional level of security since most people keep that a secret as well.

My favorite is silent truncation on the signup page but not on the login page.

> I paste in my password. It gets cut off to N characters by the form. > I paste that same password on the login page. There is no character limit on the login form.

"Just get them to create an account, they can suffer through our horrible software after."

The opposite happened to me a few times, signup doesn't truncate, the database accepts it but login truncates on the backend and you can't login.

Wow... surely that would've blown up in their faces almost immediately.

A shitty local bank back home truncated without telling you as well. Didn't realize it until they rolled out a mobile app and my password didn't work. After complaining about it, a friend who worked at said bank as a teller said to try truncating to 8 chars and it worked. :rage:

Apparently it was known internally, as they used some ancient system behind the scenes that would only support a max of 8 chars, and the website just truncated your password and passed that on. The new app didn't truncate and would get an error response.

> An old credit union I was part of in NY (SEFCU) mandated passwords with exactly 6 characters. When I complained about this I was told it was secure because they forced one of the characters to be a symbol.

For a bank?! And here I am complaining that Chase doesn't support application-based OTP. I hope you ran far far away from that CU.

I forgot my password for a credit union back in the day (before I started using a password manager as we all have so many online accounts now). I clicked the "Forgot password?" button... and they sent my original damn password back to me, in email. There are just so many things wrong with that. I complained, actually talked to their "technical people" and explained the awfulness of it, then moved all my money out of that credit union. They did change how it reset later, as another member had told me, but I bet they still stored the plain text password. I was seriously angry with their awful security.

Yeah, I was in college at the time - banks often seem to have really old and not very good systems.

I use Fidelity now and while it has issues, it's much better.

Funny thing about Fidelity -- if you call them to deal with an account issue, the automated phone system asks you to enter your account password using the phone keypad. And it's quite impatient (I wasn't a third of the way through my 32-character password before it gave up and transferred me straight to a representative!)

There was a "bug" a few years back in Dell iDRAC that silently truncated the password. Took a number of support calls and ticket escalations to get them to recognize it and patch it. It occurred to me then that if Dell's enterprise team did it that it must be much more rampant than I've seen.

iDRACs aren't supposed to be public, and are on average far less sensitive than a bank account, so all in all, not that bad. And considering the quality of Dell software, it's actually better than most of their useless pieces of crapware.

I saw this bug.

Security risk or not. Changing your password on the idrac and it not being what's expected and having to jump into a DC to change 30+ host iDRACs was not ideal.

All because I couldn't find the bug at the time, I read it a few weeks later only after over a week of back breaking basic sys admin work.

Small bonus. It built my use case for fucking off more on premise infrastructure into the cloud.

Maximum length makes sense if the hashing algorithm they're using does not go past that length. I think this puts your 1st and 3rd bullet points at odds in some cases, if I understand your point correctly.

I'm not looking this up right now, but I believe bcrypt or some 'version' or 'implementation' (excuse the inaccurate language) of bcrypt limits you to 72 characters. If that limit is not made clear to the user, then they may find it odd when their 73+ character password can have the last N-72 characters changed and still successfully log in. Silent truncation is most likely a result of ignorance on the part of the software developer (I'll admit I did not know about this limit for a long time), whereas maximum length could be the opposite.

More info on this, since I'm no expert: https://security.stackexchange.com/questions/39849/does-bcry...

You can solve this limitation yourself by implementing a simple client side digest hash before sending to the backend for proper password hashing. So your backend receives the fixed length digest hash and not the actual password for hashing. With a good digest hash algorithm like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.

>like sha256 you are effectively able to support "infinitely" long passwords without any significant loss of entropy.

I disagree. I used to have my password manager generate long passwords, but I realized that the entropy was just being clipped to 256 bits by the hash function. It's not that crazy to go over. That being said 256 bits of entropy is plenty.

The problem with this approach is that now someone on the backend will mistakenly think, hey the password is already hashed by the client, let's just store that directly in the database! And now you essentially have passwords stored in plain text.

If your backend and frontend engineers are that bad at communicating the api then you probably already have a lot of security problems to begin with.

> like sha256 you are effectively able to support "infinitely" long passwords

If my math is correct, 256bits of hash can effectively support up to about a 36-character password, depending on how many bits of entropy you give each character.

Your math is incorrect. Sha256 can support arbitrarily long inputs. You can easily verify this claim by googling a Sha256 calculator and giving it 2 inputs : First your 36-character "password" and next the same password with an extra character. You will notice that the outputs will be different.

With a password longer than about 36 characters, the pigeonhole principle comes into play, and there will exist a sub-36-length character password with the same hash as the longer password.

Right, but that doesn't refute the original point: you can support infinitely long passwords by hashing them. If we compare truncating a password to 36 characters vs hashing a password to a 36-character hash, hashing is much better. The hash is guaranteed to have at least as much entropy as the original password, up to 36 characters of entropy (yes, the hash can not have more than 36 characters of entropy, we get it, that's not the point, nobody is brute-forcing passwords that actually have 36 characters of entropy).

I'll provide an edge case example to prove my point: suppose someone has a password that repeats the character 'q' 100 times, then repeats the character 'a' 100 times, and so on, until the password contains 8 randomly selected characters. This password has (slightly more than) 8 characters of entropy, right? If you truncate the password to 36 characters, the password will simply be 'q' repeated 36 times, so the truncated password will have (slightly more than) 1 character of entropy, right? But if you hash the 800-character input to a 36-character hash, the hash will contain exactly as much entropy as the input: (slightly more than) 8 characters worth.

Maybe the example with 36 characters doesn't seem realistic to you, but my previous bank (Handelsbanken) actually secretly truncated passwords to 8 characters. I was not aware of this, and I had a password that contained multiple consecutive words (like correcthorsebatterystaple). I thought I had a secure password, little did I know my password was actually a single word because of the truncation. Now, if my bank had instead hashed user inputs to an 8-character hash, and used that as the password to their legacy system that only supports passwords up to 8 characters, my password would have actually contained 8 characters of entropy.

Yes exactly. Hence the quotes around the infinitely.

Your chances of starting out with more entropy in a 800 char passphrase is likely to be larger than what you are likely to have when starting with a 36 char passphrase.

If you hash a 36 char passphrase then you retain most of the entropy of that 36 chars. No more no less. If you hash a 800 char passphrase then you maintain most of the entropy of that in the resulting 36 chars. Which is likely to be more.

But that’s not what Sammi described as “support” upthread: “support "infinitely" long passwords without any significant loss of entropy.”¹. That description – i.e. “without loss of entropy” – is what I took issue with, due to the pigeonhole principle.

1. https://news.ycombinator.com/item?id=26866624

Personally I don't think there's a practical difference between having 1000 bits of entropy in your password versus 256 bits of entropy, but fair enough.

Thanks - the sites I'm complaining about typically limit characters somewhere between 18-32 so I suspect it's unrelated to this.

Ha, funny to see my old bank from college mentioned on here. For what it's worth, their site seems to be a lot more reasonable about passwords nowadays.

> An old credit union I was part of in NY (SEFCU) mandated passwords with exactly 6 characters. When I complained about this I was told it was secure because they forced one of the characters to be a symbol.

Woah that's so secure. What if you only had 2 characters; both symbols. I'm sure that is 2x as secure.

Yes, it gets more secure as you add more requirements. Let's mandate that last character is a digit larger than 1, but smaller than 3. Also, the password must be exactly 7 characters long, and the first 6 characters must spell out a class in WoW, lowercased.

> What if you only had 2 characters; both symbols. I'm sure that is 2x as secure.

Wouldn't it be 4x? (2^2)

Yeah love adding a !1 to the end of a otherwise secure password then incrementing the number every month