Especially if they have a maximum password length.
Not really, there are good reasons to limit password length. Like not wanting to waste compute time hashing huge passwords sent by a malicious actor. Or using bcrypt for your hashes, which has a 72 byte input limit and was considered the best option not that long ago. The limit just has to be reasonable; 72 lowercase letters is more entropy then the bcrypt hash you get out of it, for example.
Kind of.
The official web UI doesn’t let you enter more than 60 characters, but doesn’t indicate that at all. So you can keep typing past 60 characters but it won’t get added to the input field and you can’t really see that. If you paste a password into the field, it gets trimmed to 60 characters.
When creating a password, the server checks that it isn’t longer than 60 characters and returns an error if so. On login, however, it silently trims the password to 72 bytes, because that’s what the hashing algorithm they use supports.
Looks like there’s one for the Sens.
I mean there needs to be a limit, because hashing a password is, by design, resource intensive. Also, Lemmy uses bcrypt for password hashing which supports up to 72 bytes, so the limit can’t be any higher than that. It should probably be indicated somewhere though, I agree. I was also caught off guard by it but realistically 60 characters is more than enough… it’s more entropy than the hash you get out of it, if it’s random.
The web UI trims passwords to 60 characters. I assume Mlem doesn’t and the API doesn’t either or just flat out rejects the request if the password is too long.
You make it sound like an irrelevant detail, but that’s kind of the key part. If implemented properly, it’s only valid once and for a short period of time, which greatly reduces risk.