This is a proof-of-concept web site with no account passwords, using only email address for sign-up and log-in verification, as demonstrated at NoMorePasswordsJustEmail.meteor.com
Jump To:
- What's so bad about passwords?
- Example NMPJE login user flow
- Does this seem awkward?
- Is this secure?
- The code
- Outstanding issues
- History
- Related links
Passwords suck. Good, strong passwords are difficult to think up, difficult to type, and difficult to remember--but all too easy to crack. When you forget your password (as we all do), there's the sucky "email me instructions to change my password" and then you have to go through that difficult password creation all over again. If you're on an insecure computer, with malware sniffing your client-side keystrokes or other data, then "all your password are belong to us." Multiply these difficulties by every service you use (you better not be reusing passwords), and there's just no denying it: passwords suck!
On NMPJE your email address is your user id (adding separate account names would have just muddied the proof-of-concept).
When you come to NoMorePasswordsJustEmail.meteor.com and are not already logged in, you see this one-field dialog:
Entering your email address...
...and pressing enter replaces that one-field dialog with this dialog:
That security code has been emailed to your email address. That email may look like this:
Enter that security code into the web page...
...and press enter to be logged in.
Alternatively, you can click on the link in that email and be logged in directly.
You will stay logged in, even if you leave the browser and come back, until you press the logout button.
The above flow is exactly the same for new users registering for the system, with only slight wording changes so they're aware this is a new user account.
I don't know if this is more awkward than most sites, it probably depends on how much you hate passwords.
Most of the time the user won't see any of this, since they'll usually be logged in, and so this is usually as convenient as any web site that remembers logins. Signing up is certainly easier with this method than with traditional password-dependant schemes. Signing in, after a logout, is a little less convenient if you're good at remembered passwords.
Again, it probably depends on how much you hate passwords.
I wager that it's at least as secure as any site that allows one to reset passwords via email.
Considering the difficulty in coming up with good passwords, and the increasing ease of hacking passwords, then is probably more secure than most situations.
On the whole, the only fair statement is: It's as secure as a person's email is secure.
None of the code here is particularly interesting. I put it together pretty quickly, and any other developer could do it at least as well. In NMPJE I'm more interested in testing the user-flow than in the particular implementation.
The part of NMPJE handling this user login, registration, and logout stuff is:
- user_account.html - client-side html and handlebars/MeteorJS templates
- client/user_account.js - client-side MeteorJS template stuff
- server/user_account.js - server-side code to manage accounts and sending emails
There is one MeteorJS workaround here, so that when running on the live meteor.com website we won't hit the 200 emails/day limit (this also helps make our email less likely to end in the spam filters). That workaround is in this commit code, and is based on this stackoverflow question.
I'm so far convinced this is as safe as standard login systems, and more convenient a lot of the time, but there are still concerns
non-standard - users are very very accustomed to standard email/password login forms. How to make this seem not so weird?
security-code too short? - With a 6-digit number there would be a million possible random security codes. If someone knows you're on the system, enters your email address, then randomly picks a number they have a one in a million chance of guessing correctly. One in a million is pretty small, but it's not zero. It wouldn't do a robot any good to come in and just try all one-million numbers, because after the first wrong try NMPJE removes the code. But what if a robot was automated to enter the email address, try a code, enter an email address, try a code, repeatedly until it got lucky--if this robot could do so 1,000 times per second it would be expected to hack in in just a few minutes. NMPJE currently hasn't dealt with this problem yet. I assume the solution involves some combination of a) deciding how secure you need to be and selecting the security-code-length accordingly, b) adding some delay either on all logins or if there has been a failed login, and c) keeping track of recent events to detect when an attack us underway. None of the above are difficult, and maybe future updates will include something like this.
force ssl? - With v1.014 I turned off force-ssl so users can test this at http: or https: My reasoning is that since no passwords are going over the wire anyway, I don't need to worry so much. Still, there are some cookies representing session state, and it could be possible that someone may sniff that over the wire and spoof an existing session. This, to me, doesn't seem as dangerous as stolen passwords and so I let the NMPJE user decide whether they want to use http or https. If you're implementing a system similar to NMPJE you may want to consider just how secure you want to be, and may want to force https/SSL.
denial-of-login? - It is conceivable that a bunch of bots might simulate a user trying to log in from thousands of clients. In each case that would cause a new login code to be created for that legitimate user. If that legitimate user then is trying to log in from their own browser (assume they aren't already logged in) may find that their security code is constantly being re-created faster than they can try to enter one. That legitimate user will also be receiving a whole lot of emails. This is a pretty weird scenario, and maybe it's not worth considering, but still I don't have a solution yet.
- v1.000 - 2013/05/03 - Initial release demonstrating login with just an emailed security key
- v1.010 - 2013/05/04 - Add alternative security method of a link in the email
- v1.014 - 2013/05/07 - Allow and default to http, not just https. Let user choose. See "force ssl?" above.
- Discuss NMPJE on Hacker News
- Many discussions of the issue (if I'd known so many people have already talked about this, I might not have bothered, so I'm glad I didn't know)
- If I include a Forgot Password service, then what's the point of using a password?
- How to implement non-password authentication in a web site
- Identify with email - No need for passwords
- Is it time for password-less login?
- More on password-less login
- Mozilla Proposes to Sign-in Only with the Email Address, No User ID or Password Required
- Kick-ass Website Login Flow (email only, no password)
- Django-nopassword
- 30 years of failure: the username/password combination
- Passwords are Obsolete
- Passwordless - a similar passwords-suck token-based authentication middleware for Express & Node.js (good description here)
- Shop It To Me says "Bye Bye Passwords" - An app that dropped passwords in favor of email
- Mozilla Persona - Tool any site can use to login with just email (skipping the security code step) video
- Handshake.js - Similar recent POC to do away with passwords, as javascript and a service.
- NoPassword - Similar to NMPJE, as some Ruby code.
- A Guide to Using Passwords Without Distraction - A thorough guide for all of us still using sites that use passwords.
- NoMorePasswordsJustEmail.meteor.com - this Proof of Concept
- Brent Noorda Brick Wall - the author's homepage