Your Password is a DOS Vector

I've frequently seen the sentiment among technical people on Twitter that sign up forms on websites should have no maximum limit for passwords. I get the sentiment, but I also think it's sorely misguided. And, since the idea is frequently promulgated by technical people, I'm going to nitpick.

Current state

Many web services have seemingly arbitrary requirements for passwords. They may or may not include character counts, letter casing, numbers, special characters, banned words, and sustained major chords.

In terms of password security, I think (and many agree) that only one limit is defensible, and that's the minimum character count.

Most technical people leave it there. Minimum character count is all that matters, and no other limits should be enforced. However, the password does not exist in a vacuum.

The problem with no upper limit

I see two major criticisms against maximum lengths on passwords. First, it is often arbitrary, and can interfere with the password a user would use. Second, it can reduce password security by limiting the possibility space of the passwords.

While I understand that these factors are irritating, companies have good reason to impose a limit: password fields are potential attack vectors. Having no limit at all on password length would mean the server has to hold the password in memory to serve the request. Malicious requests with a password that contains several GB of data can easily crash a server, which means the door is wide open for denial-of-service attacks.

Let's be optimistic and say there is a global request size limit of 1 MB on this server. Even then, the server has to spend CPU time proportional to the size of the password to hash it, which opens the door for service degradation attacks.

I understand that devs on Twitter with no users don't have to think about potential attacks on every endpoint, but enterprises have to be prepared for it.

That said, I do think that enterprises could loosen the restriction, or take steps to close password entries as an attack vector without the restriction.

The ideal state

A very high limit

As stated, it does make sense for enterprise applications seeking to mitigate attack vectors to impose an upper limit on passwords. However, many services impose too low of a limit, especially if you're employing the "passphrase" method of managing passwords.

A 20 character max is common, but a limit of 100 characters shouldn't pose an acute problem for a modern server¹, and is more than enough for a password. How many people are memorizing (or typing in) 100 characters to check their email?

Double hashing

One of the nice side-effects of many hashing algorithms is that they guarantee an output size. If there is a need to limit the amount of data to the backend, then the original password could be hashed in the frontend², before being transmitted and re-hashed in the backend.

In this setup, the frontend hash effectively becomes the password. So, the frontend hash operation doesn't add any meaningful security, it's just there to ensure the data being transmitted to the backend is a specific size.

Double hashing has a few benefits:

• First, there could be no maximum password size limit, from the user's perspective. Any memory or compute overhead is eaten by the user's machine, which effectively removes large passwords as an attack vector.
• Second, the password that the API sees is guaranteed to be a static length, which means the memory burden and CPU workload are predictable and limited.
• Third, requests are even easier to validate. For instance, if a system is using SHA-256 in the frontend, and password field in the request is not exactly 64 characters, then the request is known to be invalid.

Early rejection

Enterprises can limit their attack surface by rejecting invalid requests as soon as possible. Request data validation should happen before any expensive operations, such as database look-ups or hashing.

If sign-up and sign-in endpoints are a specific concern, field length validation could even happen in the WAF or load balancer, before the request reaches the backend service.

Conclusion

The "no limits" crowd is solving a real problem, they're just going too far. Password length limits can be safely raised to a level much higher than the average person would use, and enterprises have several mitigations at their disposal if this attack vector is a concern.