Should password be set by users without security check?

Question

I'm guessing if I should let my users choose their password without checking if there's at least 1 $pecial charact€r, 1 CAPLOCK, 1 numb3r...

Shouldn't we just ask users to put a minimum of X characters (6 or 8?) and let them choose their level of security?

Answer 1

There are several things to consider here:

firstly is the way human beings create passworsds:

Firstly, users will just append a 1 or an ! to their favourite insecure dictionary password, or capitalise the first letter. This is a human trait called satificing (http://en.wikipedia.org/wiki/Satisficing#Decision_making). This human behaviour of aiding memory while just satisfying the rules immediately renders the 'x xxx xxx years of a desktop processor to crack' calculations nonsensical.

Secondly, you provide a mental hurdle for the user when they come back to get into your site again as the password they use for everything that isn't too serious is not working. All you've then done is given the user an extra conscious thought and possible mistake to overcome to get back into your site. This is the against the essential premise of 'Don't make me think' by Steve Krug.

You also have the added problem of obfuscation, as virtually all password fields are starred out all of the time, so visual memory is also taken out of the equation.

So your user is never going to use '642HfD77sk*7' they are going to use 'madonna1#' or '!sarah1957' or something else memorable and personal. You could probably brute force an account belonging to a close person like a parent by hand with a spreadsheet and a day or two, even if the passwords required numbers and special characters. Here are some examples of popular passwords from recent database hacks ... http://netforbeginners.about.com/od/scamsandidentitytheft/tp/The-Most-Common-Passwords-2011.htm and again, from an attack on Adobe: http://www.bbc.co.uk/news/technology-24821528 ... the same group that selected 'adobe123' en masse is not suddenly going to select a random string of keyboard symbols if required to use numbers and special characters.

this article discusses some of these points also: https://medium.com/building-things-on-the-internet/a0c3eb525200

next is the number of possible types of attack you negate with the use of a strong password

There are many security issues with websites ... three immediate examples, that will gain passwords, are database breaches where millions of passwords are stolen in one go from the source; social engineering, where the user (or their representative) hands the password over without realising it; and phishing / spoofing, where the user is convinced they are using something legitimate when they are not. Not to mention that many people keep a list of password in their wallets / on their desks at home, waiting to be physically stolen. Then we get into the other possible security breaches, like unscrupulous employees, XSS and CSRF, so by insisting on a secure password you are not negating a great deal of potential risks.

The next consideration is how secure does your site have to be

Following on from @BennySkogberg's answer, where serious security is required the developers do take responsibility for the security of their users - and so must you.

Services like paypal and online banks, who protect serious information, use many other sophisticated ways of protecting your account. They monitor alsorts of other things, like the purchases I make, and will lock the account down in the case of suspicious transactions. In these cases the password is not a large part of the security - it basically stops opportunist access from others using the same devices as me. They still require special chars, but considering the first point it's obvious that they have other ways of stopping any brute force attack.

So, in conclusion:

When you put these three points together it is obvious that it isn't really necessary. If you are storing serious data about someone then you have many other threats and should have many other tactics up your sleeve (though you probably should still enforce in order to look secure and avoid bad PR), if not then you shouldn't increase the cognitive load on the repeat visiting human. In almost all cases making things nicer for the repeat visiting human should come out on top.

But, if you must do it, then you please also publish a reminder of your password rules on your login screen, i.e. 'we made you pick a password with at least one special character', allow the password to be created and entered in plain text and provide very good password reset.

Answer 2

High password entropy protects against brute forcing passwords. It does not protect against any other attack against passwords. Your first task should be to ensure that the passwords will not get stolen from your servers and that you have proper timeouts. With regard to password policies my stance is as follows:

1. Do not store passwords in plain text. If you store encrypted passwords ensure that they are salted.
2. Do not force your user any special characters since you do not know what keyboard they have.
3. Do not prevent your users from any special characters and do not artifically restrict the length of the passwords. If I chose I need a high entropy password then the site must not restrict me. 100 characters should always suffice.
4. If you want to enforce high entropy implement an entropy estimator and check versus the entropy.
5. Do not have trivial fallback questions for lost passwords (e.g. mother's maiden name). If you need to have fallback questions ensure that users can create their own.
6. If you need elevated security forget about passwords as the only security measure. Passwords are very easy to circumvent no matter how long they are.
7. Add an option to make the password visible while typing. If a user is sure nobody is watching, why make it harder to verify if the password is properly entered?

Answer 3

You are responsible for the security of your site! Not your users. That’s why you determine how high security level on passwords your site requirements demand. If its $pecial Ch@racters, Num83r5, length of password, UPPER CASE or lower case. You decide, not your users. They shouldn’t determine security level against dictionary lookup password attacks – you do.

In an empirical study this morning I tried three different passwords on the site How secure is my password?, which illustrates the importance of characters and length. On first trial I used one of the worlds most common passwords 1234

If I let my users use this password, I would leave there account wide open to anyone. Not a really good option. So I tried another combination which IT departments often use provide first time passwords to new users. The password Winter2014! gives this acceptable result

Six years for a computer, that's quite nice. But if we throw in a whole semtenece? With only lower case letters? Let's try whatisthematrix

13'000 years? For a computer? Very nice. Password length is obviously critical!

And if we replace i with 1, a with 4 and s with $, leaving us with the following password wh4t1$them4tr1x - this is the result:

No comment needed.

More technical notes

Consider the following answer (by Tom Leak) to the question form our sister site Information Security: What technical reasons are there to have low maximum password lengths?

Take five chimpanzees. Put them in a big cage. Suspend some bananas from the roof of the cage. Provide the chimpanzees with a stepladder. BUT also add a proximity detector to the bananas, so that when a chimp goes near the banana, water hoses are triggered and the whole cage is thoroughly soaked.

Soon, the chimps learn that the bananas and the stepladder are best ignored.

Now, remove one chimp, and replace it with a fresh one. That chimp knows nothing of the hoses. He sees the banana, notices the stepladder, and because he is a smart primate, he envisions himself stepping on the stepladder to reach the bananas. He then deftly grabs the stepladder... and the four other chimps spring on him and beat him squarely. He soon learns to ignore the stepladder.

Then, remove another chimp and replace it with a fresh one. The scenario occurs again; when he grabs the stepladder, he gets mauled by the four other chimps -- yes, including the previous "fresh" chimp. He has integrated the notion of "thou shalt not touch the stepladder".

Iterate. After some operations, you have five chimps who are ready to punch any chimp who would dare touch the stepladder -- and none of them knows why.

---

Originally, some developer, somewhere, was working on an old Unix system from the previous century, which used the old DES-based "crypt", actually a password hashing function derived from the DES block cipher. In that hashing function, only the first eight characters of the password are used (and only the low 7 bits of each character, as well). Subsequent characters are ignored. That's the banana.

The Internet is full of chimpanzees.

Conclusion

So what do we do? It's irresponsible of us to compromise safety, and at the same time we need to make the site accessible and useful bringing he best user experience to our visitors. If we cannot implement a third party login option (Facebook, Twitter, LinkedIn, and OpenID) which would be the best option - I'd suggest the following:

• We chose level of security, not our users.

• If a user uses lowercase only characters, the minimum length would be 12 characters.

• If a user uses at least one character in upper case, numbers or symbols, the minimum length would be 10 characters.

• If a user uses at least two characters in either upper case, numbers or symbols and not two of the same, the minimum length would be eight characters.

This would be a delicate compromise between security and user experience.

Answer 4

Users should be encouraged rather than forced to pick a strong password. A minimum length of 6-8 characters is fairly standard practice and most people are used to it by now. Forcing the user to follow arbitrary rules, such as must include at least one uppercase letter and one special character only serve to frustrate users who are capable of choosing a secure enough password on their own that does not follow the dictated pattern. If I'm signing up for a message board, the level of security I want is quite different from what I want for my bank account. Don't make me use a bank strength password for a message board.

According to How secure is my password?, a password such as "myreallysecurepassword" would take 106 trillion years to crack, while a password such as "password12" would only take 10 days and "Password1!" would take 58 years years. They also warn against the use of common passwords such as password and password1.

If you're allowing an attacker to sit there and brute force an account for 10 days, password strength is the least of your concerns (these people are costing you money and sapping server resources). Authentication needs to be throttled, such as locking the account for 5-10 minutes after a certain number of incorrect guesses. Unless the user does not have access to the email address that's associated with their account, using the password recovery feature would be faster for them than to continue guessing passwords.

Answer 5

I recently wrote about designing for security fatigue that addresses this question somewhat.

Shouldn't we [...] let them choose their level of security?

Emphatically no. As the site owner/designer you must understand the minimum level of security needed to protect your users.* If you are storing credit card details of personal information this level might be quite high, if you are asking people to log in so you can personalised their experience the required security level can be low.

Users will generally not fully understand the security risks involved in an account being hacked and how the information gained could be used to hack other more important services, so if you want your users to choose the level of security they are comfortable with (above the minimum that you have set) then you must do something to educate them about the risks.

*There are potential legal implications if you around data protection legislation and PCI requirements if you don't.

Answer 6

The problem with people choosing and remembering good passwords is one of psychology. Passwords are scary and confusing, because people are afraid to write them down, and they're hard to remember when they have to have letters and numbers and symbols. Instead of prompting your users to choose a short and complex password, consider this question:

Please choose a pass phrase of at least four words and type it here:

It eliminates the scary wording of "password". It makes it friendly and human accessible. And you can enforce it by requiring the entered string be at least 16 characters long - which, if someone was actually using a secure password, would be a fairly safe length.

Answer 7

First, I would argue that the bigger problem isn't user account password but rather admin as those are the ones that get cracked and then expose thousands of accounts and passwords. I would then argue that social engineering attacks will expose many users data because birthrates and last 4 of social really are easy to find if someone targets you specifically.

If you implement protections such as lockouts after 3 false attempts, wouldn't you discourage the majority of user account attacks? Implement 2-step verification and you reduce attacks even more. You could add something like an image check similar to what Bank of America does just to add more protection. With cracking techniques Ars Technica Article many passwords that are based on dictionary words will be discovered very quickly as well as thousands that have proven popular over the years.

Lastly, educate your users about security when they are setting their passwords. Remind them not to use recovery questions that are easily found on Facebook or from their trashcans. Encourage them to use a tool like 1Password to help make all of their accounts secure because they probably reuse a few strong passwords that then means any crack on any site exposes them all.

Answer 8

“Be Secure or Be Sued”
Silicon.com, 16 Nov 2000

Not only you should force users to choose a secure password but also you should keep them updated with security messages/warnings. Why? Because if somethings goes wrong then you are the one which is responsible.

Let me give you some examples.

At February 8th 2000, Yahoo! was under a DDoS attack. And, here is the court result for Yahoo!:

“There is a distinct probability that if your site has been hijacked for a denial of service attack, then you could be liable for damages. I would definitely advise clients they have grounds to sue.”
Nick Lockett, e-commerce lawyer at Sidley & Austin

Or the German bank which was sentenced for a fraud based on DES.

You can find similar examples whole over the Internet.

Answer 9

I agree with Benny Skogberg. You are responsible for the security of your site. But not by forcing users to use $pecial PASSw0rds. You must provide sufficient infrastructure to avoid brute force attacks on any user account.

In normal attacks there is an IP address that try hundreds of password to crack an account. So you can simply block that IP address. But in extended attacks such as DOS there is a lot of IP address that try to crack an account. So blocking an IP address is not sufficient. In this case you can detect the attack on a account. And then restrict access to that account (e.g users required to enter a catpcha code).