Oh no! You’ve guessed one of the quotes I use to generate a password:
"Gentlemen, you can’t fight in here! This is the War Room!
Kids today will never comprehend the use of a 300 baud acoustic coupler. They laugh at the line connected modem negotiation at 14.4kbps – which was a luxury!
Length or character subsets, it doesn’t matter to me. What matters is total entropy.
However any given web site may have a local implementation limit that restricts the overall length of the password - could be 32, 64 or something like that - which may also be applied for security reasons i.e. to defend against buffer overrun attacks.
And also some web sites explicitly reject punctuation characters, possibly because they think that it is indicative of an attempted exploit. For example a super-lame web site that is vulnerable to SQL injection attacks may not allow single quote characters (standard SQL) or double quote characters (MySQL default); and a super-lame web site that is vulnerable to injection of special characters into a shell command may not allow any of a large set of special characters.
The overall approach of using only completely random passwords of sufficient entropy in a password manager is a solid one - subject to the restrictions of each web site. But in that scenario it really doesn’t matter what character subsets or length you use (as long as the entropy is sufficient) since most of the time you will be using cut-and-paste or autofill to supply the password.
However, since the web site doesn’t control whether you do or don’t use a password manager, they do need to continue to enforce password entropy at their end.
And, yes, I am putting aside mistrust of local only password managers for the purpose of this post. Using a password manager is vastly better than reusing a weak password across multiple web sites (which of course does happen).
This is beyond your control in many cases. You can complain to their security department but (in my country at least) I know you will get at best a polite rejection.
Also, as per discussion above, the web site is also defending against the possibility that their underlying password file is compromised. So high entropy remains desirable no matter how it is achieved.
This is a controversial one. I think that if 2FA is in use via a separate device, it may be OK to relax this requirement. A strong (high entropy) password that the user can remember without writing down because the same password has been in use for quite a few years for that one web site, coupled with 2FA, seems OK to me. (NB: Separate device may be difficult to enforce. A lot of people do internet banking on their phone these days so the second factor can in principle be security theatre.)
The concern is that if a password is compromised via any means then if it is never changed then the intruder has access to the account forever. (So, you may now or in the past run Windows and there was that one time 10 years ago when it caught a virus and the average user and many other users besides won’t really know what was captured and what was exfiltrated … so a periodic password change defends against that.)
I note that one of my banks allows you not to have a password at all and instead to use either a passkey xor their dodgy app. So maybe this discussion is heading towards obsolescence. (Again, that is beyond our control. It is not an approach that I agree with if it becomes mandatory but if that’s the way most web sites go, we won’t have any choice about it.)
I should have been more explicit. What I meant to ask was would it be an overall improvement over the status quo if companies, governments, etc adopted most or all of the recommendations of NIST SP 800-63B.
I’m pretty sure it doesn’t recommend forbidding mixed case, punctuation, special characters, etc, just to drop requiring them.
They also recommend a pw manger. I don’t remember whether they say cloud based is OK. I agree that there is no way I would trust something like that. I use a local pw manager with head only lock, in part because I, personally, am unable to reliably memorize even 1 randomly generated pw or phase sufficiently long or more than 2 or 3 phrases that are true phrases.
Their primary rationale is that current practices are clearly not working and that their suggestions would better reflect human nature.
It’s been so long since I read it that I don’t remember what they write anything about dongles or other hw. I’m pretty sure they have a low opinion of using text messages.
If ‘everyone’ uses a password manager and random passwords are generated therein then I just don’t see that it makes much difference how entropy is achieved, as long as entropy is achieved. So you might as well make the mandatory password requirements severe / keep the current requirements i.e. all 4 character subsets and substantial length.
If a given web site drops a requirement for ‘character subsets’ then they would have to strengthen the length requirement, otherwise you know what would happen. Users would go back to using “password” as their password.
And the high security users would use “password1” or “p4ssw0rd1”. /s
There’s no obvious way to force everyone to use a password manager. This is why some entities are pushing passkeys but that comes with its own negatives. Passkeys effectively forces everyone to use a ‘password manager’ and forces everyone to have a unique maximum entropy password for each web site.
I use a string of letters made of a short saying, in reverse, that I memorized and use every time, followed by the name of the site to be reached with the site’s first letter capitalized and ending with an exclamation mark. Easy to remember, fullfills the requirement to have a special character, etc and no one knows the first 6 or 7 letters except me.
Um, if I understood what you just wrote, then your problem is that if just one web site anywhere in the world that you use is compromised, or some device that you use to log in is temporarily compromised, or the web site itself is untrustworthy, then you just gave the intruders a huge head start towards breaking all your accounts.
Now it may be that credential stuffing attacks as currently used may not be quite smart enough but …
Just FYI, here’s what the Australian government is officially recommending, and currently running an advertising campaign on, TV and web (which recommendation is not binding on Australians, much less on anyone else - so just mentioned for discussion):
A passphrase is a more secure password. It contains a sequence of random words making it easier for you to remember but harder for cybercriminals to guess.
Strong and unique passphrases:
contain 4 or more random words
contain 15 or more characters
are different for every account
do not include identifying information such as family names, birth dates or addresses
include symbols, capital letters, or numbers, if required by the website or service.
which is not terrible advice but is not something that I am doing.
I think the risks are that
random words, if being generated in someone’s head, will be anything but random (will instead reveal and reflect word associations), and
the words are likely to be drawn from a far more limited vocabulary than what theory would suggest. (Theory may say that the average educated English-speaking adult peaks at about 2^15 words but, in practice, the active vocabulary will be far less, perhaps closer to 2^12.)
(I followed the link to some examples and the words used were concerningly basic e.g. red house sky train. If those are the kind of words chosen for a passphrase then entropy is going to be dying.)
Hence the desirability of using software to generate passphrases out of truly random and more difficult words, if that’s the direction you want to go. We might even learn a few new words along the way.
Unless that software “remembers”. You may also want to clear that software’s cache or temp files. (You probaly know that and take measures, just saying.)
If the password generator is built-in to a password manager (as is often the case) then there is an expectation that the software will remember the password but only in a secure and controlled way.
On the other hand, it is fairly important that the software be memoriless i.e. there should be absolutely no correlation between a password generated at time t and a password generated at time t+x. So, as a minimum, a cryptographically secure source of randomness needs to be used.
And, as generic advice, confidential material (of any type) should never be stored in unexpected places such as a cache or a temp file - because it makes it difficult or impossible for the user to control risk of exposure.
“Covert channels” has always been a concern since the rainbow books. But that’s how open source helps, someone could at least read the code and find out.
I didn’t say I used the Nitrokey 3. In fact, I don’t. As I explained, I use KeePassXC with an “OK password” and a keyfile on a standard USB stick.
My point was that KeePassXC supports Nitrokey 3 (via HMAC-SHA1 challenge). Until I just looked, I didn’t realize that KeePassXC also supports Yubikey (also via HMAC-SHA1 challenge).
I use pass, each password or credential set lives inside it’s own gpg encrypted file. The gpg key I use with it sits on an OpenPGP smartcard (YubiKey and/or Nitrokey, I use both).