Character order and password strength

  • Pablo

    Pablo - 2013-05-14

    Just wondering if character order has any bearing on password strength?

    Take the following for example all using the same characters and length, but arranged differently:




    The reason I ask is that the first one would be easy to remember but would it be any less secure than the others in terms of being cracked via brute force or similar?

    Appreciate any insight on this one.

  • Paul

    Paul - 2013-05-14

    The first option is less secure because it uses a dictionary word.
    Put the passwords in KeePass and see what the strength report says.

    cheers, Paul

  • Pablo

    Pablo - 2013-05-14

    Thanks for the replies. Actually the reason I ask is that putting each of those passes into keepass returns the exact same security level - 66bits? SO the first is easier given a brute force attack would go through a process or what? guesing all english words, then all words with obvious substitutions, then either of those options with random symbols or numbers? From a crackers perspective, what is a potential known going into a crack? Is there a way to analyse the file to give them the password length or character makeup in any way before beginning brute force or similar?

    Olav the picture in that article kind of made sense to me about why it was an easy guess but perhaps Im missing something?

  • wellread1

    wellread1 - 2013-05-14

    Real world password strength estimators are estimating the size of the password space that an attacker would have to search to have a high probability of finding the password and expressing the value as a power of 2 (e.g. 66 bits means the attack would have to search 2^66 passwords to have a high probability of finding the correct password). This "strength" estimate is a property of an imaginary set of passwords, not of particular passwords. Estimators make various assumptions such as: the attacker knows the length and character set size, and that the password is randomly generated. There is some agreement between estimators because most make similar assumptions about attack strategy (e.g. they are random searches of a particular password space). Unless you know the attack strategy, it is not possible to generate perfect estimates.

    The KeePass password quality estimator does not presume to know how the password was generated. Instead it uses the observable features of the single password provided to estimate password quality. It also uses a small dictionary to de-rate password strength of passwords that contains words. In the example you provided, the analyzer missed the embedded word. Also because of the statistical nature of the analysis, and the small sample size (1 password), there is imprecision inherent in the estimate.

    The best strength estimates are possible for randomly generated passwords because the search space is defined by only two parameters, password length and character depth. The password space of passwords generated by other methods can usually be extensively parametrized by attackers, resulting in much smaller effective attack space.

    Last edit: wellread1 2013-05-14
  • olav

    olav - 2013-05-15

    Estimators make various assumptions such as: the attacker knows the length and character set size, and that the password is randomly generated.

    Of course, Wheeler specifically rejects this "password is random" assumption in his estimator, which is why I prefer it. Real world cracking has moved beyond brute force. Compromised real-world password datasets have shown that people don't use random passwords, but words -- often words that are familiar to them. Crackers know this and have moved on to dictionary attacks. The game has changed, and will continue to change.

    Random passwords, such as those generated by KeePass, will continue to be state of the art for users of password managers. Their downfall is that most people won't use a random string for the master password. And that's where a good strength estimator is helpful.

    Notice that the dictionaries that are used are critical to a good estimator. These are overwhelmingly English (and specifically American English) dictionaries, which will not derive good estimates if your native language isn't English. Nor will dropbox/zxcvbn generate good estimates if you use foreign language names (names are another favorite of real-world passwords -- dropbox includes top names from the US Social Security dataset). The zxcvbn estimator also rates against keyboard-neighbors (as its name suggests, but again there is no support if you use a non-English language keyboard). As you can see for non-Americans the password strength may be misleading if the cracker has any information about you at all.

    You may expect password strength is an absolute; but it generally lacks enough knowledge about you to estimate the security of your password against attacks by your soon-to-be-ex partner, or drug-addicted child ....

    You can run the dropbox password strength estimator in a standalone configuration [1]; it will report how it assumes a cracker would find your password. [I think the 3 decimal places of entropy are quaint, but that's how they're reported.]

    passwordzxcvbn entropy
    Date$4763^32.909 bits


    Last edit: olav 2013-05-15
  • Pablo

    Pablo - 2013-05-15

    That makes everyone, Im a little clearer now.

  • wellread1

    wellread1 - 2013-05-15

    Trying to identify the effective size of the password search space, at least with respect to vulnerability to a dictionary attack, is a real challenge. All estimators can provide really poor estimates when presented with a password that falls outside of its assumptions. Consider the estimated entropy (H) in bits for the 32 bit random string:


    Estimator Entropy bits
    Analytic calc 32
    KeePass 13
    zxcvbn 71
    Haystack (1) 106

    (1) Password Haystack

    Which is the best estimate?

    Last edit: wellread1 2013-05-15

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks