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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…