Hacker News Reader

Comment by Spivak | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com