Slightly related, in order to prevent super long passwords from eating up CPU time is it better to hash using sha256 before argon/bcrypt so that the length is constant, or is it better to limit password length to some arbitrary number like 64 characters
I've been tempted a few times to simply use salt and a single iteration SHA-256 to store passwords, and put something like this on the account creation and password change screens:
> If you care about the security of your account use a 20+ character random password and do not reuse that password at any other sites. There are several excellent password managers that can generate and remember such a password for you and make it easy to use. Here's a list: <link to list of password managers>.
> We allow all normal US printable characters in your password: upper and lower case A-Z, digits, and <list of punctuation>. Set your password generator to length 20+ and to use mixed case, digits, and symbols and you will be fine.
> If you think you might have to manually type this password at some point, you can use a reduced character set with a longer password. If you use just mixed case letters and digits make the password 22+ characters long. If you use just mixed case letters make it 23+ characters. Letters all of the same case? Make it 28+ characters. 32+ characters of hex is fine, too. Heck, you can make it all digits if you use at least 39 of them.
> If your password manager offers other options, such as patterns like groups of digits or pronounceable syllables separated by some symbol, that too is fine as long as you make it long enough. Make it long enough that your password manager gives it its highest strength rating.
> The exact upper limit on password length that our password entry fields allow might vary from time to time as we update the site, but will always be at least 64 characters.
What's wrong with super long passwords eating up CPU time? Can't imagine it is that prevalent with normal users and there are other ways to deal with it if it is a vector for a DOS attack (rate-limiting the number of registrations or logins, for example).
NIST says there's no reason to limit password length any more[0]:
"Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. If the CSP or verifier disallows a chosen memorized secret based on its appearance on a blacklist of compromised values, the subscriber SHALL be required to choose a different memorized secret. No other complexity requirements for memorized secrets SHOULD be imposed. A rationale for this is presented in Appendix A Strength of Memorized Secrets."
Super long is >100 character passwords. Not much point: either the hash function is broken or some other hack will happen before humanity develops enough compute power to crack 100 char bcrypt passwords.
Websites (like some banks used to) that have less-than 20 char limits for passwords are purely bad security strategy.
Bcrypt truncates to 72 bytes, so it's kind of irrelevant IMO. Whether your average length is 12 or 20 or 64 bytes doesn't matter much.
I expect the parent's concern came from experience with PBKDF2, where the length is unbounded. It's good to consider possible denial of service attacks: if someone submits an enormous 1 MB password a PBKDF2 hasher can be knocked offline for 60s. Sha256 will quickly crunch that attack to a more manageable length.
