I have been in kind of jinx as to how a website decides on which password is highly vulnerable , strong etc . Lately my yahoo account was told to change password which I am using for long time as the website feels its vulnerable . I need to know how they measure up to this .

  • 1
    This article is helpful.
    – user45139
    Commented Jan 2, 2015 at 19:02

2 Answers 2


Password strength meters are universally limited by the amount of rules and lookups put into them compared to the amount of rules and lookups put into attacking tools, particularly of the offline cracking variety like oclHashcat.

Most common password strength meters use a simplistic algorithm that combines length and some approximation of keyspace to give your reading. For instance, some will consider an 11 character password with upper case, lower case, numbers, and symbols to be "Very Strong".


If you think that "password" with a leading capital, a little common leet-speak, and a 123 at the end is a "very strong" password, I suggest you read up on rules based attacks. Note that some of the rule sets that come with Hashcat have in excess of thirty thousand rules, and rule sets are commonly used in combination with dictionaries of tens of thousands to billions of words (essentially cartesian joins - for every dictionary word, apply every rule in the rule set chosen), depending on how good the hashing was and how much the attacker invested in GPUs.

Some password strength meters include a small to medium dictionary and a small set of rules (which are much more efficient because they're operating on a cleartext password), such as zxcvbn; however, they're still limited compared to what a good attacker (such as a competitive cracking team at an event or a security research, not even counting real bad actors, using leaked password list).

The summary is: If a password strength meter says your password is weak, your password is weak (or the meter is completely broken).

If a password strength meter says your password is strong, ignore it; assume it knows nothing.

Long purely random passwords are as strong as you can get; I second the 14 character minimum, and that's only for a purely randomly generated passphrase.

Random word combinations can be ok, but "correct horse battery staple" as a specific example is pretty bad;three of the words are in a common Top 5000 english word list, and the last one's still in both the phpbb dictionary and the Ubuntu american english small dictionary. Further analysis at my answer to should i reject obviously poor passwords, but it boils down to the fact that an attacker using a small subset of English words would find this example, and many examples humans would choose on their own, without needing to exhaustively search anywhere close to the entire 4 word combination English language keyspace.

At minimum, choose at random only longer words, after eliminating common words as well.

  • For instance, take the Ubuntu american english insane dictionary
  • then remove all words under length 7
  • then remove all the remaining words that are also in the american english small dictionary
  • then use a random number generator to select lines and random, and use whatever word is on the line
  • Even better, put some unique random separators in between them as well

The flaw in correct horse battery staple and the flaw in most password strength estimators is the same; they do math assuming it's randomly generated, and without help, very few humans even come close. Attackers know this, and work with it and the results of what humans have chosen before that's already been cracked (or was stored in plaintext).

  • "Horse" and "staple" are short dictionary words, but if combined with other dictionary words, and the result is appropriately hashed (with "salt" and a strong HMAC-based, multi-iteration algorithm), then the upshot is a strong password because the only valid attack at that point is a brute-force attack. Rainbow tables will be useless, for example, and any rules-based attack still has to content with the factorial math of 3 or 4 random words out of a large dictionary arranged in random order. Toss in a capital letter or two, a digit, some punctuation, and you're doing pretty well. Commented Jan 3, 2015 at 13:39
  • A very valid point is that any password that a user can't remember is a weak password. Because they'll write it down or, as I've seen so very many times, they'll put it in their online contact list or a draft email in plaintext. My own password(s) tend to be well over 20 characters long with multiple non-word but slightly pronounceable "words," combined with other characters and digits. Easy enough for me to remember, but just getting most users to a 14 character password of any kind is a major undertaking. The biggest takeaway is that long passwords are the only strong passwords. Commented Jan 3, 2015 at 13:43
  • 1
    The “correct horse battery staple” method (a.k.a. Diceware — same principle with slightly different parameters) is perfectly fine. You do have to choose the words randomly (letting a computer or a set of dice do it, as humans can't do randomness). Commented Jan 3, 2015 at 22:08
  • Can't say I agree fully with these comments I'm afraid. The use of sever dictionary words is not necessarily strong. It used to be when massive computing power cost $$$,$$$,$$$ but this is no longer the case. Unless everything else is set up correctly (see my answer), any use of dictionary words is potentially weak. Commented Jan 4, 2015 at 17:21
  • In addition, passcodes that users cannot remember are only "weak" if users don't use a tool to manage them. Commented Jan 4, 2015 at 17:22

In addition to the other comments, it is worth noting that most of the password complexity checkers out there are rubbish!

Indeed, the GRC site makes it clear that they are only testing one aspect of complexity.

In reality, the use of rainbow tables and similar techniques means that you can have long passwords but if you use any kind of recognisable word or phrase (even with capitalisation and/or l33t speak), you are massively reducing the strength of the password.

There are several things that need to be done right in order to have safe password use.

On the Server:

  • Strongly encrypted & hashed password stores
  • Allowing long passwords
  • Allowing alpha, numeric and symbols in passwords
  • Controls preventing rapid password attempts (increasing timeouts and lockouts)
  • Controls preventing exfiltration of the password database (Data Loss Protection)
  • Strong controls around password resets (to prevent man-in-the-middle password reset attacks)
  • Strong but easy to use (for legitimate users) password change process

From the user:

  • Long passwords (>12 characters, preferably >16)
  • Random passwords
  • Use of alpha, numeric and symbols
  • No reuse of passwords between different services

I recommend the use of a trusted generator for passwords such as the one built in to LastPass. I also recommend the use of password stores such as LastPass and/or Keepass or similar because strong passwords are very hard to keep straight in your head. For sites that require frequent rekeying of passwords such as the really annoying Microsoft cloud sites, I recommend using a pattern that is easily remembered but still fairly random.

  • The only comment I would add is related to your "Strongly encrypted & hashed password stores" bullet point. The password itself should never, ever be stored, even encrypted. Only store the hash. The hash itself should be an HMAC, using an algorithm like bcrypt, scrypt or pbkdf2, with adequate entropy ("salt") prepended, appended or daisy-wheeled into the password before it is hashed. Really, simply appending the salt should be more than adequate because of the mangling done by the HMAC function. The result is a completely different hash for every account even if every password is identical. Commented Jan 3, 2015 at 0:50
  • ...an important point is that the use of salt with a strong password HMAC function (bcrypt, scrypt, pbkdf2, et al) makes rainbow tables more or less useless as an attack vector, because no two stored password hashes are the same, regardless of the quality or complexity of the inputs. This forces attacks to be brute-force, at which point the most relevant factor in making the password hard to guess is the length of the password. Commented Jan 3, 2015 at 0:54
  • Thanks Craig, you are completely correct of course. My poor use of English. Commented Jan 4, 2015 at 17:19

You must log in to answer this question.

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