As a developer and/or user, do I really need to worry about password strength if the system does not allow brute force attack to be feasible (implements a delay or attempt counter) or implements a two-factor authentication mechanism?

As a user, if the system gives me assurances that the password is not stored in plain text, the database cannot be easily hacked or accessed, can I relax and select a "simple" password?

As a developer, if the rest of the system is implemented to protect the user's "simple" password (maybe by including a two-factor authentication mechanism that uses out of band communication, and/or by encrypted database), what is the point of annoying the user by forcing him/her to select long complex passwords?

  • not sure if password strength is the key, I believe the key is to force the user into using passwords that have no relation with their personal preferences or information.
    – user17464
    Dec 20, 2012 at 5:44
  • There is no objective answer. If the password protects your bank account you will have a different risk tolerance than if it protects your pandora profile. I think the challenge is out of scope for this site.
    – MCW
    Dec 20, 2012 at 11:38
  • 1
    I removed your call for attacking Google's email service as this is illegal in many countries. Dec 20, 2012 at 21:42

5 Answers 5


There are two important risk categories here:

  1. Attacks on the live system (e.g. guessing a user's password)
  2. Attacks on offline password hashes (e.g. from a database dump)

The first type of attack can be split into various sub-categories:

  • A brute-force attack on a user's password.
  • Guessing the top 1000 most-used passwords on one user's account.
  • Guessing the top 3 most-used passwords on 1000 users's accounts.

Password complexity requirements largely solve the last two categories, and makes the brute-force style attack much harder. When combined with proper rate limiting, all three categories can be effectively made infeasible. Traditionally the "live system" attacks were the primary driver for stronger password requirements.

The second type of attack usually occurs after your server is compromised. Despite everyone's best intentions and efforts, sites and servers do get hacked. You can't protect yourself from every possible attack vector, and that's a given in the world of security. You will get hacked at some point.

There are three major problems with having a database dump stolen:

  • Private user data is leaked, often consisting of personal information.
  • User passwords are leaked, either as plain text (if you're not doing your job!) or as a hash.
  • Users re-use passwords across different services.

You cannot stop the private user data from being leaked. Attempting to reversibly encrypt or obfuscate the data in the database just leads to a layer of complicated abstraction in your code, and provides little or no security benefit. The best thing you can do is have rigorous quality assurance testing and security testing performed on your products, services, and infrastructure, in order to minimise the risk of having the data stolen.

However, you can protect the users' passwords. By hashing the passwords with a one-way cryptographic function, we can make it difficult for an attacker to discover the original plain-text password.

Standard techniques using MD5 or SHA1 alone were discovered to be flawed, since large databases (called rainbow tables) could be pre-computed ahead of time, allowing an attacker to look up a hash value in a table and find its corresponding plain-text password. This technique was combated using salts, which aim to make each hash unique to the user by introducing a per-user unique random value, which made rainbow tables infeasible. Attackers later discovered that hash functions could be computed in a highly parallel way by GPUs, using technologies like OpenCL and CUDA. Instead of a few million hashes per second on the CPU, attackers could now compute billions of hashes per second on a GPU, or hundreds of billions per second on a GPU cluster, all utilising nothing more than off-the-shelf consumer hardware and freely available software. This means that a pure sha256(pass+salt) type of hash is no longer secure. The alternative is a key-derivation algorithm that is designed to be slow, such as PBKDF2 or bcrypt. These are more difficult to compute on parallel devices like GPUs, and reduce the number of computations per second down to a level that makes a full brute-force infeasible. However, dictionary attacks will still be reasonably feasible, especially if common passwords are used.

So, in conclusion: no, I don't think we're putting too much weight on password complexity requirements. The attack vectors involved are complicated, and the computational power available to people today is high enough to make common passwords dangerous no matter how slow and computationally expensive the key-derivation function is. Users re-use passwords, so we must protect those passwords as best we can.

  • 1
    I am not arguing that we should not strive for up-most security, I'm just wondering if the efforts are misdirected at forcing the user to select a complex password even when the the back end is secure (good physical and logical security, database encrypted, password salted and properly hashed). If the system only allows an attacker to guess the user password at a very slow rate (maybe an exponential wait between failed attempts) or by using a two-factor authentication, aren't complex password requirements superfluous?
    – Drew Lex
    Dec 20, 2012 at 8:08
  • @DrewLex That's the point: you can't rely on the rate limiting because you will get popped at some point, and you can't artificially rate-limit hash cracking. Plus an attacker using Tor or a botnet has a huge supply of IPs, so can attack a large list of users with a set of common weak passwords. Complexity requirements are mandatory.
    – Polynomial
    Dec 20, 2012 at 8:31
  • Hash cracking becomes an issue IF the database is compromised, and only if the database uses a storage method for the password that is not exponentially impossible to reverse. So if we mitigate this risk at the back end, why alienate the user with complex password requirements?
    – Drew Lex
    Dec 20, 2012 at 9:15
  • For two reasons: First, because "exponentially impossible to reverse" doesn't make any sense in the context of password cracking - an attacker can always buy more GPUs, or attack the weak passwords first. Having PBKDF2 hashes with ten million iterations is great, but it's useless if your users have a common password like "monkey". Second, because you will get hacked. It's inevitable. Even if your web app is 100% secure, with no bugs, you can't possibly prevent every 0day for your OS and services. Security is about defence in depth and risk reduction, not 100% guaranteed protection.
    – Polynomial
    Dec 20, 2012 at 9:21
  • 4
    Keep in mind that I'm not in favour of bad complexity requirements like "must have 1 letter, 1 number and 1 symbol" - these are pointless. A lowercase alphabetical password with 25 characters is much more secure than abc123!, yet it wouldn't pass validation. A better solution is to blacklist known common passwords, and impose relaxed minimum strength requirements based upon both length and character types.
    – Polynomial
    Dec 20, 2012 at 9:58

Remember that one of the reasons we also require complex passwords is that when a database gets hacked, the passwords cannot be bruteforced easily. (less complex passwords will allow just this)

While users should never re-use their passwords, it's something that unfortunately still happens.


Delay or attempt counter will prevent a direct brute force attack but what if hacker steals your whole database? Then he can brute force your passwords for as long as he wants. And with this your two-factor authentication is already 50% broken. Your second authentication step can be broken with social engineering/a computer virus or whatever other technique needed.

No, in my opinion, we are defenetly not concentrating too much on password complexity, not at this point. When everything else on server is compromised, your strong hashes (probably) won't be.

  • Am making the assumption that the system does its part and implements all best practices regarding password security storage within the system.
    – Drew Lex
    Dec 20, 2012 at 5:59
  • 3
    But if that assumption is true (and it never is), you can also store them in plaintext.
    – cen
    Dec 20, 2012 at 6:13

The primary concern with complexity requirements is to make it hard to do an offline attack against a leaked hash table. Not reusing passwords is far more critical than password complexity and any non-trivial password would be fine from a security standpoint on a live system if the DB wasn't compromised and proper brute force prevention is in place.

However, since passwords are frequently reused and we won't necessarily know if a hash table has been compromised, complexity is necessary to protect either other accounts or an unrealized hash table compromise from allowing an attacker to determine your password.

Personally though, I would tend to agree that some places (not most, but some) have been starting to reach the other danger side, which is making complexity requirements so hard that it decreases usability and causes user frustration that is too severe for the level of security necessary for the site in question. This is particularly true of sites that have been compromised in the past and are trying to make a "good show" of doing things "better." (Sony, I'm looking in your direction.)


One compromise for complexity is password length. In other words a longer alphabetic, easier-to-remember and easier-to-type password is mathematically as strong as a shorter random password that contains all types of characters.

Longer passwords also prevent you from using dictionary words, words in common password wordlists, and hashes that exist in rainbow tables.

You must log in to answer this question.

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