Yes, I know our password policy sucks

In 2014 I built the Password Management system for the University of Calgary. The largest feature of the tool is the ability to change your own password, and to change your password you have to follow our password standard (we don’t say password policy around here, for the same reason computer scientists don’t call themselves engineers). Our password standard is actually fairly straight forward, you need a certain amount of password entropy for your password to be sufficiently secure to access our systems. Password entropy calculations allow wildly different password rules, and as long as it takes a sufficiently long amount of time for an attacker to guess your password, the password is considered sufficiently secure.

Now, back in mid 2014, I wrote the tool in a bit of a hurry as we had a immediate need for a new way to reset passwords. We had a number of disparate directory services and we were adding another one to support Office 365. This new player made it a huge headache for our students and staff to reset their passwords, so a new tool was made to make the task trivial. Since I wasn’t given time or money to do proper user testing, I settled for a simple feedback form in Google Forms, which I linked to the bottom of every page in Password Management. It only really had one question, tell us what we can do better:


The initial feedback was useful. The tool was very rough around the edges, so the feedback helped me refine what functionality was needed and what sore spots could be patched up. Three months later the tool was complete, but I left the feedback form up anyways. Once in a while a new bug is found in the latest browser or a popular browser add-on causes something to go wonky. However without fail, every couple of weeks I get linked the same comic from XKCD. Here it is for posterity:


To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.

From XKCD:

This is a good comic. There is a good discussion over at Security Stack Exchange which validates for the most part the argument here. Can you guess which route we enforce on our users?

Yes. The top one.

In fact, I even created a nice little bit of JavaScript to help the user pick a password like Tr0ub4dor:



The question of why is very simple. We need to meet a certain standard of password entropy, and the systems we run enforce it in a certain way. We are bound by provincial auditors to protect our mission critical systems using enterprise tools. These enterprise tools ultimately put a bound on what kind of passwords we can use. These tools are very inflexible.

I really like user experience as a discipline, so this irks me just as much as it irks our students.

So can we allow pass phrases like the second example in the comic? Of course, but then we could only allow passphrases and nothing shorter. Time and time again we find user’s are unwilling to use long passwords or use password safe applications. For about a month we had Password Management report on the length of passwords entered before being hashed, and the data was aggregated anonymously into buckets of various lengths to study how successful a different password standard could be. Without revealing too much about our user’s password habits, I can confidently say forced 20 character pass phrases won’t be a thing anytime soon.

The flexibility to calculate entropy on the fly when the user selects a password is simply not a feature of our current toolkit, and you have to use the tools your given. For full transparency, here are the choices we are given for password entropy (ignoring things like password age and reuse):

  • Minimum password length (a number in characters)
  • Password complexity (yes or no)

The astute reader may recognize these options as a policy of Microsoft’s Active Directory.

It is certainly trivial to calculate entropy in the Password Management tool, and it would be great if we could allow long password length or password complexity with a shorter password, however that is not supported in our toolkit. We could also be clever and manipulate Active Directory’s fine grained password policy on a per user basis, however we are currently enjoying the benefit of having Active Directory as our ultimate unwavering gatekeeper on the password standard. Allowing Password Management to be the end all and be all of password standard enforcement puts us into a unique customization that will be difficult to get out of going forward.

Those auditors are also very thorough at looking at things we try do ourselves.

So if you are a student reading this and you want to use correct horse battery staple. Here are two recommendations:

Put .A1 at the end of your password:

correct horse battery staple.A1

Make a sentence out of your passphrase, and add a number at the end:

Correct horse battery staple.8

(Please don’t actually use correct horse battery staple).

Ideally in the future one of three things will happen to resolve this:

  • Our core systems will gain the functionality to allow flexible password types (unlikely).
  • User’s will spontaneously embrace pass phrases and password vaults, thus allowing us to set 20 character length passwords with no complexity (also unlikely).
  • Passwords are no longer used for authentication (the dream)

Until then, keep that feedback coming!

Opinions in this blog related to my employment at the University of Calgary are my own, and do not represent the interests of the University of Calgary.



Sean Feil