Is forcing users to use a strong password effective?

Question

I am designing a service that would, among other things, store sensitive information. To ensure no unauthorized access of this information, it would be encrypted with a key derived from their password (PBKDF2). The password will be stored in a BCrypt hashed + salted format in the database. It is never stored in plain text.

The nature of the saved information is such that a strong password is necessary. Some websites force their users to make up passwords with large entropy by enforcing strict character guidelines. These complex passwords can lead to password reuse on different websites [1]. This is A Bad Thing™ [2].

I would much rather have my users select a password that is both strong and not very likely to be reused or already in use on another, less secure web service. As such, I was thinking of using an XKCD-like [3] password scheme for my users in their native language.

The user would be presented with 4-5 different words from a large word list with more than 6 characters (no words with special characters included, just ASCII). The password input dialog would be formatted with 4-5 fields instead of the normal single field, to reenforce the passphrase paradigm. Upon registration the password can be regenerated at will, to give the user the ability to select a passphrase consisting of words that they can easily remember. The user can not enter their own words.

I know from personal experience that CreeperHost [4] already uses this method, albeit with a single password field with four concatenated English words.

My questions are as follows:

• Would this method be more secure/effective than allowing users to pick their own?
• Does anyone have any experience with implementing a similar scheme? Was it effective?
• Is dividing the password field into more than one distinct field benificial or does it expose too much information?

I am looking specifically for answers related to real-world application of this specific method, if there are any. I am familiar with the theoretical strengths and weaknesses of this method of password generation.

---

1. The Tangled Web of Password Reuse - http://www.jbonneau.com/doc/DBCBW14-NDSS-tangled_web.pdf
2. Password reuse - http://xkcd.com/792/
3. Password Strength - http://xkcd.com/936/
4. Creeperhost - http://www.creeperhost.net/

Answer 1

Allow any passwords. Just highlight consequences.

Your scheme is weird and alien to users and I believe many people would rather stop using your service than comply. Instead of letting them choose their own password, you're forcing them to remember one you chose for them. This is unacceptable to most people. You think that you're giving them a choice by "try again", but the difference in user experience is about same as ATM vs one-armed bandit.

Keep in mind that the biggest issue is human factor. What you should avoid in the first place is passwords being written on a whiteboard. These guys had a very secure password. And then it aired on TV.

If you want to ensure no one at your side would be able to crack it, then what you need are internal procedures, not monkey-training users. Maybe a system where access to salted passwords is protected by the same retry limits as the user login panel. Besides, it's not important to make it impossible for workers to gain access. Clerks in stores have unlimited access to cash registers. What prevents theft is awareness of unavoidable consequences. Use admin-session recording. Use "minimum 2 persons to access" procedures. This is how banks do it, because strong user passwords can't protect everything.

Answer 2

The specific questions:

Would this method be more secure/effective than allowing users to pick their own?

Yes. You will reduce password re-use and remove the very common passwords immediately.

Does anyone have any experience with implementing a similar scheme? Was it effective?

I've seen a lot of 'alternative' password schemes in the past. Most just added support problems and complications without substantially improving security.

Is dividing the password field into more than one distinct field beneficial or does it expose too much information?

I think you've already defeated the basic automated no-knowledge attacks simply by being different. That leaves a targeted attack. However if there's public sign-up available then the attacker can discover that you need 5 words or whatever. So I don't think you are providing the attacker with more information by splitting it into fields.

Obviously don't provide advice about which word(s) are wrong though if authentication fails - that will undermine the security!

More advice

There's lots of other good advice in other answers about usability.

If security and usability are important perhaps look at something better than passwords. SMS perhaps?

It's possible to faff around with passwords for ages and still not deal with the risks properly. Trojans on the users computer, authentication reset via e-mail accounts that get hacked, phishing ... there are things that no amount of messing with fancy password schemes and controls will address*.

If the data is important I'd do something better than a password.

(Sometimes you can be better off just generating a random password for the user and asking them to store it securely in a locked drawer. It depends on what the threats and attacks are you are worried about, and how the system will be used.)

*There's quite a lot to be said for the risk based two-factor approach google offer, where the two-factor authentication is triggered only occasionally. It controls cost and gives a great security improvement. But I'd outsource this unless you have a lot of time on your hands :)

Answer 3

You should read about Diceware. You can get 44 bits of entropy with four words from a much smaller list. If your list is 2050 or so words and you select without replacement, each word will be about 11 bits of entropy because log₂(2048) = 11. With 5,000 words you can get 12 bits per word. (log₂(4096) = 12)

I like the idea of a "try again" link that the user can click until presented with a combination they think they can remember.

One thing about your question bothers me. If the data are encrypted with a particular user's password, then only that user will be able to decrypt the data. If your data is stored on a per-user basis, that may be OK. Do note that if a user forgets his or her password, then the data are toast if the password is the crypto key. You really might want to consider an asymmetric key arrangement in light of this.

For access, do not separate the input into four fields. That gives an attacker information the attacker should not have. Just decide whether the words shall be separated by spaces or not and tell your users.

Answer 4

The problem I see with this approach is simply the non-conventional nature of it, which will reduce the likelihood of people even using it.

Personally, I would have to have a very compelling reason to use the service in order to put up with this, as opposed to traditional password entry. I've commented in the past that I think application developers have some responsibility to try to ensure that users use strong passwords. However; ultimately this is the user's responsibility.

Also consider that you're forcing the user to employ one particular method of ensuring password entropy. The XKCD approach is fine, but it isn't the only one and there isn't absolute, empirical evidence that it is the best, nor is there any assurance that if it is the best today, it will remain the best six months from now.

