Mar 11, 2019
Password-Less One Time Login Links
We recently launched a web portal for our customers to use and monitor our healthcare de-identification and linking solutions.
As part of the portal, we needed a solution for authenticating our users. You’re probably used to entering a password to authenticate or verifying through your email or social media account. We decided to authenticate by sending users a unique link via email and then logging them in by hitting that endpoint. A process called one time login links.
This article is why we chose one time login links over any other authentication solution.
Get in front of real users ASAP
The way we survive is by getting feedback fast and iterating. For our portal, this means getting something real users use as soon as possible by using commonplace tools and ideas in healthcare companies. Given our users are employees at healthcare companies, we can take for granted they have access to email. However, we can not take for granted that all customers share authenticators, for example, that everyone uses gmail and can authenticate through Google. Furthermore, researching good third party authenticators and then running choices by customers takes a lot of time. Thus to be agile, we were left to choose between password based login or one time login links.
Easy for users who infrequently visit site
We know our web users are going to use the portal for performing the infrequent activity of downloading our application and monitoring runs of our product. One time login links require a user to go through more steps than a password — a user must visit the website, then their email, and then go back to the website. Where as with passwords, a user just stays on the website for the whole authentication process. However, most users who infrequently visit a website (a) don’t remember their password or (b) use a common password for multiple websites. With one time login links, a user isn’t burdened to remember a password they only need once a week or less, while still ensuring maximal security.
No passwords stored = more secure
Bad password hygiene is commonplace, which can lead to a variety of security concerns. One common form of bad hygiene is using the same password for multiple websites. In this case, if a user’s password is compromised on one site, it is compromised everywhere. Another common practice is a user storing passwords as plaintext notes, either digitally on their computer or even on a sticky note. This allows an attacker to be able to walk up to an unattended desk, collect password information and then use the password later without the comprised user knowing. Lastly, people tend to pick passwords that are easy to remember but also easy to break, like a beloved’s birthday or the beloved “password123”.
On the other side of it, as a company, it’s convenient to avoid storing user passwords. Since extra security precautions must be taken to store passwords securely, removing this need reduces engineering complexity. This allows us to build and iterate more quickly without compromising on security.
A couple other things to think about:
[Con] One time login links are not a common user experience, and at first may be less intuitive than using passwords. We tried to reduce confusion by making the login experience have really clear language and testing it on lots of people.
[Con] By authenticating through email, we have allowed a new vector of attack via email.
[Pro/Con] Our users are employees of companies. Since their authentication to portal is tied to their company email, when an employee leaves a company and no longer has access to their email, they also no longer have access to portal. However, not all employers are fast at deprovisioning email or have that built into their process. For example, if a user is a student at an academic institution doing research and then ends their semester of research, their email will still be active.
[Pro] Because your email is used during the login process, you get email validation for free.
[Pro] Our login links are only valid for 15 minutes. Thus if your email is comprised, past login links can’t be used to access our portal.
As a developer, I always put myself into the shoes of my user. The most surprising part of developing authentication for our portal was that I initially felt login links were really unintuitive and would be a complex paradigm to ask our users to learn. But through creating a concise workflow with clear language and testing it out on lots of people, we were able to make the login links very intuitive. I still strongly believe it’s good to gut check any feature you release to clients, but in this case I was reminded to not underestimate the power of high fidelity prototypes and fast feedback from users.
