Improving Password Meters

I've cried and cursed over password meters earlier. Twice actually. I've been planning to do it again too, just haven't found the time yet. (Volunteers?)

Then this site appeared in my Twitter stream - HowSecureIsMyPassword.Net, and I soon got in contact with Mark (@smallhadron). A bit of e-mails, broken promises from my side supplying some constructive criticism etc, and here I am. Sorry Mark, but finally I couldn't keep these ideas in my head any longer, so here you are. I still hope and believe this can be of interest to you, as well as anyone else considering making their own password metering software. :-)

First of all; your test runs in my local browser, I do not have to submit whatever password I choose to test to a remote server, like they do in Sweden (last checked April 7, 2012). It's clean, simple and easy to use.

None the less; here's a few suggestions from me:

1. Password usage conditions
There are password meters available just for "testing" whatever you type in, and there are password meters used as part of the registration process at various sites and software you purchase. Since howsecureismypassword.net is a general site, I guess people will use it for testing any type of password they might have or consider to use. Work, e-mail, Facebook, Paypal, whatever... You could ask where this password would eventually be used, in order to tailor certain threshold values.

Example:
If the user says that the password will be used for logon to a personal Windows XP system, we can assume that the password will be stored using Lanman & NTLM. In such a scenario we also know that if the password exceeds a length of 14 characters, the Lanman hash will be invalid and thus not usable for cracking purposes. If the password is <=14 characters, the lm_lm-frt-cp437-850#1-7 Rainbow table set will crack the password in < 1 hour (well, at least in 99.5% + of all tested password hashes)


If the password will be used at , we can assume MD5 without salting. (Yes, I'm probably pretty pessimistic here, but there are just way too many of those sites around.)


So what you could do is to make a few checkboxes: Where will this password be used? (Windows, Linux, FreeBSD, I don't know...) - and from there you can set better threshold values for your password evaluation.


2. Referring to Rainbow Tables could be a good idea?
Take a look at the currently available Rainbow Tables at #freerainbowtables. The table progress page will show you what's cooking at the moment as an additional bonus. I presume the table set names are readable, otherwise drop me an e-mail or talk to @quelrods (James Nobis) on Twitter, one of the admins at freerainbowtables.


You could do a "progress bar" or something - perhaps coupled with the "password usage conditions" selections from the user as given above - to illustrate when a password is out of range for being cracked by those rainbow tables. There is no guesswork here - either the rainbow tables will crack the password (*very fast*), or they won't. The charsets will give you the exact details on which characters are supported in every rainbow table set - and you have the min-max length info in the filenames.


Doing estimates on time to bruteforce certain keyspaces is risky - in the understanding of me being worried people may put way too much trust into such "14.3B+1 gazillion years to crack" estimates. The hacker might be lucky and crack a 30+ character password in seconds!


--


Hm. I could do more to this blog post but it's late. Gotta sleep. I hope this could be of some interest at least. Everyone please feel free to comment your opinions and suggestions for improving the usability and - safety? - of password meters.