The best way to handle passwords IMO, is to have the browser compute a quick hash of the password, and then the server compute the hash of that. That way the “password” that is being sent to the server is always the same length.
The best way to handle passwords IMO, is to have the browser compute a quick hash of the password, and then the server compute the hash of that. That way the “password” that is being sent to the server is always the same length.
Well we don’t know how that website is actually storing the password. They may well be using a password hash. Also, you should use scrypt or argon over bcrypt IMO. And there should be no upper restrictions on password length. argon2 can handle hashing megabytes of data in about the same time as a short password, so there’s never a need to limit the password length.
To potentially answer my own question: I believe the protocol I was looking for might have been the dat protocol which seems to have been replaced by something else.
Reddit’s database was pretty poorly designed. They designed it to be really flexible so they could make changes easily early on, but it was highly inefficient. I don’t know if it’s still like that, but the old website’s source code is public and it is very inefficient.
It is bad programming. Specifically it is very bad security (especially setting a maximum length - that is just ridiculous). I think websites should not rely too much on passwords anyway. They should be designed under the assumption that attackers will fairly commonly get access to user passwords, and therefore not let someone do too much damage from simply being able to login to your account.