You'll have half your users with passwords like '123'. You could say it's the user's fault and their account is compromised, but when it's half the users on your site, really your site is compromised.
Correct, though I would phrase it as "the password can be 100s of chars long, if the user so chooses"
i.e. No noticeable maximum length for people using password managers and generating 30, 50 or 100 char random passwords, but still insulated against attacks with endless streams of input data - it is acceptable to reject 10 000 char passwords as a hostile input designed to tie up server resources.
I said nothing at all about what the minimum password length should be, and that's deliberate, it's a separate kettle of worms.
But ok: I'm also not a fan of measures such as "password entropy" or "must contain at least one from column A and one from column B". Subjectivity, naive use and changing attacks have given these a bad reputation, often deserved. Password length is not subject to such changing moods.
The parent posts comment, "A decent minimum password length, without any funky requirements, just the minimal length" is fine by me. I didn't want to add to that statement on the topic.
With all the rules in the world, some people are going to have relatively weak passwords, and we cannot entirely eliminate that. But we can also allow and encourage strong passwords by - as an easy first and minimum step - removing deliberate misguided impediments like max lengths and disabling paste.
I think the only way this can happen is zero-knowledge password proofs, i.e. browsers implement a mechanism by which password fields submit a proof that the user has the password, rather than submitting the password. This way the server can only verify the password if they've implemented the proof system correctly, and they can't leak the password because they've never had it.
The basic idea is, the server gives a unique nonce with the password form. The user enters their password. On form submit, the browser stretches the key space of the password using a slow hash, then uses the digest to generate an asymmetric key via a referentially transparent algorithm (no random salts). Then the browser prepends the URL (obtained from HTTPS) to the given nonce (to prevent man in the middle attacks). The browser then checks to see if it has seen this nonce before and displays an error if it has (to prevent replay attacks--this forces servers to generate new nonces, although the browser can't force them to verify that the nonce that is signed later is the same one they sent). Finally the browser uses the key to sign the nonce, and sends the signature to the server. The server uses the public key (which was generated in the same way and given to the server at sign-up) to verify that the user has the password.
I love the idea of zero-knowledge password proofs. Others can chime in on the approach you've proposed, but I have a more practical concern about developing critical mass.
How do you break through the chicken and egg problem of not enough users using or not enough browsers supporting this capability?
Browsers that support the password-nonce argument sign as I described. Browsers that don't support it pass through the password and the server performs the ZKPP key generation (this is no worse than the current system of hashing passwords). So servers can implement this immediately without worrying about breaking in non-supporting browsers.
After adoption by a few major sites, browsers can add a warning that the server didn't send a password nonce and the password will be passed to the server so the user has to click "Okay" before it gets submitted. This can be escalated to more severe messages to pressure more sites to comply.
Implementing it in Javascript would defeat the entire purpose. The point is for the browser to implement it as a supported field on input tags of type password.
You don't want to restrict on any password aspect but this:
Is the password known?
Any sort password is know. There are lists of millions of known passwords.
Better would be to get away from passwords entirely.
NB: I've been checking the xkcdpass utility (available on Debian). Generated 50 sets of 100,000,000 passwords each, comprised of six words (the default), then sorted these uniq, and counted the output lines.
Any duplicates would result in fewer than 100,000,000 lines.
All fifty trials had no dupes.
Took most of a week to run that, on an older box :)
- never disable paste on a password field.