31

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?

  • 8
    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
  • 68
    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
  • 33
    It would be super annoying if it didn't accept the 32 character random string generated by my password manager. – Matti Virkkunen May 1 '18 at 8:09
  • By the way: consider haveibeenpwned/passwords. This allows you to ban known leaked passwords (I believe this will cover a lot of the most common passwords...) – Bakuriu May 2 '18 at 17:19
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.

  • 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
  • 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: 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
14

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 -

  1. You are using a good hashing algorithm - scrypt, bcrypt, PBKDF2, etc.

  2. 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:

  1. scrypt at a rate of ~ 6.4 million hashes per second.
  2. bcrypt at a rate of 184 thousand hashes per second.
  3. PBKDF2-SHA256 at a rate of 775 thousand hashes per second.
  4. 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%.

  1. scrpyt - 571274756.25984 seconds (~9 years)
  2. bcrypt - 19870426304.690086956521739130435 seconds (~315 years)
  3. PBKDF2 - 4717623793.6296464516129032258065 seconds (~75 years)
  4. 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. – Adonalsium Apr 30 '18 at 18:23
  • 4
    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
  • 2
    @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. – Adonalsium May 1 '18 at 14:49
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 × 1020 possible combinations. Using all 95 chars on an English keyboard, you have 5.98 × 1019 possible combinations.

  • 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
  • 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
  • 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
3

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 (221 = 2.1 × 106), which is worryingly low. If you choose 4 words randomly from a list of the 1000 most common English words, you would have 10004 = 1012 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.

3

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 2 '18 at 6:38
  • @joeytwiddle, the visual indication is the easy part! – ShadSterling May 2 '18 at 13:20
2

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.

1

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.

0

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".

-1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.