This would drive me up the wall. I don't want to have to sit in my mail client, waiting for it to pull down the message that may-or-may-not have arrived at my mail host yet, when it's incredibly easy to use a password manager for everything without having to leave my browser. He bemoans the number of controls you need to interact with to log in, but to get to log in with his method, I need to put in my email address (or take the time to find it in the list), interact with whatever control submits the form, switch to my email client (at least 1 control, probably more), refresh it to get the most recent messages (perhaps more than once), open the message, click the link, go back and close the window I used to start the login process in the first place, then switch back to the window with the app in it. Seems far more complex.<p>I don't buy his premise, either; he claims you need to interact with "6 different controls" to log in to Facebook, but (a) you only interact with 4 of them and (b) that's only the first time you log in from that computer. He's trying to solve a problem I have never experienced. I'm curious to see if others have felt overwhelmed by the number of controls on login forms; this is a problem I've never had.
Someone needs a history of internet mail. It was never designed to operate in real time or be fast, whereas people expect logins to be fairly quick.<p>Also, using an email backchannel and one time keys moves the security from an encrypted connection (assuming SSL) to an unencrypted SMTP connection anyone can view...<p>Back in the good old days of UUCP you might wait a day or two to get mail from across the globe...
The logic behind this system isn't terrible. But as others have pointed out, it still relies solely on a third party. And while it's true that exposing the entire user list would not give an attacker much in the way gaining access, it's still a leak of trackable information. I think a more secure solution would be to model an authentication standard after public/private key encryption. If all browsers would endorse it, the interface would be remarkably simple.<p>Present the end-user with a certificate management dialog when they open a browser for the first time. That would allow them to either browse for an existing certificate or create a new one. After one is created they're given a copy which could be used in any other browser at a later time. From that point on, each time a Web server requires authentication it could be handled behind the scenes. No log on page, no passwords, no user names; only aliases and a push button start. Signing up would become a one click affair, as well. Press the button, and the browser sends the public key to the Web server. A site gets hacked? Big deal, there are no vulnerable hashes -- only public keys. You would never be required to remember anything more than backing up your certificate. Worried about recovery? Do what you would do with SSH. Pop the cert on a thumb drive and hide it. Hell, even create a feature in that management dialog to do it for you.<p>This of course would require a large standards body and the involvement of every major browser company. But in the end, it would be easier.
I had to read this article twice to make sure I was understanding it right. I honestly see zero benefit in this approach. It does not speed up the login process at all. The only thing it accomplishes is not requiring the user to remember a password. Additionally, it puts way too much power in the hands of random email servers. What if my email system at the office goes down for a few hours. Am I locked out of all websites too?<p>I do agree with his point that memorizing passwords can get cumbersome, especially with different sets of rules for different logins. However, the majority of people store their passwords in their everyday browser or just stay logged in indefinitely.<p>The real solution to "doing away with passwords" lies in recognition technology on devices. What if my keyboard could recognize my identity and pass that along to <i>authorized</i> sites as login credentials? What if my iPhone could do the same? I'll defer the argument of privacy in visiting sites where you don't want your identity revealed for another time.
What's the overlap of users who (a) have trouble with login forms and (b) leave their email open all the time (whether browser or dedicated app)? This relies on a very high level of comfort with email and context switching.<p>This could potentially introduce an increase in spam if users are now instructed to click on links in emails blindly as long as they match a site that they're familiar with.<p>Leaving one app/tab for another seems like bad UX to me. This doesn't seem any better than the OAuth dance, even if it uses a much more seemingly familiar mechanism.
On OpenRent [1] we're using the Google Identity Toolkit [2]. We're finding that in our current configuration it works extremely well, even for non technical users.<p>It offers password-less log-in, and also remembers your username/email client-side. The only issue is lack of support for facebook/twitter log in out of the box - but that is apparently in development.<p>It doesn't seem to be widely adopted, and that is possibly due to the reliance on Google servers it adds to your service. Whether that comes back to haunt us or not I don't know - but I have a backup system in place in case GITKit does stop working!<p>[1] - <a href="http://www.openrent.co.uk" rel="nofollow">http://www.openrent.co.uk</a><p>[2] - <a href="https://developers.google.com/identity-toolkit/" rel="nofollow">https://developers.google.com/identity-toolkit/</a>
I honestly don't understand a lot of the comments in here. For starters, many websites (eg Twitter) require email confirmation for new signups and password resets. This is not so different, the UX related commentary is superficial at best. After the initial activation / a reset you're back to cookie based auth, just like most sites.<p>Second, there is not a single mention of the biggest problem with passwords currently: the apparent inability of many sites to store them securely. I'll take this method of authentication over a password based one any day for probably 90% of the sites I have an account with currently. Especially sites like HN (not implying insecure password storage on HN - just saying for any forum based sites, it's more than adequate IMHO).
Ben, I like where you're going but I think we need to go just a little bit further to make it viable. In particular, it's email that's the weak link (so to speak). But it's entirely possible and desirable to replace email with something that has emails positive qualities without it's drawbacks. I'm thinking a secure, realtime channel to which only you have access, and a notification system that let's you see (on all your devices) what got posted there. Anyone (or anything) in the world can post to it, and they are guaranteed that you'll get first crack at the data. (In this case the data is a one time URL).<p>What sort of thing represents a secure, real-time channel to which only you have access? Note that, unlike email, we are not interested in queueing messages in this channel. My first thought runs to a public URL, a place where anyone can post anything, and it will appear on all your devices (possibly within the browser).<p>So basically as long as you maintain credentials to access that channel, sites have a good way to give you a one-use login URL.<p>In an ideal world, you're browser would have a password protected private key and knowledge of what your personal URL is. All sites requiring login would ask the browser for that URL, and the site would send a one-time login URL to the channel URL, and the browser would be smart enough to just follow the link.<p>Bam, login nirvana.
OK, so i am going to go out on a limb here and assume that this WILL piss off a portion of your users.<p>That being said, can it work "halfway"? It seems the main benefit of this approach (from a UX standpoint, disregarding security etc.) would be to simplify things for people who always use one device and forget and reset their passwords all the time anyway.<p>What one could do is to simply reverse the prominence of the "enter password" and "reset password" steps of your login flow.<p>Enter your email, and get a big fat "Get Login Link" button below the field. Next to it is a small link that says "use password"
For most cases, I think the ideal is identity tied to the device/browser via an email address:<p><a href="https://login.persona.org/" rel="nofollow">https://login.persona.org/</a>
This is how Staticloud[1] works. You put in your email address and receive a log in link. You never have to register; registration and login are the same process.<p>[1] <a href="http://staticloud.com/" rel="nofollow">http://staticloud.com/</a>
I remember being intrigued by Google's "Sesame" experiment (covered on HN at <a href="https://news.ycombinator.com/item?id=3469692" rel="nofollow">https://news.ycombinator.com/item?id=3469692</a>) where they logged you in via a QR code processed via your mobile.<p>Relying on something you have (mobile phone with a trusted app on a trusted network) instead of something you know (passwords) can be an interesting choice. Ideally you'd require both (something you know <i>and</i> something you have), but we want to avoid passwords.
First things that come to my mind are privacy problems. This autocomplete would make it really easy to find out whether a person uses the service. (dating sites, porn sites, torrent sites, political sites,....). Additionally if the ologin happend only via the mail address, you could collect email addresses very easily from many websites.<p>Anyway, I like the idea of questioning the current way of user authentication!
I also felt login process should be simplified. I got two types of registration forms at my new website
(www.survenator.com) - one is express where user only enters their email address and a highly secured password is email to them. Other is the complete registration form. Although the form is still kept very short. Users can change their passwords\other account information anytime.<p>Express registration may work for well for those who have hard time coming up with strong passwords or don't want to think about a password while doing another new registration.
We started this feature as an experiment and will evolve\refine it based upon the usage.<p>Once the user confirms their account if they selected "remember me" checkbox then we don't require them to login, we just check for authentication cookie.<p>I do not agree with the author regarding his vision for "password reset tool feature to send the link in the email". Sometimes users want to take control of their password and do not want to remembered for security reasons.
I've been working on a demo of something similar. It's a work in progress, but I've got it running at <a href="http://nopassword.alexsmolen.com" rel="nofollow">http://nopassword.alexsmolen.com</a>. Code at <a href="https://github.com/alsmola/nopassword" rel="nofollow">https://github.com/alsmola/nopassword</a>.<p>Not only can you register and login with only and email, you can review and revoke your active sessions.<p>People who are complaining about the speed of email - the session could last indefinitely until you log out, which would reduce the number of times you had to perform the ceremony. Plus, think about the benefits of this when you need to authorize a TV, phone, etc. You can simply visit a link in your email instead of copying and pasting or typing in those form factors.<p>I'd also like to integrate SMS to support optional dual-factor authentication, which should get help fix the single point of trust problem.
Sending link to e-mail is exactly as dependent on third party as OAuth.<p>Non-power users (11 yo kids) maybe don't always have their inbox open/session active.<p>Best case scenario with one e-mail entry for multiple devices stand in conflict with link only being usable once.<p>Don't get me wrong, I think passwords are horrible but this post was just made in too much of a hurry.<p>Interesting topic!
Am I crazy in thinking that this whole problem should have been solved a long time ago by making password management a responsibility of the browser, either by baking it in or mediating the exchange?<p>Combined with a simple standard for credential exchange (get request to example.com/login to get the list of required fields, post to <a href="https://example.com/login" rel="nofollow">https://example.com/login</a> to login. Or more likely, some existing standard that handles more cases and is already thought out) this whole annoying problem is no longer affecting every person who uses the web.<p>Is it too late for this? I feel that it probably would be very difficult to make this work now, it's too late and the browsers wouldn't go up against google and facebook who now want to own and track your identity.<p>That makes me sad, that kind of stagnation cuts off whole important areas of progress for web users.
I actually implemented a system very much like this on an internal company network recently. For that purpose, it worked great. I don't think it would work in an open, public context, not least because an attacker can force your site to spam its users. However, when you are going to stay logged in forever on basically the same devices, having an email-based login system without a password is no more pain for the user than a verification email (since that's all you're doing anyway). Essentially you're relying on the website to generate a local, device-specific, secure password instead of requiring the user to create and remember a (likely insecure) password themselves.
Why accounts should have anything to do with email or email address. It's bad policy and I hate it. We all know that email isn't secure. For many sites I would like to disable password recovery due these inherit security issues related to email. If you ever login to Gmail, after that you have always clear all cookies and cache data and possible super cookies. After that you would need to login (again) to email to uh oh, access other sites. Afaik this is super bad idea. Naturally you could save the link as bookmark, which would work. But security would still suck.
Apple should augment a single sign-in mechanism with a transparent 2nd factor embodied in the iPhone. This would result in your being automatically logged into any participating site while using Safari on the same LAN as your iPhone. The mechanism would fall back to the traditional password if you don't have the phone. Bluetooth could also be used to communicate to the hardware.<p>The hardware would only run signed Apple firmware and be separated from the CPU and most of the rest of the device, except for access to radios.
Outside of transfering money, I think you should structure your site so that logins are not necessary. For example, if I wasn't the only "drcube" on Hacker News, I wouldn't be upset. Names in meat space aren't unique, why should we expect them to be on the web?<p>Next time you think about starting a web service (that doesn't handle money!), think about what you lose by getting rid of user accounts entirely. It probably isn't much.
A way to streamline this even further might be to pair it with a browser extension designed to poll your inbox for these specific messages. When received, the extension could handle the login step, eliminating the need for the user to jump to their inbox for the validation email. I'm not sure if that kind of extension could be created so that it didn't compromise the security of your inbox.
I don't think it's the order of the elements, I think it's the combination of the elements and the process of entering them. See Ford's (yes Ford's) experiment for proximity based automatic login/logout with your phone.<p><a href="http://www.fastcodesign.com/1670097/ford-schools-apple-with-clever-phone-login-appwait-what" rel="nofollow">http://www.fastcodesign.com/1670097/ford-schools-apple-with-...</a>
I definitely find this topic interesting and have a hard time remembering all my passwords, but I'm not fan of this solution. Honestly, how isn't this just a worse implementation of OAuth? It seems equivalent to clicking a "login via gmail" button, except with more of a lag?
Here's an idea, if you allow me to choose From a list of users, then I'll continuously "spam" other users' inboxes with login link messages.<p>We could suggest that Facebook implement something like this. Seeing a login control containing 950MM names would be rather comical.
At a very high level, I like this idea. It would be great if there was browser support to super-persist the auth tokens (cookies) through cookie-clearing and also sync between browsers on machines -- most likely via a browser plugin.
So going from a "bad" login form with 6 controls to a "simpler" login where I now have to interact with the site's form, my browser, and my email client is somehow better?<p>This is just silly and a login form like this would drive me crazy
This means the second someone loses access to their email account, they lose access to every account on every system attached to it via this method. I'm not sure introducing a single point of failure is a good idea.
I personally think this could work. The big show stopper occurs on a shared computer. It would be annoying to get logged out of a service daily and have to request a new email link to log back in.
Thinking of it for enterprise users it could really work.<p>Enterprise users seem to be on Outlook all the time checking their e-mails so this would work if you can't tie your passwords into AD/Exchange.<p>Maybe have an option to have a token that can be entered or a link clicked.<p>I get all my e-mails on my phone so if I received a code that I can enter in my phone that can work. I could also click a link in Outlook and be logged on.<p>Now if someone has my phone which is receiving my e-mails and they enter the e-mail on a website and receive the secure login we got a big problem. I don't know how to get around that.<p>Interesting discussion, but some flaws. I would think it requires some sort of 2-factor auth to save people whose e-mail addy is compromised.
Please, somebody figure out how to get us over the hump to the bright future day when we all have asymmetric keys embedded in hardware and we can leave passwords behind.
I have a text document on my computer that lists all the websites/programs with username/password. I also use autocomplete (which IMO is basically the same as having a document with all passwords.) I can have unique passwords for every single website without relying on a third party cloud solution. And for the passwords I use often, I have them memorized anyway.<p>If something is compromised (which has happened) then I have a list of every single site where I have an account, and can change the passwords.<p>A side benefit to this is if someone needs to access something (most likely while traveling, or if I'm dead) all the information is there for them.
The problem with "solutions" like these is that they start with faulty premise that "passwords are broken". This particular idea sounds like death by a million cuts.
having the user select field list all users is not so bad, but the email a login link is a terrible idea, this is a break is workflow worse than a password.<p>Even most incompetent users like my mum save their password into the browser keychain so it ends up bring only a single click anyway.<p>Things like browserID are solving this far more simply.
and you still need a password to access your email account. let's assume you are at a friends place and want to login somewhere...you have to grab your phone to get your secure webmail password, login on gmail/etc. click the link. a real timesaver...
So what happens when someone's email account is compromised?<p>Currently there's a fair chance that the victim can reset passwords and change contact info for their online services before the hacker bothers to do so. But this would be impossible if email were used as the sole form of authentication.
Passwordless authentication done right is a subject in here, try to break the auth and let me know...<p><a href="http://news.ycombinator.com/item?id=4291856" rel="nofollow">http://news.ycombinator.com/item?id=4291856</a>