Hacker News Reader

Comment by strifey | Hacker News Reader

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.

View on HN

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

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.

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

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.

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.

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!

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.

> 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.

> 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.

Reply on news.ycombinator.com