What considerations do I need to keep in mind when enforcing passphrases?

Question

According to XKCD: Password Strength, if the password consists of “four random common words”, it will be secure and memorable.

I want to make a web application and make users create their passwords in this way. Each password should have at least 16 characters and must be sentence of at least 4 words to make it more secure and memorable. But this will make the attacker know that all passwords are like that. Is this a bad idea?

What better ways are there to force passwords that are more secure and memorable at the same time?

What threat are you trying to protect against? If your user wants to use a 6 digit lowercase password, how does that make your threat more likely to succeed? If you have brute force detection on your site, and store your passwords securely, that should be more than enough for a web application. — JeffUK, Apr 30 '18 at 12:37
Just don't be too surprised when 50% of your user base chooses a variation of `Password1 Password2 Password3 Password4` and the other 50% chooses `correct horse battery staple`. Your site's decision to implement such a system is viewed as nothing more than a formality for using your site; the user does not appreciate security and just wishes to get in and achieve some task or another so their aim is minimal friction. — MonkeyZeus, Apr 30 '18 at 13:00
dup of: https://security.stackexchange.com/questions/6095/xkcd-936-short-complex-password-or-long-dictionary-passphrase — Nir Alfasi, May 01 '18 at 05:47
It would be super annoying if it didn't accept the 32 character random string generated by my password manager. — Matti Virkkunen, May 01 '18 at 08:09
By the way: consider [haveibeenpwned/passwords](https://haveibeenpwned.com/Passwords). This allows you to ban known leaked passwords (I believe this will cover a lot of the most common passwords...) — Bakuriu, May 02 '18 at 17:19

Peter Harmann · Answer 1 · 2018-04-30T12:32:21.163

54

It is not necessarily a bad idea. The attacker can know the password is in that format, considering the 4 words are random enough. But here is the thing, there are other good ways to make a memorable strong password. Limiting your users to the one you like is not very nice. For example I use password manager with truly random long passwords, which is even better than what you propose, but I could not do that on your site.

More importantly, if the reason you want to do this is to force users to use strong password, then generate the 4 words password for them. You can generate such password by having a dictionary, then choosing random number between 1 and the number of words in your dictionary and taking that word. Do this 4 times and you have a password. You can get inspiration here. This is important, as most users may not choose 4 truly random words, but instead 4 easily guessable words. In such scenario, this would be worse then letting them choose any password.

edited Apr 30 '18 at 12:32

answered Apr 30 '18 at 12:07

Peter Harmann

7,778
5
20
28

42

when creating password rules, one needs to remember; People are very clever when it comes to being stupid. They will find a way around the rules you set to make it easy. so goes the birth of Password1, P@ssword1... etc etc – TheHidden Apr 30 '18 at 12:09
@TheHidden well, that is why I suggested he generates the 4 words instead of letting the users choose. – Peter Harmann Apr 30 '18 at 12:18
Yea I know! I just wanted to put my 2 cents somewhere and it matched what you were saying – TheHidden Apr 30 '18 at 12:20
15

If you create a random password for your user, he's pretty much forced to write it down instead of memorizing it. If he's already using a password manager, there's no need for this. This might be worse than the original idea. – Esa Jokinen Apr 30 '18 at 12:23
3

@EsaJokinen I am not suggesting he generates a random password, I suggest he generates 4 words as he wanted them to use, like this site: http://correcthorsebatterystaple.net/ – Peter Harmann Apr 30 '18 at 12:25
2

That's better, but not what your answer says. Now that I read it again I can see what may have been your intention. You may want to improve this to be more clear on this. :) – Esa Jokinen Apr 30 '18 at 12:30
1

@EsaJokinen edited. Now it is as clear as sun :) – Peter Harmann Apr 30 '18 at 12:32
1

Generate the password on account creation as a suggested password. Have a password strength meter and reject anything lower than "strong" - your password would pass the criteria, but the user is still free to use a password manager or something instead. – htmlcoderexe Apr 30 '18 at 14:27
@htmlcoderexe I was thinking the same thing, the reason I did not write it down is, it is near impossible to do a reliable meter for password strength. And the question sounded like he wants to enforce it. As was mentioned, people are really clever when trying to be stupid. – Peter Harmann Apr 30 '18 at 14:34
Alternative to assigning a user a password, give them a list of random words with which they can make their password. A list of 16 words which the user can pick 4 and order them how they want will at least give them a chance of being able to remember it without resorting to Post-It notes. – David Starkey Apr 30 '18 at 15:43
1

