Many people have the perception that website security and good user experience can’t go hand in hand. It’s true that certain security measures affect user experience and there will always be cases where trade-offs between the two have to be made. But when you introduce UX and security from the early stages in the software development life cycle, both can go well together. But in practice we often see things going wrong. A few days ago I decided to reset my Telenet (a Belgian telecom provider) password. And for several reasons this was a bad experience. I wrote this post initially in Dutch but I found it worth the while to translate it. Unfortunately I can’t run the Telenet website in English, so I used Google Chrome’s translate option what can result in funny English sometimes ;-).
Password reset implemented wrong
Let’s have a look to the different steps of Telenet’s password reset process.
If you enter your e-mail address and press “Next one”, Telenet generates a password for you and shows it together with your username in clear on a web page.
I frequently see websites that generate a password and send it via e-mail. I cannot remember that I ever saw that the newly generated password was shown in clear on a webpage. The best reason I can come up with is that they want to prevent that a password sits in clear in someone’s mailbox.
From a usability perspective this is really bad. Now you have to copy the password on the clipboard to be able to (manually) login afterwards. When you forget to do so and you close the page, you have no longer access to your account (your old password is already replaced by the new one at that moment) and there’s no option left but to perform a password reset again.
Because the reset does not require verification by the owner of the e-mail address, I tried if I can reset someone else’s account. This is not possible, Telenet only lets you perform a reset when you are connected with your own Telenet modem and while not using a proxy or VPN connection.
This is an example of how you solve one problem and create another. Nobody else can reset your password, but you can only reset it yourself when you’re at home. What if you’re on vacation, need to login but you forgot your password?
Never create passwords for your users
One of the fundamental problems of Telenet’s password reset implementation is that they create a password on behalf of their users. When you do this, the following problems occur:
- At that moment a user is no longer able to login with his old password. This implies that he is temporarily locked out of his account when someone else executes a password reset for his account. This is the reason why Telenet added an extra check; only if you’re connected with your modem you’re able to do the reset.
- You have to find a way to deliver the new password to the user. Telenet “solves” this by showing the password on the screen. Other websites send the password via e-mail. This is insecure because e-mail traffic (and thus the password) can be intercepted and a mailbox is in most cases no safe storage medium.
How to implement a user friendly and secure password reset?
If you put the responsibility of setting a new password where it belongs, on the user, both problems are solved. When a user wants to reset his password, send an e-mail containing a reset link. Via this link the user can choose a new password. The link is a unique URL that must be loaded over HTTPS and looks like “Reset/?id=ace3823415cd38c962cb9e54a1ae533c”. The token “ace3823415cd38c962cb9e54a1ae533c” must be random, so it can not be guessed.
Furthermore the token may only be valid for a limited time and must be deleted after the reset is done. This ensures that the window of opportunity for attackers is very small. The token needs to be stored together with the ID of the user performing the reset and the time when the token was created. When the user loads the reset link, the website checks if the token exists. If this is the case, the user is authorized to change the password.
This implementation ensures that only the owner of an e-mail address can reset the account for that email-address from anywhere in the world.
Change password
When you perform a password reset, Telenet generates an 8 character password consisting of numbers, lower and upper case letters, for example “6bQL3A3x”. Although Telenet doesn’t require to change this password at first login, it’s a good idea to do this.
The choice of your password is something you better don’t leave to a (possibly outdated) website because you often get this kind of — In Telenet’s own words— “moderate” passwords.
Note the password advice given in the screenshot above. The tips are either outdated or wrong. The current best practices are no longer to require a mix of special characters, uppercase and lowercase letters. If you want to know more about this, you certainly should read this article. The main reason is that people always fall into bad habits when they have to meet these password complexity requirements. And the same is true for the last tip “Extra safe: change your password regularly”. Instead of strengthening the password it has the opposite effect. People already have difficulties to choose and remember passwords and when they (need to) change them often they will mostly use variations on their previous passwords.
Whatever advice you put on a password reset page, people will come up with passwords like $Password1234. The only thing people see is that the password strength indicator says that their password is “very strong”. This is exactly why you better not use such indicators.
If you let people choose freely — with the only limit being a minimum length (certainly read this article about length vs. complexity) — but you refuse passwords that have been leaked on the internet, you are forcing users to choose much stronger passwords. Here you can find a collection of more than 320 million leaked passwords that you can use to check against.
Personally, I use a password manager. This is a tool in which you can store all your passwords. Furthermore it helps you with generating random, strong and unique passwords.
A 64 character password may seem absurdly long. But since I do not have to remember it myself — my password manager does this for me — I choose a password that is as long and strong as possible. A website that saves passwords in a secure way, thus hashed, does not have any reason to limit a password in length. The hashed value always has the same fixed length regardless of the length of the password. At first, Telenet seems to be doing well, my new password is accepted without problems.
Until I try to log in again. Then I get this:
After experimenting a little bit I discovered that they store only the first 40 characters of the password in the database. This explains why I could not login with my password. I informed Telenet more than a year ago of this inconsistency between back-end and frond-end but this bug is still not fixed. If you, for whatever reason, constraint the length of a password — and let’s hope in the case of Telenet it’s not because passwords are insecurely stored in the database — ensure that you also validate it at client-side.
Account security
Telenet does not offer the possibility to enable two-factor authentication (2FA) for an account. The advantage of 2FA is that — even when your account is hacked — hackers only get access to your account when they get hold of this second factor, for instance a code generated by an authenticator app on your smartphone.
An extra layer of defense that is actually necessary for online accounts like Telenet. A Telenet account can be used to manage personal data (name, address, telephone number, modem settings,…) and login to different applications, one of them being a mailbox. An e-mail account is a critical account, that except a lot of personal information, often contains registration and password reset e-mails of other online accounts.
The absence of 2FA is an important reason why I don’t use my Telenet e-mail address to register accounts on other websites.
Conclusion
I didn’t write this post to point the finger at Telenet. But their account management implementation has a number of usability and security problems. Do the test for yourself on several websites and you will notice that many of the problems described in this post often occur. I hope that identifying these problems and offering some alternatives can help some people to improve their account management implementation.
