Strong Passwords: Three Random Words

When performing security tests, we very often come across weak passwords. We often see dictionary words with suffixes such as Welcome1, Password123, or Lockdown2020. We also see “leet” substitutions, such as P@55w0rd, 3l3ph@nt, or L0ckd0wn. We’ve previously shown how quickly password cracking can be performed. With passwords like the above they would be cracked easily. Simple protections such as “Password complexity” don’t solve the problem on their own, for example complexity enforces the requirement for three of the following: uppercase, lowercase, numbers, and symbols – which all of the weak options above meet.

For password length, on this page Microsoft considers an eight characters a “good password” and on this page states a “strong password” has 12 characters, but adds “14 or more is better”.

It is clear that passwords based on a dictionary word, passwords using character substitutions, or contextual passwords such as those based on a company’s name are insecure. An additional significant factor is password length, the longer the better. We would consider anything less than 14 characters to be insufficient. A second factor is the character set, but the insecurity of a small character set is compounded by patterns such as 123, 2020, or using guessable features such as dictionary words or contextual words.

Instead of just a minimum password lenght, the NCSC recommends using three random words, such as “coffeetrainfish”, but does add that patterns such as “onetwothree” should be avoided as well as avoiding contextual words such as family or pet’s names.

The NCSC recommendation is a good one if the words are truly random, long and uncommon. “thebigdog” is a terrible choice with a limited character set and coming in at only nine characters. Whereas “perniciousscoundrelbovine” comes in at 25 characters and is much better. The length makes a full key space bruteforce infeasible. Although if an attacker focuses on combinations of three words and is lucky enough to have a weak hash such as an NTLM or NetNTLMv1 hash (perhaps captured through LLMNR spoofing), it could feasibly be broken.

Our hashcracking with AWS post shows a NetNTLMv1 hash of this nature would take up to about 8.38 days to crack, and an NTLM hash would take up to about 5.15 days. With most hashes being cracked in half that time. The cost would therefore be around $1000 to $2500. For most people we would expect that to be an adequate level of protection, for those looking for even more – we recommend adding another random word, bringing you to four random words.

If our maths holds up (we’ve shown our working below this post), that’d push the time to crack from 5.15 days, to around 2400 years.

It is true, that choosing very long and completely random passwords with a broad character set can achieve similar or better bruteforce protection – but they are harder to remember. It is also true that Password Managers make the task of remembering passwords much easier.

However, the balance of security offered and simple nature of the “three random words” format makes it easy to get the message across, even to non-technical team members, therefore it is our recommended approach for most situations. Where an exceptional level of security is required then four random words can be used.

That’s it!

Our Maths

1. We’re basing these figures on the the benchmarks we achieved using hashcat in benchmark mode on a p3.16xlarge, which cost us $24.48 per hour to run. Our benchmark showed the fasted crack speed was NTLM at 680.2GH/s. For our word count we used 171,476 words which is the figure given here for “words in current use”.

Putting this all together, we can crack 979,488,000,000,000 NTLM hashes per day (that’s 680200000000 times 60 times 24 to convert the per second hash speed to per day). There are 5,042,083,489,338,176 possible options within the keyspace (that’s 171,476 to the power 3). Now taking the number of passwords and dividing it by the per day speed we get 5.15 (taking two significant figures).