A password length limit is reasonable as long as that limit still allows for strong passphrases; e.g., the limit isn't less than 64 characters. A loud limit when setting the password is significantly better than silently truncating the password.

If the application ultimately stores the password with 128 bit (hopefully salted and key-stretched) hash, there's no gain in allowing passwords longer than ~64 characters. E.g., with a diceware passphrase with 5 character words with spaces between them, a 64 character passphrase allows 10 words which would have an entropy of more than 128 bits.

A developer potentially could be worried about SQL injection or buffer overflow attacks injected via the password field -- granted you should use the standard methods to prevent these attacks: always use bound parameters with SQL (versus string manipulation to construct queries) and always properly bounds check your strings (possibly by using a safe programming languages or safe libraries with built in protections). You need to be worried about these attacks on all user input; this is not unique to the password field so the protection gained by a maximum password size is likely negligible.

There could be tangential reasons for limits as well. Say you are a bank that gives users ATM cards with a PIN (personal identification number). Allowing a user to set and use a 50 digit pin likely would have little security gain in practice over say a 8 digit pin - when an attacker needs both a user's ATM card, use a monitored ATM, and gets locked out after say 4 wrong attempts. A 50 digit pin, could be more expensive in human costs for your bank, as it would be forgotten/input incorrectly more frequently - have to be collected and have an employee walk the customer through some necessarily lengthy password reset mechanism (e.g., the reset mechanism has to be costly so it is not the weakest link), and the process could lead to poorer customer satisfaction (needed to get out money but couldn't).

A password length limit is reasonable as long as that limit still allows for strong passphrases; e.g., the limit isn't less than 64 characters. A loud limit when setting the password is significantly better than silently truncating the password.

If the application ultimately stores the password with 128 bit (hopefully salted and key-stretched) hash, there's no gain in allowing passwords longer than ~64 characters. E.g., with a diceware passphrase with 5 character words with spaces between them, a 64 character passphrase allows 10 words which would have an entropy of more than 128 bits.

A developer potentially could be worried about SQL injection or buffer overflow attacks injected via the password field -- granted you should use the standard methods to prevent these attacks: always use bound parameters with SQL (versus string manipulation to construct queries) and always properly bounds check your strings (possibly by using a safe programming languages or safe libraries with built in protections). You need to be worried about these attacks on all user input; this is not unique to the password field so the protection gained by a maximum password size is likely negligible.

There could be tangential reasons for limits as well. A bank that gives users ATM cards with a PIN (personal identification number) may choose to force users to use PINs between 4-10 digits in length. Allowing a user to set and use a 50 digit PIN likely would have little security gain in practice over say a 8 digit PIN - when an attacker needs both a user's ATM card (that hasn't been called in as stolen), use a monitored ATM, and gets locked out after 4 wrong attempts. A 50 digit PIN, could be more expensive in human costs for your bank, as it would be forgotten/input incorrectly more frequently - maybe trigger an employee to investigate (e.g., check the ATM video and compare with previous successful transactions) or have an employee walk the customer through some necessarily lengthy password reset mechanism (e.g., the reset mechanism has to be costly so it is not the weakest link). This whole process could lead to poor customer user experience which the bank wants to avoid.

A password length limit is reasonable as long as that limit still allows for strong passphrases; e.g., the limit isn't less than 64 characters. A loud limit when setting the password is significantly better than silently truncating the password.

If the application ultimately stores the password with 128 bit (hopefully salted and key-stretched) hash, there's no gain in allowing passwords longer than ~64 characters. E.g., with a diceware passphrase with 5 character words with spaces between them, a 64 character passphrase allows 10 words which would have an entropy of more than 128 bits.

A developer potentially could be worried about SQL injection or buffer overflow attacks injected via the password field -- granted you should use the standard methods to prevent these attacks: always use bound parameters with SQL (versus string manipulation to construct queries) and always properly bounds check your strings (possibly by using a safe programming languages or safe libraries with built in protections). You need to be worried about these attacks on all user input; this is not unique to the password field so the protection gained by a maximum password size is likely negligible.

A password length limit is reasonable as long as that limit still allows for strong passphrases; e.g., the limit isn't less than 64 characters. A loud limit when setting the password is significantly better than silently truncating the password.

If the application ultimately stores the password with 128 bit (hopefully salted and key-stretched) hash, there's no gain in allowing passwords longer than ~64 characters. E.g., with a diceware passphrase with 5 character words with spaces between them, a 64 character passphrase allows 10 words which would have an entropy of more than 128 bits.

A developer potentially could be worried about SQL injection or buffer overflow attacks injected via the password field -- granted you should use the standard methods to prevent these attacks: always use bound parameters with SQL (versus string manipulation to construct queries) and always properly bounds check your strings (possibly by using a safe programming languages or safe libraries with built in protections). You need to be worried about these attacks on all user input; this is not unique to the password field so the protection gained by a maximum password size is likely negligible.

There could be tangential reasons for limits as well. Say you are a bank that gives users ATM cards with a PIN (personal identification number). Allowing a user to set and use a 50 digit pin likely would have little security gain in practice over say a 8 digit pin - when an attacker needs both a user's ATM card, use a monitored ATM, and gets locked out after say 4 wrong attempts. A 50 digit pin, could be more expensive in human costs for your bank, as it would be forgotten/input incorrectly more frequently - have to be collected and have an employee walk the customer through some necessarily lengthy password reset mechanism (e.g., the reset mechanism has to be costly so it is not the weakest link), and the process could lead to poorer customer satisfaction (needed to get out money but couldn't).