@DavidStarkey you can remember pretty much any combination of words. Giving them such a choice reduces the strength of the passphrase quite a lot further. I would personally give them chance to request different password, but make it take longer time to appear. Probably 5 seconds. This way they can get reasonable password, but they will most likely not regenerate the pass too many times therefore not reducing the strength much. – Peter Harmann Apr 30 '18 at 15:46
Do not randomly choose words for your pass phrases. Have a dictionary of words, make it large, but remove words that may make unintentionally offensive combinations. For example when I made mine for account setup passwords some of the first words I removed were colors that mapped closely to human skin tones. (there may be lists of neutral words you can adapt.) – arp May 01 '18 at 02:14
Also remove homonym pairs as they are hard to remember especially if you use the less common version. – arp May 01 '18 at 02:15
The answer is similar to the approach 1Password takes for a passphrase. – Qsigma May 01 '18 at 09:19

score 13 · Answer 2 · answered Apr 30 '18 at 13:00

You are alluding to Kerckhoff's Principle. When we design cryptographic systems, we assume that the attacker will know everything about your system except for the entropy derived parts (Keys/passwords/etc, typically) - this is because we can't guarantee that they don't know details, but must assume that they don't know our generated keys. Any password generation scheme follows this reasoning - if a password scheme is said to be secure, then you can believe that an attacker knowing which scheme you're using isn't a problem.

The reason that it isn't a problem is due to the way that password namespaces work. If you demand that a user generate a password based off of a known diceware list, such as the EFF list, and you demand that it is at least 4 words long, then we can compute the namespace complexity.

First, we'll figure out the namespace of a single word - In the EFF diceware list, you roll five six sided dice and pick the result that comes up. Because there are five positions with six options, we can compute 6^5, which gives us 7776 - this simply means that there are 7776 different possible words for each place.

Now, we can compute the minimum namespace complexity of four of these words. This is simply done by taking the number of possible words and raising it to the power of the number of words in the password - 7776 ^ 4. This gives us 3656158440062976 (3.6 Quadrillion) possible different passwords of four EFF diceware words.

Now, to guess how long this would take, we have to make some assumptions -

You are using a good hashing algorithm - scrypt, bcrypt, PBKDF2, etc.
The attacker has consumer grade hardware. - We'll look at some benchmarks for an array of 8x 1080 TIs, which are top of the line at time of writing, but shouldn't be taken as the maximum hash rate - the NSA, etc probably has special hardware just for hashing passwords as fast as possible.

We can see from this benchmark that in OpenCL, an attacker with 8x 1080 Ti can attack good algorithms at the following rates:

