Are common passwords at particular risk?

Question

The question Should we disallow common passwords like “password” and “12345”? on User Experience immediately made me think that these common passwords were extremely dangerous not because they are weak but because they are common.

Rather to my dismay the security side of the argument seems focused on but if you ban them, users will use other weak passwords which is a partially valid argument, but surely actually using one of the most common passwords on lists like 25 Worst Passwords are significantly more at risk simply because they are common rather than the actual time it would take a brute force hack to guess them, right?

Is it realistic to assume attacks will focus on common passwords before brute force? In a world of rate-limited password entries and captchas, it seems likely that you'll only get 1-3 guesses at a password; guessing all 5 letter combinations isn't feasible, but guessing "password", "123456" and "qwerty" seems like a valid possiblity.

Answer 1

Some UX specialists says that it's not a good idea to refuse a password. One of the arguments is the one you provide : "but if you ban them, users will use other weak passwords", or they will add random chars like 1234 -> 12340, which is stupid, nonsensical and will then force the user to go through the "lost my password" process because he can't remember which chars he added.

You have two options. I like them both (I explain why in each) :

1. Let the user enter the password he wants. This goes against your question, but as I said, if you force your user to enter another password than one of the 25 known worst passwords, this will result in 1: A bad User Experience, 2: A probably lost password and the whole "lost my password" workflow. Now, what you can do, is indicate to your user that this password is weak, or even add more details by saying it is one of the worst known passwords (with a link to them), that they shouldn't use it, etc etc. If you detail this, you'll incline your users to modify their password to a more complex one because now, they know the risk. For the one that will use 1234, let them do this because there is maybe a simple reason : I often put a dumb password in some site that requests my login/pass just to see what this site provides me.

2. Add some rules, like "At least one number and one special char, must be a minimum of 8 long", etc. This will go against the worst password. On the other hand, if the user has a quite complex password that doesn't match one of your rules, it will result in a bad UX.

Finally, you have to choose between a good User eXperience or an improved security. Now it really depends on which kind of project you're building : if it's a basic website to upload pics of puppys, maybe you don't have to set up a complex security system. But if you're the next paypal, you should.

Regarding your question about brute force, it depends on how you set up the password storage. If you add a salt and pepper, brute force can be made against the database. If you add a captcha in the login page, or increase the time between tries and errors, brute force won't be possible.

It's possible that the attacker use the worst password first, but I'm not sure it would be quite efficient. Even if he choose the first 3 (regarding your rules about captcha and 1-3 guesses), this will greatly reduce the probability of hacking into an account.

Answer 2

What you're missing here is that most password attacks, where complexity is an issue (i.e.: attacks not involving social engineering), happen offline. This means that the attacker already has their own copy of the password database, and is able to run analysis on their own system freely without worrying about the target system locking them out. CAPTCHA and account lockout policies are ineffective against these attacks.

Dictionary attacks are much faster than brute-force attacks. So, yes it is realistic to assume that attackers will target "common" passwords before resorting to brute force. John The Ripper, perhaps one of the most well-known offline password cracking tools, even uses this as a default action. So, if your password is "password" or "12345678", it is very likely to be cracked in less than a minute. A randomly-generated (or, at least, not so common) password of equal length could take quite awhile longer.

Answer 3

It depends on the needs of your application and is not one size fits all. If the worst-case compromise scenario only affects the end user and is a minor inconvenience for them (and no inconvenience to you), a simple educational warning (this password is very weak) and allowing them to create the weak password is probably sufficient.

If your application needs to be secure like you are a bank, or you are an online merchant that saves customer's credit card details¹ (and credit card chargebacks mean are equivalent to theft + extra bank charges), or the account has administrator privileges, or ... , you should do your best to prevent accounts from having weak passwords and certainly not allow any popular password. I would create a sorted database of million+ most popular passwords taken from some online source (also including standard English dictionary), and check passwords against that in addition to checking that it passes some other minimum criteria; e.g., must be 16+ characters OR be 8+ characters with an upper + lower + number.

Very weak passwords (top 1000) can be randomly attacked online by botnets (even if you use captchas/delays after so many incorrect attempts). Dictionary attacks are very quick offline if your hash database was compromised somehow.

¹Note: a better solution may be to not save credit card details or at least require them to retype in the details whenever they attempt to use a new IP address.

Answer 4

I'm certain that attackers will use common passwords first before starting a brute-force attempt. Even if CAPTCHA's (and other detective/preventative) devices are in place, the list of common passwords are much smaller than words in a dictionary.

I'll take a different stance and suggest that it makes sense to disallow common passwords in most use cases. The strength of a password is tied to the difficulty for the adversary to obtain unauthorized access. The qualities that the community currently accepts as a strong password are based on difficulty for an adversary to obtain access whether by brute forcing, cracking, or other methods (i.e. pass phrases and mnemonic devices increases the difficulty for a passer by to memorize). XKCD represents this pretty accurately in this comic. Using different cases, symbols, etc increase the randomness of the password such that the attack would take longer to successfully execute and also increase the likelihood that attempts would be detected.

