There's No Such Thing as Magic... Passwords

By Avi Deitcher

Many years ago, I had a manager from whom I learned one good thing: the principle of least surprise. Your systems - technology, processes, cars, postal service, whatever - should surprise your user as little as possible.

In a car, it is a matter of safety and regulation. The right pedal increases acceleration, the left one slows and stops the car. If you reversed it, you could cause serious injury (not to mention destroy your market share).

The principle of least surprise depends greatly on your context. Placing critical warning messages in Arabic violates the principle if your users are in Arkansas, but not if they are in Abu Dhabi.

In my experience, in technology systems, the principle of least surprise is violated most often by people trying to be too smart by half.

In the last few weeks, I have come across two very similar glaring examples of violating the principle of least surprise, both involving Web sites being too smart by half about login security.

It is a well-known problem that there are too many passwords, and that they are, on the whole, an insecure method of securing access to sites. Passwords are often too short, too easy to guess, and reused too many times.

In order to make peoples' lives easier, many people use password managers like 1Password and LastPass to manage their passwords. It works like this:

  1. You reach a Web site with a password field.
  2. You enter the username and password, or use the password manager's generator to create an impossibly long and complex password that never will be guessed.
  3. The password manager recognizes that you have entered a password and offers to save it for you.
  4. When you return to the site, the password manager fills in the username and password for you.

Because you no longer have to remember the passwords, the password manager can generate difficult, long and impossible to guess passwords, which make password guessing nearly impossible.

As a human, we could never remember a password "as652&^@!ggJK87!@#@&k". But that also means no one ever could guess it, making it much safer.

The entire process - one well known by a significant percentage of Web users and almost all technologists - depends on the password manager's ability to enter your saved (or generated) password into the password field on the page, or retrieve it when you enter it. In other words, it depends on the Web site using commonly accepted behaviours.

And there's the rub. If the Web site changes anything about how the password is entered then you break the password manager. Worst of all, users would have no understanding why, or, in some cases, even that it is broken.

Two Web sites - one a bank, another the domestic arm of one of the largest global insurance companies - watches for your keystrokes and when you are done typing your password, changes it in some way.

Why does it do that?

As a general rule, companies never store your password. Instead, they use a mathematical function called a hash to store a representation of your password. You can go from your password to the hash, but not the other way around. Thus, given your password, I can confirm if it is you, but given the hash (when properly implemented), I cannot figure out your password.

Apparently, these two sites hash your password right there in the browser window.... and are being too smart by half.

Because the password has to exist in the clear somewhere to be hashed, and because the channel between your browser and the server is encrypted and secure, there is little to no benefit to creating the hash in the browser, and possibly some real downside.

But the bigger issue is that you change the field exactly where every password manager looks for it.

In these sites, here is what happens:

  1. You go to the page
  2. You use your password manager to enter the username and password
  3. The site does not recognize that you entered a password, since it didn't catch any keystrokes
  4. The site sends your actual password - the way citibank.com, gmail.com and every other normal site does - to the server, which expects the hash
  5. The site fails to confirm your password, and you have no idea why

Assuming you are technically-minded and actually figure the above out, and so you think you fix it:

  1. You go to the page
  2. You use your password manager to enter the username and password
  3. The site does not recognize that you entered a password, since it didn't catch any keystrokes
  4. You realize this and enter the mouse into the password field and leave it
  5. The page hashes your password and sends it
  6. The site confirms your password
  7. Your password manager looks at the password field, sees something different from your saved password, and asks if you want to save your new password
  8. You save the "new" password... and now have lost your correct password!

The sad part is that if you really wanted to hash in the browser, you still could do it without breaking the user experience. All you need to do is hash the password in the background when the user presses "Submit" and send it as a separate field. Plenty of Web sites do this exact practice to send necessary "hidden" fields.

The principle of least surprise is crucial to making customers want to use your service, and thus growing your customer base.

Technology gives you lots of choices in how to do something. Choosing what to do is the difference between a great user experience and a terrible one.