It’s not so much why the OP thinks they’re entitled to arbitrary password length, it’s that the UI/UX does nothing to inform the user of this. And also the bytes they save restricting password length to 32 instead of 128 or 256 would be a few dollars rounding error in the end of the Year budget.

I fucking hope they don’t save any bytes doing that given that’d mean the passwords are stored in clear text.

Though given what we’ve seen so far once people started taking a look that’s not out of the realm of possibility.

I am really struggling to come up with a situation where this would actually matter. I guess if for some reason the first 32 characters of my password got leaked but not the next 32? But why would that ever happen, and who wouldn't change their password in that situation anyway?

32 characters might be safe, but we could make the same argument for 16 characters, yet there is a huge vulnerability there: Someone might have a perfectly secure series of words as a password, but only the first three words survive truncation. Now they can be brute-forced easily.

It's bad form in general to truncate a password.

proper hashing yields no saving of bytes.

You're right, I forget about that. Which is why I'm not a backend programmer.

You are only storing the hash of the password so there is no reason to have arbitrary length constraints like 32. Why not make it several thousand characters?

There is actually a reason (though 32 seems pretty short. Something like 256 is probably more reasonable).

Several thousand characters (or worse, unlimited length) opens up your attack to a form of DDoS where you can exploit the fact that password hashing is a computationally heavy operation. See here: https://arstechnica.com/information-technology/2013/09/long-...

> Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large—and guaranteed-to-fail—passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher. This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

55 would make sense if they are using bcrypt. But since it's 32, they're probably not actually securely storing (password hashing) them at all.

The real problem there is using an algorithm that gets slower on longer passwords.

There's no need to have a cap bigger than a kilobyte though.

Is there a cryptographic hash algorithm that doesn't? It seems like that would make it non-cryptographic (since you will need to read each byte at least once).

Reading each byte once only takes a few microseconds. That's not the issue.

What you need is for the slow core of the algorithm to be fixed-speed.

Either by only reading the input bytes during initialization, or by only feeding a fixed number of input bytes into the core during each round.

Isn't this mitigated by hashing the password on the client (in addition to hashing it on the server).

But couldn't an attacker just skip the client-side hashing?

Then the server will reject it for being the wrong size.

The GP suggested it would also be hashed by the server - presumably because you can't trust client input.

You would hash it on the server because you don't want to turn the 'hash' into a plain-text password.

But instead of the server accepting an arbitrary string, it only accepts hexadecimal or base64 strings of a specific length. Which solves the problem.

I'm not quite understanding the protocol here.

If the client sends only a hex/base64 string, how can the server trust that it's the result of a password being fed to a KDF?

It doesn't matter.

The threat model is: Password is too long, lots of CPU is wasted, denial of service.

By only accepting strings of a certain length, the threat is defeated.

The client could send an intentionally bad password even if they weren't lying. If they lie, only the client is harmed, and in a non-new way.

So this scheme has one notable upside, and no notable downside.

There are better solutions, but this one is valid.

Hmm, I can see some benefits to the scheme, such as using the client's CPU cycles, and the plaintext password never having to be sent to my servers.

Maybe it's just that it's not the norm, but I'm still unsure I'd actually use this scheme.

As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.

TBH, my preferred solution here is never to silently truncate passwords, and just to set a "sensible" limit on password length, e.g. 256 characters. Yes, it's still an arbitrary limit, but it should be long enough to cover 99.9999% of users.

> As the owner/maintainer of a service, I want to be in control and know that my user's credentials are secure - there may even be legal obligations here in some countries.

The code doing the client-side hashing is just as secure as the rest of the client interface. You don't compromise anything by doing it.

Still, it's easier to do the extra hash locally on the server if you need it.

How?

Yep. You do want a limit though as you don’t want random attackers to DOS your login server by feeding megabytes you your kdf.

For me it's not the maximum length which is the issue. It's the silently accepting input which is too long.

I usually sha256sum a string whose format I know to generate the 64 char password. My expectation of password length is that I should simply paste the result into the password field and not have to think about it any more.

Why: len(sha256sum(str)) = 64.

A few hundred to thousand characters, because you don’t want to send megabytes of garbage to your KDF and that’s more or less the only reason to limit password length.

Also if you put a limit, don’t silently truncate.

I find 64 characters a pretty reasonable expectation.