Password length vs DOS attack

Question

As I am referring to how password hashing works, there is an owasp blog says like "if a user can supply very long passwords then there is a potential denial of service vulnerability, such as the one published in Django in 2013."
I couldn't be able to understand the connection between Password length and DOS attack. As far as I know, Password length has a major dependency with Password cracking, since high length passwords are hard to crack. \

1. But, how Password length has a connection on password hashing time since DOS attack is efficient if the hashing time is increased?\
2. Does the computational cost/hashing time depend on Password length?

Answer 1

how Password length has a connection on password hashing time since DOS attack is efficient if the hashing time is increased?

The hashing time increases linearly with the amount of bytes to be hashed. Some hash functions internally work on blocks of data. If a new block is needed due to more data to be hashed the time it takes to add each block to the hash is constant. A block is not a character or two and its size depends on the specific hash function (comparison). If SHA-256 (block size of 512 bit) is used then there will be a measurable time difference for an at most 55 byte password and a 56 byte password (these values are due to padding).

Nowadays the password is hashed not once but multiple times in order to make brute forcing harder when the database with the hashes is "lost". Different hashing schemes behave differently with long passwords. PBKDF2 is popular, but uses the full password for each iteration. That means a longer password severely increases the computation time. scrypt is also popular, but uses the full password only for one iteration. The remaining iterations are done based on a hash which is fixed in size. scrypt is lighter on the server in case of a DoS compared to PBKDF2. I haven't looked at other popular choices.

While the computation time is severe, the other resources should be evaluated as well. When an attacker sends an unbounded amount of bytes to the server the server must store it in memory and process it. There is a consensus that this should be bounded before any kind of hashing starts. 1000 bytes seems like a good upper limit. No user needs that many bytes and you can go even lower.

Does the computational cost/hashing time depend on Password length?

Yes, but it depends on the hashing used by how much.

Answer 2

The Django PBKDF2 DoS was a result of a poor implementation of the algorithm, and doesn't really reflect a general issue with password hashing.

The algorithm is a bit like this:

digest = HMAC(key=password, data=salt)
derived_key = digest

for each iteration:
  digest = HMAC(key=password, data=digest)
  derived_key = xor(derived_key, digest)

return derived_key

You can see why this is going to scale badly with password size - each iteration you're hashing the entire password into the key for the HMAC, and since you might have many hundreds of thousands of iterations it adds up pretty fast - half a million iterations turns a 4k password into nearly 2GB of data to hash.

But an obvious optimization should also be apparent here -- turning the password into a HMAC key need only be done once:

hmac = HMAC_Init(key=password)
digest = HMAC_Calc(hmac, data=salt)
derived_key = digest

for each iteration:
  digest = HMAC_Calc(hmac, data=digest)
  derived_key = xor(derived_key, digest)

return derived_key

I believe Django ended up making this fix some time after the length restriction was added as a band-aid.

Password length does obviously have some small effect as the cost of hashing scales linearly with length, but given modern cryptographic hash functions run at hundreds to thousands of MB per second, stupidly long passwords are probably more of a network DoS issue than anything.