Why dafuq do websites have a max length password policy!!!

Trying to save a few bits in their database servers.

otherwise, it is pure BS

@asgs
Also to make it obvious, that they save passwords in plaintext.

so it told me my password had to be between 10 and 14 characters and could not contain -, . or \

They maxed out the iterations bcrypt runs at before producing serious sever load, keeping the string lower allows for further iterations - aka: its a "secure" password, although it's so small it's guessable by brute force.

@irene we have a legacy system that stores plaintext and it is not even on the tech debt

@irene
Bcrypt is a Blowfish hashing algo - usually the goto for crypto-hashing unless using sha based algos (sha256/512) which are much faster, but back to Bcrypt, it has a side affect when you increase the iterations, or costs, which is expected anyway when you understand what its doing.
.
Generally you can get it up to about 15 or so iterations before it "blows" out and starts affecting server load.

https://en.wikipedia.org/wiki/...

Compliance and entropy.

NIST guidelines suggest 16-64 chars, so there is an upper limit even in guidelines, but it's absurdly high so

@Parzi I use mostly generated passwords stored in a password manager.

My default length is 32, but e.g. Microsoft limited passwords to 16 chars, WITHOUT TELLING on registration or password change.

So I could register fine, when I tried to login, I got an error because the pw is too long. Had to truncate my own pw to login... Industry standard my ass!

@irene jup, a real mess

I can think of 2 reasons:
1. So you don't spam server with 2GB passwords.
2. So you don't make your passwords insecure - if your hash is 128 bits make your password max length 128 bits otherwise you'll have false positives. So your 400 bit password may hash into the same string as 8 bit password.

@sSam Hashing.
2gb -> 64bytes

Also, any password that long would exceed the max request size and fail with a 413/431 anyway.

@Root so what? You are going to waste bandwidth and processing power?

@Root you are correct yes. Hashing will take literally infinite amounts of data down to a fixed size. But that data is done in chunks and has to be loaded into memory attached at once until hashing is done.

If you look at sites like Facebook, or YouTube which could have literally millions or even billions of people logged in, and thousands or tens of thousands logging in right now, we start to see a ram issue... Kinda?

If 1,000,000 people log in, at the exact same millisecond, assuming we can handle all those requests concurrently, you can hold all the passwords in just 4gb and the Mac password length is 4kb. That's a password length of over 4000 characters. Or 64x as long as the NIST recommendations.

So there is logic to it that I assume people might follow. But if you dig just a tiny bit deeper you realize that logic is complete bullshit.

There are other concerns like how fast you can do hashes or bandwidth, which at the level of tech Giants and fortune sites is a real concern.

@irene there are effective size limits though even if you hash your passwords:https://usenix.org/legacy/events/...

Tldr: limit of bcrypt is 56 bytes ~55 chars. I believe argon2 does not have this limitation

@irene True but a too long string size can make a hashing algo crash or application memory limits (those would be extreme but possible)

@sSam oh no, allowing my users to have good passwords! Whatever shall I do?

More seriously, you're right that it's an avenue for denial of service. However, most hashing algos (bcrypt included) have an upper limit on input size anyway, so you should limit your password length to that regardless. If they didn't, I'd probably limit them to a few kilobytes, depending on load generation. Why? Because past that, it's basically just an RSA key.

@irene That entirely depends on the server configuration.

@Root about the strong passwords read 2nd point in my initial comment.

@sSam Trying to bypass the pigeonhole (collision) issue that way won't work -- though it will "help." The issue instead lies in the hashing algorithm.

Why? You can have two short strings that produce the same hash, so you cannot prevent collisions.

However, the likelyhood of someone discovering collisions (accidentally or via brute force) is insanely improbable, even when allowing unbounded password length with a hashing algo that lacks an upper size limit. Therefore, I don't see the concern. At least not until quantum computing is more common. Most security approaches are not quantum resistant anyway, and simply cannot be due to their nature.