When we first set up our website, we didn’t allow user-specified passwords; we just generated one, and that was your password (rather like a registration key, in a way). This was obviously not ideal, so pretty soon we started allowing customers to specify their own passwords but we wanted to make sure that the passwords were reasonably strong as we do occasionally see attacks on our systems.

Rather than re-inventing the wheel, we started out using cracklib, an Open Source password checking library. Over time, two things became apparent:

• The checks that cracklib does are in some cases too onerous.

• When the check does fail, cracklib does not give error messages that are understandable or useful to end users.

Now, we prefer to spend our time working on our products rather than our website, and this was a relatively minor issue (some of you didn’t think so, I accept, but you were in the minority) and had an easy workaround of using a somewhat more secure than necessary password and storing it in Keychain (or in your chosen browser’s password database). As a result, while we were aware of the problem, it took us a while to get around to doing anything about it.

Attempt number two was based on another piece of Open Source code, pwtools, which is a port of the algorithm from the OpenWall Project‘s passwdqc to Python. This was a distinct improvement, and we’re actually still using it to generate and suggest passwords, but it still ended up with some customers puzzled as to why it was rejecting their passwords when they felt they were perfectly good enough. We didn’t always disagree.

Anyway, I’m pleased to let everyone know that we are now on attempt number three. This time, we’ve written the code ourselves rather than borrowing from others; fewer passwords should be banned, and because we have a Javascript implementation of the checking code it’s now possible to see in real time in the Change Password form how strong we think your chosen password is.

I’m sure there will still be people who want to use a password that our form doesn’t like. Hopefully, though, this should now mean that the password they’ve chosen is genuinely bad as opposed to not meeting some unusual rule that someone else has come up with. If you were one of the people who wanted to set their own password but found it too tricky, please do try again and let us know how you get on.

p.s. Please don’t use the same password on multiple websites. While we’ve implemented our site in such a way that we can’t tell what your password is, not everyone does, and some database administrators and website operators will, as a result, have access to the text of your password. It’s much better to use Keychain Access or 1Password so that you can have separate passwords for each purpose.