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.

  • 7
    Actually, it's entirely possible for an attacker to only have access to password hashes, without being able to do anything else - imagine a login system using a database, with a dedicated login data user, which can only access that table. Have seen this arrangement live, with SQLi on the login form - can read that table, and do nothing else. Also, your setup allows for a targeted denial of service against specific users - every 30 minutes, I send 5 random login attempts. They can never log in...
    – Matthew
    Commented Dec 3, 2015 at 15:45
  • 2
    While I agree that It is not the user's task to prevent the hashed passwords from leaking, it is the user's problem if their hashed password is leaked. So asking the user to partake in minimizing the cost of such a leak seems reasonable to me. Commented Dec 3, 2015 at 16:52
  • 1
    Similar question here: security.stackexchange.com/questions/72343/…
    – R15
    Commented Dec 3, 2015 at 17:06
  • Pretty sure your password is: 12345 ... Just saying.
    – aslum
    Commented Dec 4, 2015 at 19:25

4 Answers 4


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.

  • 1
    An assigned UserID will be difficult to remember. These will be written down which is security a problem if you consider it part of the entropy, right?
    – Silver
    Commented Dec 4, 2015 at 9:50
  • See edited answer for ID on paper. Commented Dec 4, 2015 at 15:56

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.


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


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.

  • Imagine I have one computer and I click on the Register link... Commented Dec 4, 2015 at 9:12
  • 1
    Are you implying that users have no useful information in their accounts, so you just can create a new one? Why have passwords at all then? Commented Dec 4, 2015 at 9:15
  • See Section 4.2, Lockout Strategies, in this paper. Commented Dec 4, 2015 at 16:00
  • @AndrewPhilips Authors of this paper don't seem to know that IP addresses are a shared resource, so a single infected computer may effectively lock out legitimate users connected via the same ISP. Commented Dec 8, 2015 at 15:36
  • @DmitryGrigoryev, that is a problem, in general. However, check out 2nd paragraph in that section. They point out that one could breakdown failed logins btwn previously successful IPs and new IPs. So, this only falls down when an ISP is using NAT for lots of users and an attacker resides within the same NAT'ed IP as the legitimate user. Commented Dec 8, 2015 at 17:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .