Password: WhYdO1ne3dT0d*th1s

Passwords are the bane of my existence. I loathe them. Every time that I try out some new service or need to get something for my school work and I'm faced with that all too familiar field prompting me to enter a password the fire of hatred in my belly is stocked a bit more. This hatred is fueled further when I'm informed that my password does not meet the requirements for a password. As a user nothing is more aggravating than being told that to install an app that will show me kittens as a background I need a 15 letter password with no repeating letters that must include a symbol, a number, a capital letter, an emoji, a sample of blood and one Kanji character. Given the fact that I have over 200 passwords to different sites its a wonder that I don't spend most of my money replacing computers that have had unfortunate accidents with blunt objects.

Unfortunately passwords are essential in this day and age. It would be foolhardy to try to do most things without them. They secure our information, our bank accounts, our access to paid services and so much more. That doesn't mean that they are the best method however. Passwords were a stop-gap solution that was created long before people wrote words. They haven't changed much since the days of guards with swords standing outside of doors. What has changed is how they are implemented and bypassed. 

When mechanical computing machines were invented it didn't take long for people to realize that they could create better and faster encryption than a human could. Of course as the encryption got better, so did the encryption cracking, leading to the mess we have today. Interestingly enough this has made passwords *less* secure because they don't address the single most critical flaw - the user.


It doesn't matter how mathematically secure a password is if the user can't remember it. This has led to the number one password being "password" and it shouldn't be surprising. Humans are good at pattern recognition, not randomness. We can look at clouds and see fluffy bunnies, or stare at a modern piece of art and understand it. Ask us for a random string of characters and we fail miserably. Add to this the fallibility of memory and problems really start to pile up. Leading to the inevidable post-it notes on the monitor. 

A number of different options have been developed to deal with this issue. Some options are wholly dependent on the user, such as using a pass *phrase* instead of a single word. With this technique the user chooses a long phrase, say "the password is anything but password." This adds entropy to the password, thus making it more secure. Similarly you could employ the XKCD method of using four random common words. Both of these methods are easy for the user to remember, but hard for hackers to guess. They are not un-crackable however, as this wiki explains, but can be made more secure with the inclusion of punctuation.

This can become problematic if you have several hundred passwords that are unique. To address this problem, clever people have designed programs that will generate long passwords built with random characters for you. LastPass is one such solution. With it you only have to remember one password, which is the one to the LastPass application, and it will generate secure passwords for you. If you need to be able to access your passwords from a public computer, which is the case for me, LastPass offers a couple of portable options that can be installed on a flash drive.

Is There Not A Better Way?

Of course all of these options still don't answer the fatal flaw of the user having to remember a password. Some time ago I read a Medium article written by Justin Balthrop discussing the very issue. In it he suggested an alternate authentication scheme.

  1. Instead of asking users for a password when they try to log in to your app or website, just ask them for their username (or email or mobile phone number).
  2. Create a temporary authorization code on the backend server and store it in your database.
  3. Send the user an email or SMS with a link that contains the code.
  4. The user clicks the link which opens your app or website and sends the authorization code to your server.
  5. On your backend server, verify that the code is valid and exchange it for a long-lived token, which is stored in your database and sent back to be stored on the client device as well.
  6. The user is now logged in, and doesn’t have to repeat this process again until their token expires or they want to authenticate on a new device.

From a user experience point-of-view I like this idea...a lot. This cleans up the problems that user have with passwords and it is easy to use. There is even a company - - that is developing a product to do something along those lines. Of course, there are still problems with this technique, as pointed out by the comments on the post, but it addresses the fatal flaw of passwords.

As much as I'd like them to, passwords are not going anywhere anytime soon. So it is up to us, as developers and designers to implement secure systems that work for the user. The user won't develop a complicated password scheme while registering for your product, he will go with the route of least resistance. By removing as many obstacles as possible for him, we provide them with a better experience, which hopefully leads to more traffic for us.