Looking closer at attack methods, the top 25 password, along with many others are commonly populated in dictionaries. Attackers are usually keen to common passwords and will often make an attempt to run through the short list first. It's similar to the common practice that many vendors ship devices with well-known passwords (i.e. cisco/cisco, admin/admin) and not forcing the change of the well known default credentials. From payoff perspective, it's usually worth trying the common passwords first. The only reason why an attacker might not take this approach is when the attack is targeted. In which case, the attacker may exercise more caution because s/he doesn't want to throw up red flags.

Taking one step back, I use the term "attacker" loosely. Attacker can mean a bot (or automated script), a script kiddie (un or less skilled), or a skilled individual. Many security arguments muddle the ground between protecting against the auto/unskilled and skilled attacker. Though the techniques used to detect and prevent auto/unskilled attackers usually follow common sense, the skilled attacker will likely be aware of traditional detection/prevention strategies and adjust their attempts accordingly. Assume that I'm referring to the auto/unskilled attacker unless I qualify the skill level.

Following the attempt to run through common passwords, additional on-line attack methods like brute force are more difficult to successfully launch if there are appropriate prevention or detection systems in place (i.e. access logs/audit logs, brute force detection). Alternatively, off-line attack methods require access to a protected password file - if an attacker can get access to the credential info (be it hashed, encrypted, or otherwise protected). Pen testers (whitehats) often follow the workflow of using known accounts to gain initial access to a system to gain deeper access into networks. Regardless, if an attacker has offline access to a credential store, there's bigger problems than just passwords.

The practice of security really involves making tradeoffs with accessibility. The less accessible system is generally more secure than one that is more accessible. The UX/UI person will pitch stories to make their lives much easier (more accessible system). The security person will have to pitch a less accessible system. Both will ultimately have to settle on a stance that's acceptable by the BU/sponsor. Combine the previous point with the tendency for most people to place blame (or perhaps lack of willingness to accept fault) and the principle that the squeakiest wheel gets oiled first. If the user is allowed free range in choosing a password, and an attacker gains unauthorized access and wreaks havoc, the "victim" first response will be "how did this happen?" Fingers start to point all over the place and often ends up at the person responsible for security with the question, "why did you let me choose this password?" I'm not claiming that this is common, but the individual responsible for security is ultimately responsible for pursuing policies aimed at protecting the users (and brand/employer). My point here is that sometimes it's not good practice to let users make their own choice about passwords.

Then again, the value access depends on the value of the information provided and identity of the user.

Answer 5

Is it realistic to assume attacks will focus on common passwords before brute force?

In my experience that has been the case. Though trying common passwords is just a different kind of "brute force".

The real underlying question is this: will attackers try an exhaustive attack against a single account, or will they try a very superficial attack against all of the accounts.

The answer to that depends on what the attacker wants. If he wants access to a specific (e.g. celebrity) account, then he will pound endlessly at that account alone; it's the only one of value to him. But if the attacker just wants access to any account, or to as many as possible, then it's much more reasonable for him to try only the most common passwords on ALL of the accounts.

In my experience in examining attack code found "in the wild" and currently in use, the password ordering is this:

1. Try the most common passwords first. Usually there's a list of between 10 and 500 passwords to try
2. Try dictionary passwords second. This often includes variations like substituting "4" where an "A" would be or a "1" where there was the letter "l", as well as adding numbers to the end.
3. Exhaust the password space, starting at "a", "b", "c"... "aa", "ab", "ac"... etc.

Step 3 is usually omitted, and step 1 is usually attempted on a range of usernames before moving to step 2.

Answer 6

Of course but that shouldn't be the question. The real question is: What can you do about it?

Not much. You can force users to use more complex passwords which will either make them write it down, drive them away from your service or make them mad (I have a very complex password with a special character that some password validators simply don't accept).

The root of the problem is that passwords suck, plain and simple. They are a simple solution for a complex problem ("Who are you?") and, as Einstein already knew 80 years ago, there are solution which are too simple. What users want is that their own PC identifies them "somehow" and that it manages their identity for them. So if you can, don't use passwords at all.

Prefer single-sign-on solutions like OpenID, BrowserID or similar services. This allows the user to remember one excellent password instead of a crappy one for every site or, worse, the same password for every site.

Answer 7

An attacker runs the first 5000 common passwords and brute forces the password. What you can do is make the password at least 9 characters long, with a upper case, lower case and special character.

If you are developing a system you can filter the data when creating an account. You should server side language and not client side language for that.

If you are a Microsoft System Administrator what you can do is create a Group Policy and enforce it to that restrictions which i mentioned and you can have other options too like password length, account lockout policy and many more.

check out Regular Expressions.