[whyever]

Such long passwords are silly, they will be effectively truncated by the key length of the underlying cryptography.

[FabHK]

Agreed. But since every character gives you around 6 bits (26*2 letters + 10 numbers + some special characters ≈ 64 = 2^6), you'd need 256/6 ≈ 43 characters to exhaust the checked entropy, so up to that level it makes sense.

If you use sentences instead of randomly generated characters, the entropy (in bits/character) is lower, so 100 characters might well make sense.

[afiori]

Which is why sha+bcrypt is always better than just bcrypt

[sweetjuly]

Passwords are (or, rather, SHOULD be) cryptographically hashed rather than encrypted. It's possible to compute a hash over data which is longer than the hash input block size by feeding precious hashes and the next input block back in to progressively build up a hash of the entire data.

[xx_ns]

bcrypt, one of the more popular password hashing algorithms out there, allows the password to be up to 72 characters in length. Any characters beyond that 72 limit are ignored and the password is silently truncated (!!!). It's actually a good method of testing whether a site uses bcrypt or not. If you set a password longer than 72 characters, but can sign in using just the 72 characters of your password, they're in all likelihood using bcrypt.

[whyever]

Yes, in this case it would be easier to brute-force the key instead of the password, so the additional characters don't really help.

[bsimpson]

For years (and way more recently than is appropriate), the financial institution Schwab would silently truncate your password to 8 characters.

If your password was 123lookatme, you could type 123lookaLITERALLYANYTHING and it would succeed.