I’d say that the login step is one of the first things we design when programming a project. Two strings of text (“User” and “Password”), two fields for the user to fill in the information and a button to click on and access. We can also add the possibility to reset the password in case the user forgets it: this functionality directs the user to a page containing a field where they have to enter their e-mail address, after which they receive an e-mail with a link redirecting to a page where they have to specify the new password.
As we develop these features, it’s highly probable that many more developers around the world are doing the same. Every programmer has had to do this at some point, as every quality analyst has had to create test cases. It’s a workflow that hasn’t varied much over time.
For each time you access your Facebook, Instagram or Gmail account, like any other application in your computer or cellphone, you’ve probably selected the option to remember your password, and rarely change it. In other cases, when you need to change your bank account or computer password, for example, you have to retrieve the freaking password you entered long ago, and that’s when the trouble begins.
Security Passwords Today
Let’s briefly discuss passwords before suggesting ideas to avoid the user a password-related headache. Many applications allow you to use the word password, which is one of the easiest passwords to remember but it’s absolutely risky. Others make the process of creating a password an ordeal, like this banking application (whose name we won’t reveal), which states that the password:
- must contain a minimum of twelve characters,
- must contain 4 non-consecutive numbers,
- must contain at least one uppercase letter,
- cannot contain repeated numbers nor letters,
- cannot contain vowels,
- cannot be the same as the previous 12 passwords used.
As you may imagine, remembering such password is anything but easy for someone who forgets where the house keys are. Creating a valid password is tiresome and hateful, and the user will try to find the easiest way to remember it (maybe by writing it down), but it’s very likely that they will often resort to the “recover password” option.
Let’s see how this works. In most cases, the user will receive by e-mail a link enabling them to reset the password. In others, as with an e-mail server, the user will have to answer the security questions they specified when first creating the e-mail address, probably eight Game of Thrones seasons ago, and they won’t have a clue.
Ideas to Avoid the Users a Headache
Although some applications allow the user to save passwords or can suggest smart passwords, we could step out of this model and consider rethinking the user authentication process in our applications. Here are a few ideas taken from apps I’ve tried:
- Some services detect (possibly by machine learning) where you’re trying to log in from. If you accessed the application from Buenos Aires and five minutes later there’s an attempt to access from Taiwan, there’s something wrong, unless you can teletransport yourself.
- One idea is to make the authentication process easier in devices the user has defined as safe, and use a different method (like a token or biometric authentication) to validate whether another device is safe to use.
- There are other ways (like allowing simpler passwords or requiring other user information) to facilitate this step while also determining if it really is the user who’s trying to log in, but it’s open to discussion which data to ask for validation.
- In Gmail we can use our phone for authentication purposes and enjoy many of their services.
There’s plenty of room to explore methods that will free the user from going through the tedious process of choosing the classic user/password combination. What solution can you think of?