Complex password rules - is there any sense?

Question

Let us assume that our system is well designed and it limits the amount of login errors so that brute force attach on the user interface is not possible. Say after 5 failed logins for an account the account is disabled for 30 mins and IP blocked if you try too many different usernames.

Now, is it at all a realistic risk that someone would be able to guess someone else's password?

It is not the user's task to prevent the hashed passwords from leaking, so don't start with 'must have entropy, so that password hash is hard to break'. If an attacker can get the password hashes to their hands, they for sure can read everything and do anything else in the system as well.

***** <--- unmasked, this a very common word, include it in your answer, if you think more entropy is needed. You have 5 guesses.

Answer 1

Two points to note:

1. It is good practice to assume that other security steps have failed. You can' say that insecure passwords should be allowed because sites shouldn't allow details to leak, or that you should assume that there are brute force protections in place. Password requirements require users to deviate from established behavior and create passwords which are further towards the edges of the bell curve of frequency. The less common the password, the harder it is to break in a dictionary attack. Increasing entropy fends off brute force.

2. Using the argument that "I can make a word that you cannot guess, therefore the general rule should be to allow everyone to make their own free passwords" is a fallacy. Most people do not make passwords assuming adversarial intent. They make passwords based on what they can remember, and security is a secondary concern. Password requirements force the consideration of security, or force them not to use the frequent offenders of password lists.

Password rules are one level of multiple levels intended to keep people secure, under the assumption that others fail/are not followed, the more of these we have, the more likely we'll actually make enough work to matter.

Now, the relative benefit of password complexity rules in comparison to other routes of similar effectiveness is another question entirely, but the question of whether they are better than no requirements, then the answer is yes.

Answer 2

EDIT - Hey down voter(s), checkout the paper. I'm guessing you're afraid of a reasonable debate in this space. Perhaps, we as a security community are inflicting unnecessary pain on our users. Is it worth exploring?

I've always wondered about password rules and felt they might not be needed.

This paper argues (quite effectively) that we should reconsider secrecy of the UserID and dump complex password rules. That is, do not use public information (like email address) for User ID and instead have the organization assign a user ID. If you consider the total entropy of the account, i.e. log(UserID)+log(Password), then a larger and not easily guessed User ID works against an attacker, meanwhile the User can set their browser or their app to remember the User ID. User can also keep a file (encrypted or not, it doesn't matter) with site/application/user_id mappings on the computer.

If you want to argue that this leaves the user open to malware attacks, well, then, complex passwords won't stop that, either.

If you want to write the ID on paper, then (1) lock it in a drawer (at work/home) or (2) leave it hidden somewhere near the computer (at home). A Real Attacker (tm) with physical access to a computer has many options beyond needing a user id (or even a password). Physical key loggers, disk copies, single user and external drive boots, etc. If the computer is at home, a human close enough to steal a user id off paper (locked away or not) is the least of the computer owner's worries.

Still, keeping an electronic copy of the User ID on the computer is just fine. We are defending against the most likely attack here (password guessing over the interwebs), not the least likely.

One of my financial institutions does this (assigned account ID) and allows a numeric password. I feel my account is quite safe.

Answer 3

I am going to add onto Jozef's answer, what he said was correct.

Your premise that "If an attacker can get the password hashes to their hands, they for sure can read everything and do anything else in the system as well." is incorrect. Yes, an attacker may have dumped the table containing all of the hashes, but if there is a complexity rule in place, the attacker will have a much harder time cracking the hashes. Also, if a competent hashing algorithm is in place, such as bcrypt, one won't have to worry too much about their password being cracked before the site realizes that the datatable has been dumped. In this scenario, your password would be changed before having anyone gaining access to your account.

Also, assuming your 5 character password is hashed with md5, a computer set up with Hashcat could crack that password faster than one could say "Complex Password".

Answer 4

Imagine I have a botnet controlling 100 computers. If I don't care which user to crack (I just need access), then each computer will have 5 attempts * 3 users (let's assume) before its IP will be blocked. That alone gives me 1500 guesses, enough to crack some of the weakest passwords out there.

Since blocking IPs for a long time doesn't make sense (for example, on my server I block IPs for 10-30 minutes only), the botnet will be able to retry the same attack tomorrow with another 1500 guesses.