scrypt at a rate of ~ 6.4 million hashes per second.
bcrypt at a rate of 184 thousand hashes per second.
PBKDF2-SHA256 at a rate of 775 thousand hashes per second.
SHA1 (just for comparison, don't use this for passwords) at a rate of 101 billion hashes per second.

So for our given namespace of 3.6 quadrillion possible passwords, we can compute the following expected times to crack - please keep in mind that on average, 50% of the namespace will need to be exhausted, not 100%.

scrpyt - 571274756.25984 seconds (~9 years)
bcrypt - 19870426304.690086956521739130435 seconds (~315 years)
PBKDF2 - 4717623793.6296464516129032258065 seconds (~75 years)
SHA1 - 36199.588515475009900990099009901 seconds (~.2 days)

So, we can see that you need to implement a good hashing algorithm as well.

Two things are missing from this algorithm - first, we didn't omit words shorter than 4 characters. The EFF diceware list has many words that are 3 characters long. If you increase the minimum word length, you reduce the namespace. I think the EFF list has ~500 words that are 3 characters long, but that's a guess. So, the namespace is slightly less complex.

Second, we treated these passwords are randomly derived. Because you instead wanted sentences, we need to keep in mind that sentences aren't random. If you want the sentences to make sense, then there are attacks you can perform against them - you can use Markov chains and other fun stuff to generate likely sentences rather than plain brute forcing the password. I have no statistics on how much easier this is than brute forcing, so I'm going to go ahead and say you should assume it makes a huge difference and is much weaker.

I think if you're going to calculate specifics on the time to hash the entire namespace, you should consider the implication of using salted hashes (which should absolutely always be done). That increases the hash namespace quite a lot. — Aaron, Apr 30 '18 at 17:57
(or rather makes it impossible to re-use hashes to crack more than one password at a time) — Aaron, Apr 30 '18 at 18:03
I believe scrypt, bcrypt, PBKDF2 all salt their own hashes auto-magically. — Monica Apologists Get Out, Apr 30 '18 at 18:23
According to wikipedia, those three algos specifically require a salt as one of the inputs to the equation. There may be libraries that try to handle some of that behind the scenes, but it is not possible to have a salt that is generated within a hashing function. — Aaron, Apr 30 '18 at 19:16
@Aaron I think you're correct, like for the Argon2 hashes with PHP; PHP will create the hash from just the password, salt and all, but the algorithm itself needs a salt given to it — Brian Leishman, Apr 30 '18 at 20:11
@Adonalsium: One of the reasons teh random words is good is because there's like 30k-60k of them. Don't make the idea weaker by excluding all of the shorter words. — Mooing Duck, Apr 30 '18 at 22:47
@MooingDuck OP required 4 words of 16 characters or longer in their problem statement. The reason I mentioned it was to more or less warn away from excluding 3 letter words. Also the EFF list is only 7776 words long. — Monica Apologists Get Out, May 01 '18 at 14:49

score 4 · Answer 3 · edited May 02 '18 at 00:34

4

You are not damaging the security of the passwords by telling the attacker that the password is at least 16 chars long, and comprised of 4 or more words. It's the same as telling that the password must have at least 10 chars, have at least one capitalized letter, one number and one symbol. Right?

With 4 words, the cost of a bruteforce is bigger than 10 random chars. If you ask the user to use at least one capital letter, the cost increases even more.

According to the Oxford dictionary, English have a little less than 175k words. There are 8.64 × 10²⁰ possible combinations. Using all 95 chars on an English keyboard, you have 5.98 × 10¹⁹ possible combinations.

edited May 02 '18 at 00:34

forest

65,613
20
208
262

answered Apr 30 '18 at 12:03

ThoriumBR

51,983
13
131
149

4

"With 4 words, the cost of a bruteforce is bigger than 10 random chars" Not true. – Peter Harmann Apr 30 '18 at 12:04
12

"With 4 words, the cost of a bruteforce is bigger than 10 random chars" This may or may not be true, depending on the size of the word list and character set. – Lie Ryan Apr 30 '18 at 12:09
1

Easiest case: 4 words with 4 chars each, one space between then, mixed case. 19 chars, 53 possible chars, 53^19 = 5.17E32. 10 random ASCII chars: 128^10 = 1.18E21. – ThoriumBR Apr 30 '18 at 12:10
5

@LieRyan You would need over 30k words in your dictionary to make it more secure. So maybe possible but unlikely. ThoriumBR your calculations are just plain wrong. The proper way to calculate the strength is in the xkcd comic. – Peter Harmann Apr 30 '18 at 12:15
7

@ThoriumBR but you do have to take into account other factors, I doubt the majority of peoples passwords would be "toTk uTpC lmen PQZt". it would most likely be "my name is jimmybob" – TheHidden Apr 30 '18 at 12:16
1

Ok, lets take the Oxford dictionary. It have 171476 words, and a 4 word password means 8.64E20. But you don't know if all users are using English words, and as you cannot count on users to use hard words, you cannot count on users taking password from the full Unicode charspace. – ThoriumBR Apr 30 '18 at 12:21
3

@ThoriumBR Well that is the thing, most people will not use 171k words in their dictionary. You will be lucky if they use 2k. But 2k would still be enough, if the are chosen truly randomly. That is why I recommend generating the password for them. And yes, few users may use other languages, but who cares? If it is a targeted attack, you know the nationality and if it is not, you just move on to easier target if they can't guess the one they are trying. – Peter Harmann Apr 30 '18 at 12:23
"If it is a targeted attack...": If is a targeted attack, the attacker always win. If it's not, 4 words is a large enough space for the attacker forget bruteforce, and leaked password lists are useless. – ThoriumBR Apr 30 '18 at 12:36
@ThoriumBR well, again, you are assuming if you show users a password form and say choose 4 words, they will actually choose 4 random words. That will not happen in most cases. I guarantee most people will have a guessable password just because they choose from only few very common words. – Peter Harmann Apr 30 '18 at 12:39
1

@PeterHarmann: You'd be surprised how few words 2k is.http://www.sciencemag.org/news/2016/08/average-20-year-old-american-knows-42000-words-depending-how-you-count-them says that most Americans are familiar with 27k-52k words. That 30k word mark is not a high bar. – Mooing Duck Apr 30 '18 at 22:51

score 3 · Answer 4 · edited May 02 '18 at 00:36

Memorability. A 4-word password will definitely be easier to remember than a random password, but that doesn't mean the average user will actually remember it without writing it down or using a password manager anyway (there are just too many different passwords to remember nowadays). So memorability is useful and is great, but it might not be as useful as you think.

Security. A 4-word password will be more secure than the average password only if the words are chosen randomly from a sufficiently large set of words. According to this article I've found the entropy of the password used by an average user is expected to be about 21 bits (2²¹ = 2.1 × 10⁶), which is worryingly low. If you choose 4 words randomly from a list of the 1000 most common English words, you would have 1000⁴ = 10¹² possibilities, so a password that is 1 million times harder to bruteforce than the average password.

So, generally speaking, your idea is not bad, as long as you don't let your users pick their own words, or they'll end up choosing passwords like "pass pass pass pass" or "1 2 3 4", etc. And of course, this is all speaking in general, because there are definitely specific cases where your method would actually decrease the security of the password. For example, your method would decrease the security of my password because I tend to use long random passwords by default, so if you forced me to use your method on your application I would be using a less secure password than usual. The same is probably true for communities like this one, where I hope the average password entropy is far greater than 21 bits and probably greater than your 4-word passwords.

score 3 · Answer 5 · answered May 02 '18 at 03:04

You can't force users to use passwords that are secure and memorable.

This answer to a related question summarizes the comic as emphasizing that the human aspect of password policies, not the computer aspect, "should often be the overriding concern".

@Adonalsium's answer covers the computer aspect well. Using diceware is relatively good for the human aspect without being bad for the computer aspect, so it's an acceptable way to generate passwords.

But if you want memorability, you cannot dictate to users how to generate passwords. Nor can you require that they use passwords you generate for them.

There are a few obvious things to avoid, like restricting password lengths to something unreasonably short, requiring characters from a particular list (like digits or punctuation), or prohibiting characters from a particular list (like spaces or quotes). So how can you avoid those but still require secure passwords?

You need to estimate a lower bound on entropy of the entered password, and set your policy to only accept passwords with an estimate above some minimum (possibly based on the desired minimum crack time). The only such estimation tool I know of is zxcvbn (which unfortunately doesn't reject "correct horse battery staple").

This will allow the use of relatively short randomly generated passwords and of relatively long diceware passwords, without requiring either, or allowing either to be inadequate. The user can choose the method best for them, and you can require the level of crack-resistance you need.

Generating and recommending diceware passwords might be helpful, and I think it's a good idea, but I would have to make sure that process didn't introduce new vulnerabilities before I would use it myself. (Another thing to provide links about, if you do it.)

(I'd also be inclined to have a password security chaos monkey constantly try to crack your users passwords, and force a reset whenever it succeeds. But I'm not sure if that would actually succeed on weak passwords more often than unlucky passwords.)

Although zxcvbn does not contain a comprehensive dictionary, it can at least provide a visual indication to your user when they are moving in the right direction. It could also be extended and improved... — joeytwiddle, May 02 '18 at 06:38

score 2 · Answer 6 · answered May 02 '18 at 08:32

My advice is don't. I will not even discuss whether it will enforce password security (you already got a comment about 32 random characters password generated by a password manager), but more the effect on global security.

You are adding a constraint for end users. Some (uneducated) always use same password. They hardly remembered it and do not want to be bothered by a new one so they will not use your web app if they can. Other will say: that is a nice idea, but I will not be able to remember that for a long time... let's write it down on that sheet! Those that are used to a good password manager will say how stupid it is that I cannot use my random generator! and again will avoid the app if they can.

The only use case where I can accept password rules is for the main password in a corporate environment. Employees are supposed to use it everyday (every working day...) and only one is normally needed, thanks to Single Sign On solutions, so remembering it should not be a problem. For all other use cases, the end user is assumed to be responsable for his/her own data and my opinion is that anything above a minimal length is an annoying constraint, and I will try hard not to use that site.

score 1 · Answer 7 · answered May 01 '18 at 14:19

I don't think you can have useful password enforcement of this. The strength of the XKCD method AKA diceware depends on the words of the phrase being random. Four chosen words, particularly four chosen words that make a sentence are a very weak passphrase and there is no way to check whether the words they enter are random or chosen.

score 0 · Answer 8 · answered May 02 '18 at 16:07

Don't, but do give the user that is trying to set a thoroughly insecure password a warning and make them confirm they really want to set it.

Forcing people to set a password that is above what they can memorize will not only have them write it down, but write it down haphazardly and in an insecure place.

Also, in some organizations, the ability to use a secure (by complexity) but shared (among an authorized team) and/or predocumented (under lock and key) passphrase is desirable - password guidelines that reject some reasonably secure passwords can become a real annoyance here. Usage scenario: "Please set the complex passphrase this team uses for all vendors of type XYZ, so that there will be no hassle in case another member of this team needs to urgently access it in your absence".

score -1 · Answer 9 · answered Apr 30 '18 at 13:22

What better ways are there to force passwords that are more secure and memorable at the same time ?

Two things pop my mind (both related with increasing the password "alphabet"):

1) It is unclear in your post whether or not numerical and special characters are permitted. Assuming it is not, that would leave you with an alphabet of only 32 different characters. I would include and also actively motivate your users to use them.

2) Assuming you would only use English words, an attacker has two straight forward attacks. (A) brute-force each individual character or (B) brute-force each individual 4 words based on an English dictionary. Considering that large part of the world's population have English as second language, motivate your users to mix languages.

What considerations do I need to keep in mind when enforcing passphrases?

9 Answers9