Test the strength of your password policy

Shouldn't the formula simply be =D11^A32, =D11^A33, etc. You can check the values by setting Max. # of Characters/Symbols Size Allowed in Passwords to 10. Instead of getting 10**15 you get 1,111,111,111,111,240 Mike

Here is web form for same calculations. Form is restricted to NIST and Perfect (computer generated) calculations. I didn't understand why original spreadsheet is limited to 15 characters as NIST is not restricted to that (Perfect do not have any limits, user selected passwords is specified as 'after 15 characters add 1 bit per character').

In the proper setting, password expiration is useless: Mike Howard did the math in "How often should you change your password – or should you bother?"; http://is.gd/DblR the math is not that hard, and I can't find any loopholes; can you? So don't bother with password expiration.

You know... secure passwords are a wonderful thing, but forgotten passwords (and the associated processes) have their own issues and, meanwhile, this whole spreadsheet rests on an interesting assumption: that username/password pairs can be tested easily. Of course, historically, we have the lockout mechanism which is supposed to prevent such abuse. But, as Mr. Grimes notes, people turn this off because of DOS issues. Then again, perhaps we should have some options between "locked out after some stupid piece of software mucks up the works" and "lock outs? never!" Locking out machines which have engaged in probing (and making it stupid easy to identify such misbehaving machines) might be one such step. And this can be a gradual thing: after a certain number of failed password attempts, you can start randomly failing valid passwords, and the likely hood of failure can go up with further attempts, with full lockout not happening until maybe a hundred distinct password hashes have been used. This should be restrictive enough to stop exhaustive searches and the false negatives should also slow down other attempts. And there's no reason to keep secret the likely hood of false negatives a secret -- when this mechanism gets triggered it should be "in your face obvious". Of course, you will still be getting support calls from people when they can not log in, and of course the real problem is exposing the raw information to people that need to know, without burying them in trivia. So password change and reset dialogs should all also be changed to present a security summary (about the threat level of failed password attempts) and a way of drilling down into this information (which machines have been misbehaving, trends, that sort of thing). And, of course this is all vaporware or worse. But... ... but our computer systems are insecure when the people responsible for them do not understand them. So we really ought to be approaching these problems as a strong expression of need, for more comprehensible systems.

I really appreciate the work you are doing. I tend to think that entropy is a bad measure of password security though. It works great for evaluating certain code types, but humans just don't do random very well and it's hard to abstractly measure all the shortcuts an attacker can use to take advantage of this weakness. Personally I think the log-in protocol used is more important than a very strong password creation policy. Increasing the time cost of a log-in attempt depending on the number of failed log-ins can be very useful. It stops a DoS attack against the user, but at the same time if you limit an attacker to one guess every two minutes or so, (after the first three or four), you can make even a "weak" password fairly strong. One measure of the strength of an individual password I've found is to look at the mangling rules that were applied to it, (using a modified edit distance), and then compare that to the rules used in popular password crackers. This way you can quickly evaluate how many guesses it would take to crack that password using real life examples. More about this can be found at my blog here . Sorry about the shameless self promotion ;)