At Webmaker, we’re experimenting with a method that allows people to log in without a password by using a handshake over email or text message instead. Our goal is to reduce the frustrations that come with password management for our users. We also aim to reduce the security risks that come from weak and stolen passwords.
Webmaker will launch the new login experience soon. Check back here for updates, or join the discussion on Discourse.
Like many of you, we grew tired of passwords long ago. It’s a challenge to make them strong and a daily hassle to remember them. We often hear news of passwords stolen, even from tech-savvy companies with very sensitive information.
We wondered – why do we still use passwords? Aren’t there better ways to log in?
A quick search revealed that a growing number of people ask the same questions. Below, we discuss some of the existing password tools and alternatives, like Lastpass and social sign-on with Facebook. We share details on our ideas and solution to this problem. But first, here’s the short version of where we landed.
No Passwords to Forget. No Passwords to Steal.
For Webmaker’s platform, we designed a different experience for log in. New visitors can join simply by entering their email address and choosing a username. They can immediately explore Webmaker and use the tools, confirming their account later.
When people return to the site later, they log in with two steps. First, they identify themselves with their email address or username. Second, Webmaker reaches out to them with an email that includes a link to log in. If they check this email on a phone and want to log in on a desktop, they can copy a short key instead. No passwords to forget. No passwords to steal.
We added another nice feature to make Webmaker even easier to use. The log in email actually offers two links: “Sign in”, which is great for public computers, and “Sign in & remember me”, which lets you stay logged in on your home computer or other devices. Once you enter the site, there’s no need to check a box that says, “keep me logged in.”
Lost Password, Found Solution
We started this work like we start most projects, by asking obvious questions. Why do we log in to sites? What do passwords do for us? We found that people log in for two primary reasons: to identify themselves and to keep other people and spambots out of their accounts. A password is a portable way to uniquely and secretly say, “Hello website, this is really me.” Passwords can do this, but they are not the only way to identify ourselves and prevent other people from pretending to be us.
One day Kavita created an account for a new site, knowing she probably wouldn’t return for months. When asked for a password, she mashed her keyboard like a cat playing a piano. A friend next to her stared and stuttered, “But, how will you get back in?” She replied, “I’ll just reset the password like I do for every other site that I use only a few times a year.”
At Webmaker, we considered experiences like Kavita’s and wondered: what if we skipped the password and deliberately used the password recovery process instead? Could we turn it inside out, reduce the clicks, and make this annoying experience a positive one? If so, an answer to broken passwords might be hiding right at the center of the problem.
As we explored this idea, we quickly learned that other people have written about this as well. It seems that a few sites do something similar for mobile users. This solution recycles existing technology and experiences, and just requires some careful design to make it smooth. At Webmaker, we decided to push the idea further and make it our primary form of login.
You can read more about the design of the system and the user experience in a post by Matthew Willse.
Remix for Your Web Service
Is this secure? The system rearranges existing technology and experiences to help us avoid the weakest links in our security: weak passwords, vulnerable password storage, and passwords that somebody repeatedly uses on many sites. It is more secure than the most commonly used current solution.
If designed and documented well, this solution could be useful for other sites as well, eliminating the burden on people who run web services to keep passwords secure. This approach reduces the need to maintain code for social sign-on services, and it decreases the vulnerability of stored passwords. The links and keys emailed to each user are temporary and expire after short interval or after repeated attempts to use them. You can find a more technical discussion of this in a post by Chris DeCairos.
Many efforts to make the web more secure make it less friendly to use, proving that technology only provides one part of good security – savvy design is often better than brute force. For example, some sites require longer and more complex passwords which only increases security in theory; people will find shortcuts that make things easier for themselves but less secure. They might use familiar words and dates, or repeat passwords across sites. They might keep passwords on their desk, or worse, their computer’s desktop.
Social sign-on using Facebook, Google or Twitter offer one alternative to identify ourselves. But while social sign-on offers convenience, it puts our privacy in the hands of a few companies that arguably know too much about us and our life online. Social sign-on can also be inconvenient for people who use public computers at a library or use shared devices with their family. Nobody wants to log out in order to log in. For site developers, social sign-on can also be a challenge to maintain as the implementation varies between services and periodically changes.
Services that store and remember your passwords, like Lastpass, are only a partial solution; they can’t help Webmaker and other sites keep your passwords safe. And like social sign-on, they can also be difficult for people who use public computers or shared devices.
Feedback & Next Steps
Right now we support email. We plan to also support phone numbers and SMS for an easier log in experience with mobile phones. We also made passwords optional, smoothly offering a different experience to users based on their preference. We are curious to see which option users prefer, and why they prefer it.
We will continue to test this system across a range of scenarios and devices and iterate improvements. We welcome your feedback, ideas, and bug reports. Post your questions in Discourse or bugs in bugzilla.