Do consider the use of password managers, which can generate very large, completely random passwords and enter those automatically for the user. You would likely break those applications with this approach.

Also, consider things like the grc.com password haystacks article, which claims that this:

D0g.....................

...is a stronger password than this:

PrXyc.N(n4k77#L!eVdAfp9

...simply because there is one extra character, despite the overall entropy (randomness) being fairly low, and it would take a computer 95 times longer to brute-force guess the password that is easier for you to remember.

The problem is that brute-force attacks are only really used up to a certain length of password (6 to 8 characters) because of the ridiculous computational expense as the passwords get longer. But even very complex short passwords are highly vulnerable to brute force. Newer attacks are hybrid pattern-based attacks that use compromised passwords as patterns within larger passwords. Powerful GPU's make this approach workable, and apparently it is highly effective. Simply padding a weak password with .'s doesn't appear to be a good solution.

Also see this article, Password complexity rules more annoying, less effective than lengthy ones.

So, at least some recent research indicates that the most relevant factor in password strength is password length, at least in part because passwords with a lot of complexity are just too much for most users, even if they're short. The XKCD approach helps ensure password length by making it easy to remember very long passwords, without those passwords being simple well-known patterns or phrases. That is (probably) it's ultimate strength--just the length of the resulting passwords. Having said that, I'm starting to wonder how long "correct horse battery staple" will hold up to newer hybrid pattern-based attacks.

Since there are other approaches to achieving the same result, forcing users into that one may actually be making your service more difficult to use without a commensurate payoff in security. Also, if some weakness is found in the XKCD approach six months from now, you are hard-wired into it and must expend substantial effort to change your service.

Answer 5

It sounds like a great way of preventing password reuse, although as you may be nudging users out of their comfort zone it might cause them to save the password into a text file so they can remember it. You should stress that the user must remember their password, or use a password manager in order to store it securely (if that is something acceptable to you and your system). I would also make sure the multiple field solution works with common password managers, although I cannot see any other issues with splitting the words this way.

As password manager functionality with several fields designated as the password may be difficult to implement, I would also give users the option of using their own passwords too, however you should state that user must only use securely generated random sequences, for example like those used in password generators included in Keepass or LastPass. To prevent a user from just entering the same password they always use, you could enforce a silly restriction just in the case that it is user entered to ensure it is actually unique. For example. 50 characters minimum, using at least 20 numbers and it must include lower/uppercase and at least one symbol. This will make expert users happy, while preventing weak passwords from others (although you may get some users padding their weak passwords with 45 "2"s and one "!"). You could try and detect cases such as these and then reinforce the message that this option is for use with password generators only, however there would be diminishing returns in putting so much effort into edge cases. The better choice would be to try and to explain to non expert users that the generated different words option would be more beneficial.

I am designing a service that would, among other things, store sensitive information. To ensure that no one on our side of the is able to retrieve this information, it would be encrypted with a key derived from their password (PBKDF2). The password will be stored in a BCrypt hashed + salted format in the database. It is never stored in plain text.

In order for a Password Based Encryption to be secure against offline attacks (e.g. the people on your side, or if access was gained by an attacker another way), you would need an entropy of 128 bits or more, which means you would need ten random words for this rather than four or five. Although, as you are using PBKDF2 to strengthen the key, this may give you 16 bits or so of additional entropy (depending on iterations), therefore only nine words are needed. My point is to make sure that you do the maths to ensure your encryption is adequate.

This would make it even more difficult for your average user to remember the passphrase, and if they used a password manager you may as well go for the 50 character option and let them log in that way. As others have pointed out, it seems this could potentially generate a lot of support requests and it is a lot of effort to develop only one part of a secure authentication and session management system.

Answer 6

Your method is interesting, but I think I don't like it.

1. You allow the users to "respin the wheel" until they find a password they like. If you did this with four-digit numbers, I'm afraid some people might spin again and again until they end up with 1234 or 0000. This would make the attacker happy.

2. Even though there are a lot of combinations, an attacker can restrict to trying passwords only of your prescribed structure (and in fact they can use your very service to determine what word list you use).

Answer 7

Before trying to implement any password policy you really should watch this great presentation by Rick Redman at AppSecUSA 2014 titled "Your Password Complexity Requirements are Worthless":

https://www.youtube.com/watch?v=zUM7i8fsf0g

He discusses cracking passwords using the similar patterns that all humans use to create passwords.

Answer 8

The user would be presented with 4-5 different words from a large word list with more than 6 characters (no words with special characters included, just ASCII). The password input dialog would be formatted with 4-5 fields instead of the normal single field, to reenforce the passphrase paradigm. Upon registration the password can be regenerated at will, to give the user the ability to select a passphrase consisting of words that they can easily remember. The user can not enter their own words.

This is going to be an issue.

This means that you have to have a list of the words that are being used in the password phrase, and that there is no deviation from that list.

If a hacker is able to get the list somehow, whether it be from brute force attempts or social hacking or whatever other way, then they have the list of words and it is that much easier for them to figure out the password.

If you instead make it so that a user can enter their own words and allow numbers and/or special characters, the password phrase will be much more secure and you will still keep them from using the same password as {everywhere else} because you are still forcing 4-5 words for the password phrase.

Couple of things (some of which were already mentioned)

1. Make sure the words don't repeat more than once
2. Don't allow them to repeat a word more than once (pass, word, pass, word)
3. Don't use the password as the key for encrypting the data
   • This is a very bad idea, especially if the user forgets their password and needs a password reset.
4. Don't use a password scheme
   • This leaves clues for a hacker to eliminate words and phrases, narrowing the field.