UX Planet — Medium | Bastian Heinlein Passwords — a pain to us all.

Apparently many designers and developers believe secure passwords have to look complicated. The most secure ones for them seem to be like ”#sK8/a_C%eD8)“. This looks like hell and is a mess to create.

Credits: Adrian Zumbrunnen

Would you like to create such a password? I wouldn’t. Instead, I would probably risk it to write down this password on a note or use the same password several times. Maybe I would use a password manager. None of these is a great idea. Therefore, such complex requirements for passwords are a real problem for privacy and IT security.

But we need these passwords! At least this is, what some guides tell us. NO! We don’t need overly complicated passwords. I don’t have any idea who invented this legend, but this person probably hated us. So many websites, apps and whatever demand us to use such passwords without any logical reason.

Why we don’t need complex passwords

If the safety of passwords relied on the number of different characters, how can our iPhone be safely protected by a 6-figure passcode? This is just 1,000,000 possible combinations. Apple did something, at least theoretically, pretty easy. The “Secure Enclave Processor“ (a pretty cool piece of hardware) restricts how often you are allowed to enter a wrong passcode. Furthermore, they use one more trick: they set a hardware delay between the inputs.

The same security measures could be done on a web server! You simply could limit the number of attempts to enter a password. Of course, this causes some problems, which would go too far for this article, but in general it is pretty secure: If there are too many attempts to enter a password, the server could lock the account and notify the user, so he can unlock it via email.

Still not convinced?

Maths for the rescue!

A long password is king. It’s nearly unimportant if you have 26, 52, 62 or even more different characters, because security increases exponentially with the length. Example needed?

If your password is only a single lowercase character, it offers 26 possible variations. You have 52 possible combinations, if you demand uppercase or lowercase characters. On the other hand, you have 676 possible combinations if you require two lowercase letters. You see, length is more important.

Just a small mathematically excursion why this is in fact true.

The number of possible combinations equals security. In order to calculate this, you write:

The formula for password security — so easyThe green line relates to the formula with variable length, while the orange line relates to the formula with variable number of different characters.

If you look at the graph of this, on the y-axis you have the security. You see clearly that the security level takes off very fast, if you use the password length as variable, as the derivative of this function is then exactly the same function. On the other hand, the security gain is slower, if you vary the number of different characters. Because then the derivative is only this:

Yeah, Maths is awesome

It’s that simple.

Why Password Security Is Also A Designer’s Task

Complex passwords are difficult to remember and a mess to create. This is an obstacle we don’t need to confront the user with. So, why should we? Creating an account is never something the user likes. Therefore, we shouldn’t call for more than we need.

If the user managed to create an account despite of complex rules the next challenge starts: entering the correct password. You don’t see what you type, so failing is pretty likely, if you also have to think about special characters, numbers and whatever. An even bigger problem than typos is to remember the password, hence one of the most often pressed button on each website is the “I forgot my password“ button to reset the password. This is less convenient than it could be as it is (hopefully) not the desired way to use a service.

Maybe, even it’s not very likely, some users even will need help by your support to recover the password, even if your reset process is properly designed. Worst case: As a result of this, the general service could become worse, as the support has to deal with such obvious tasks even more or it will become more expensive.

But don’t worry, help is underway! Here are five ways to do better!

1. Explain why they need secure passwords

We should explain our users why they need secure passwords. Passwords will protect users’ privacy and prevent identity theft. So, why shouldn’t we tell this the user? Obviously, a course about passwords is overdone, but you could offer a “Why do I have to do this“ button, just like Gmail does.

Gmail offers the answer to the question we ask ourselves when we create a password together with an indicator for password strength.

2. Make it easy to create a password

We should make it as easy as possible to create a password. Therefore we shouldn’t lay down more rules than this one: “Use at least x characters.”
Of course, this would allow to create passwords like “password“ which are in lists containing frequently used passwords (therefore it’s vulnerable to attacks). So it should be forbidden to create these passwords.

Just one rule for passwords. It can’t get any easier.

3. Use social login

Maybe you even can give up the idea of your own account system. Social networks like Twitter and Facebook offer login APIs. As most users will be registered there, they won’t be required to create a special password for your service. Instead they can rely on Facebook/Twitter authentication and you can use existing user records from these services.

The typical way to use medium.com is probably one of those.

4. Use only email address in your login form

Medium shows a different way: Having an account system without any passwords for user not willing to use social media logins. This could be the perfect way, leastwise for the “usual“ user. Local Storage or cookies have to be activated by the user which maybe allows an attacker to derive the password. It also won’t work very well if you have a target audience being very concerned about privacy as they probably will have deactivated cookies.

On the other hand, the majority of users will have a great experience: You only create an username and enter a mail address. No more passwords. No more problems.

You see: No passwords!

5. Remove sign up wall completely

It might sound strange, but probably you won’t need passwords at all. If you don’t design a social network, the need for an account, is probably not given. A comment section on your blog can live very well without demanding the user to register, I wrote in detail here. I developed a media platform which was supposed to allow the reader to comment the articles. As recording their mail for security reasons would have been needed for an account system but also would have conflicted with German privacy laws, I had to develop/design an alternative. It allows the user to comment under an article and verify his mail per comment, instead of registering. Everytime he writes a comment, he would get a mail to confirm he wrote the comment. This allows to force a connection between mail address and comment without requiring a password.

This allows the user to comment without having to register.

Another example: If you order something online, there is usually an option to order as a guest. Why shouldn’t you make this the norm? Again: No more passwords. No more problems. You just confirm your identity when it’s needed.

Conclusion

Here we are. Hopefully you learned a little bit about password security and why it’s a task of a designer to think about this topic. It’s just one single piece of the user experience, but considering each single piece is what I believe makes a great UX.

Just do it. Press the ? to help others finding my article.

Connect with me on Twitter.

• Think Different: Software Is Part Of Great Design
• Why encryption fails because of bad design

Why Complex Passwords Are Bad Design And 5 Ways To Do Better was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.