correct horse 19 battery staple
I’ve worked for companies where they ask for the out of date NIST stuff you mention and it’s either you follow what they ask or you lose out on a deal to fund your company.
https://pcipolicyportal.com/blog/pci-compliance-password-req...
[1] - https://security.stackexchange.com/questions/33470/what-tech...
50,000^4 > (26+26+10+10)^10
$ egrep '^[a-z]{4,10}$' /usr/share/dict/words | wc
50768 50768 433477
$ for i in `seq 5`; do egrep '^[a-z]{4,10}$' /usr/share/dict/words | shuf -n 4 | xargs; done
droned engraves developer manoeuvre
lifeforms lurked pursuing subjugated
hooligans underplay sudden command
quartettes soapbox blacklist pigtails
roughening chefs mortals earthy
1Password just gave me this: land convolve witchery bequest
Having said that, since I use 1Password, these are rare and almost exclusively used for things where I need very-short-term memorable passphrases for things that won't let me copy/paste from 1Password (like my Apple ID or the passwords my bank ask me for over the phone...) Everything else just gets 25 random chars (or the maximum number of chars the input will allow).
A 1000 word vocabulary is quite understandable, though a little awkward.
A random word might be as few at 10 bits of entropy. If a person is picking them out of their head, I'd bet it's unlikely to be as many as 12 or 13 bits. Most of the words we "know" aren't ones that come to mind when we're "randomly choosing words"...
echo $(cat /usr/share/dict/american-english | grep -v \' | egrep -v '[A-Z].*' | shuf -n 4 | tr '\n' ' ')
trawled scratch protract sagings
perpetuates barium entreated credits
integrals virago chronicled weathercocks
foremasts milkmaid bashful maddened
disposes shrunk propose stanchion
midwived romantics gallbladders spotlighted
I wrote a command-line tool in Rust for generating passphrase using these wordlists. I use it myself any time I need a password.
My tool is fast, free of charge, open source and it can also tell you the entropy that will result for any given choice of number of words.
For example let’s say I want it to give me four words from the long wordlist, and I want to know how many bits of entropy this corresponds to.
pgen -l -n 4 -e
Current settings will create passphrases with 51.70 bits of entropy.
What does that mean, you might ask.
The Wikipedia article on password strength (https://en.wikipedia.org/wiki/Password_strength) explains it well:
> A password with an entropy of 42 bits calculated in this way would be as strong as a string of 42 bits chosen randomly, for example by a fair coin toss. Put another way, a password with an entropy of 42 bits would require 2^42 (4,398,046,511,104) attempts to exhaust all possibilities during a brute force search. Thus, by increasing the entropy of the password by one bit the number of guesses required doubles, making an attacker's task twice as difficult. On average, an attacker will have to try half the possible number of passwords before finding the correct one.
Ok, so how good is 51.70 bits of entropy, you ask?
Wikipedia, same article again:
> The minimum number of bits of entropy needed for a password depends on the threat model for the given application. [...] RFC 4086, "Randomness Requirements for Security", presents some example threat models and how to calculate the entropy desired for each one. Their answers vary between 29 bits of entropy needed if only online attacks are expected, and up to 96 bits of entropy needed for important cryptographic keys used in applications like encryption where the password or key needs to be secure for a long period of time and stretching isn't applicable.
So let's say that you are satisfied with 51.70 bits of entropy in this case. What does a password like that look like? Let's generate one.
pgen -l -n 4
plastic case refocus demise
Oh yeah, and about the claim that it's fast. Just how fast is it? Have a look.
time pgen -l -n 4
browbeat hummus sandbox unfixable
real 0m0.005s
user 0m0.001s
sys 0m0.006s
But hey, let's say we wanted to generate a bunch of passphrases at once.
How much time does it take to generate 10.000 passphrases and dump them into a text file?
time pgen -l -n 4 -k 10000 > 10k.txt
real 0m0.132s
user 0m0.073s
sys 0m0.058s
Source and instructions on how to install it are on GitHub.
Yet somehow, each time the XKCD is posted, someone will "point out" that pass phrases can be dictionary attacked, which is kind of like me saying "I know which letters are on your keyboard, and can therefore brute force your password!", but not having done the math beyond that.
10,000^5 > 50,000^4
This is probably misleading (and possibly confused).
Diceware style passphrases are easily brute forced relative to a random passphrase of the same length but that doesn't mean they're "easily brute forced". Assume your attacker knows how you're constructing your password, estimate the amount of entropy, and be sure it's enough.
44 bits is low for offline attacks, but (as the comic points out) still better than a lot of passwords people use even when they're trying to make a good password and following NIST guidelines. If you use 5 words and draw from a longer list, it's easy to be solidly out of the range that's crackable on modern hardware.
When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include, but is not limited to:
- Passwords obtained from previous breach corpuses.
- Dictionary words.
- Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
- Context-specific words, such as the name of the service, the username, and derivatives thereof.
A diceware passphrase has 6^6 possibilities ≈ 15 bits of entropy per word, so an unremarkable 5-word password has 77 bits of entropy — generally good enough — and if you have a high value target that might be susceptible to offline attacks, 90-100 bit passwords are still pretty easy to remember.
I wish people wouldn't use XKCD as the go-to reference for "collection of randomly selected words"-style passwords; it always seems to leave people confused about why the technique works.
You can’t take one recommendation that you like out of a whole body of work and start running around telling everyone to do this one thing. If you’re going to follow NIST, you need to do all of it. MFA is a big part of why complexity is reduced in the NIST guide, and you MUST have it if you’re going to remove complexity requirements. If you can’t have MFA for some reason (and yes, there are legitimate reasons for this), then you still need to use complexity, expiration, etc.
I've done brute force exercises. Some people always pick bad passwords. Tell an organisation to change every 60 days and a lot more people give up and land on May2019!.
Every time I start in a new organization, I spend some time to sit down and make a very strong password. The kind of password I would trust my retirement savings to. I'll sit down and dedicate a solid 30 minutes to transforming a bizarre but easy to remember phrase in 20-30 special characters with abbreviations instead of full words. Then I'll spend the time to commit it to muscle memory. I've done this probably 30 times over the past 20 years.
60 days later, maybe I make another new very strong password. 60 days after that, it's 8:15 and my computer is forcing me to update my password and I have an 8:30 meeting and now my password is asdfg;lkjh. 60 days later it's asdfg;lkjh1. And so on.
Password expiration dates are one of those things that just don't work with human beings. It's the "work harder, not smarter" approach to security. Somebody wrote it down once, and now everybody who came along later copied the same bad checklist and added more bad things to it. Instead of working to improve the practical security of their system, they work to adhere to their arbitrary checklist. It only makes sense from the most cynical Dilbert perspective.
I have a complicated google password - I use it no where else. I have a security key. In 12 years I've NEVER had to change my google account password AND I have not been hacked. This works well. Because google is resistant to brute force I don't even bother adding tons of weird special characters.
I worked at a govt related agency. They had to change passwords every 30 days and there was a dual password requirement (one to login to the VPN, the next for the app). Result?
- Many folks used a shared account with a public password emailed out every 30 days so everyone else did not have to deal with all the hassles of the password expiration dance. It was also super hard to onboard anyone new (ie, 3-4 months for staff with 12 month projects) This account ended up posted next to every computer.
- Rate limit attempts - Block after 4 tries for an hour, after 8 tries till a reset - Screen against password lists - Screen out other obviously bad (ie, too short etc). - Allow hardware 2fa BUT allow staff to validate computer.
This alone gets you a ton of mileage
If you make your security policies into a problem for your people trying to do their work, they'll find ways to work around it.
That either means 1) your policies are misplaced and you need to relax then, or 2) you need to fire everybody who creatively works around them.
If your adversary is Mossad, the option 2 is the right one. If your adversary is not-Mossad, you can almost certainly have a security policy that people won't feel the need to work around.
There are, of course, shades of grey below "Mossad adversaries", but in my opinion at the upper end of that you have policies that include providing every employee with a good password manager, TOTP apps/devices, and/or USB 2FA keys - and choosing services which integrate properly with them.
"Change your password every X days" is an admission that you're going to leak passwords somehow, and that you only care about your data/systems enough to close the attack window down to X days. Which means you're screwed before you start, and may as well just turn everything off now.
Even without MFA the lack of password expiration is still considered best practice. It's not just parroting.
Separately though applying MFA anywhere possible is a best practice and should be separately encouraged from the strength and rotation policies.
That's completely contradictory to what the NIST guidelines state:
> The most notable form of these is composition rules, which require the user to choose passwords constructed using a mix of character types, such as at least one digit, uppercase letter, and symbol. However, analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought [Policies], although the impact on usability and memorability is severe.
aphiofsofdes68537513 is good enough and defeats a dictionary attack.
It requires discipline but I’m responsible for people’s PII at work and I treat that seriously.
For my personal stuff I keep a separate vault but with the same criteria.
If 2fa is involved it's a different story, but if you're talking about something liiiike the pass key of a private key that you can't guarantee is secret? Or if it's the private key used to do things like sign certificates? Please add randomness.
- No password that is part of a leak. It requires maintaining a database, or using an online service.
- No upper limit on length and character set. It requires full Unicode support and proper string processing.
> (links to https://www.digicert.com/blog/creating-password-policy-best-...) where they give the usual (at least 2 special characters, but not " or \) advice
This is counterproductive and is actually discouraged by the latest NIST guidelines, that prefer passwords that are easy to remember, but still hard to guess [1].
[1] https://auth0.com/blog/dont-pass-on-the-new-nist-password-gu...