It’s a well-known fact that most users choose weak passwords. Choosing a strong password is actually much harder than it might seem at first. Huge wordlists constructed from previously leaked password databases are readily availably online and we consistently pick passwords which are at or near the top of those lists.
In a worst-case (but increasingly common) scenario, where the actual database of hashed passwords is stolen, a half-decent cracking program will be able to spit out these weak passwords almost instantly, leading to large numbers of accounts being compromised. This is especially true for simple unsalted password hashes, which companies have been found to be using in some of the recent scandals, despite it being acknowledged as very poor practice for many years. Cloud Foundry stores passwords using bcrypt, which is deliberately designed to hinder password-cracking, but even so, weak passwords are still vulnerable.
So what can be done to help people choose stronger passwords which are not easily cracked? Some sites have complicated and annoying password policies which force you to include a combination of numbers, symbols and different-case letters in your password, despite the fact that this usually just makes your password hard to remember without actually making it stronger (as depicted in the famous XKCD “correct horse battery staple” cartoon).
Most users are familiar with the use of password-strength meters. In Cloud Foundry we plan to use a meter not just as a guideline for choosing a good password, but also to define the system policy. So rather than saying “you must satisfy these X annoying rules”, we simply say “you must get this score or higher on the meter”.
Obviously, the question then arises as to what makes a good “score”. The code we use is based on the calculations from Dan Wheeler’s zxcvbn project (https://github.com/lowe/zxcvbn), which uses a combination of common password dictionaries and checking for patterns such as dates, keyboard sequences (hence the project name) and other typical “bad” password choices. The dropbox tech blog about the project gives an excellent overview of the algorithms used and the rationale for choosing this approach. It’s not perfect – finding a weak password with a reasonable score isn’t too difficult, particularly if you consider languages other than English, but it’s definitely a good start and something we hope to improve on in future releases.
The main difference is that while the original project is a browser-based Javascript library, we will be using a server-side implementation both to provide feedback and to actually enforce a particular policy. The port of the zxcvbn library, as well as a sample application (both in Scala), are available on github. The sample application is also running on Cloud Foundry at https://szxcvbn.cloudfoundry.com/password.html. You can either use the ajax-enabled UI or directly submit requests to it and get a JSON response. Here’s an example using curl
$ curl -H "Accept: application/json" -d password=correcthorsebatterystaple https://szxcvbn.cloudfoundry.com/
which returns
{"score":8,"crack_time_s":2.0372004064749978E9,"match_sequence":[{"start":0,"end":6,"token":"correct","dictName":"english","matchedWord":"correct","rank":1525},{"start":7,"end":11,"token":"horse","dictName":"passwords","matchedWord":"horse","rank":494},{"start":12,"end":18,"token":"battery","dictName":"english","matchedWord":"battery","rank":3845},{"start":19,"end":24,"token":"staple","dictName":"english","matchedWord":"staple","rank":14066}],"crack_time":"63.38 years","entropy":45.21165314373938}
In our production implementation, the interface will only return the score plus the server’s required score (to allow the UI to tell the user how close they are to providing a strong enough password). The sample application is more verbose, providing information on how it has analyzed the supplied password string.
About the Author
