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.
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.
The idea here is you only need to log in on a device once (or as often as you delete all your cookies). After that the site would remember you, so there really wouldn't be that much waiting on emails to arrive.
Definitely not something I would want for my bank account, but who cares for logging on to a support forum or some other trivial account.
So why not just make the session last forever the same way, but using a password instead of requiring me to login to my email and click a link? I logged into Facebook the first time and as long as I didn't delete cookies, I could go to Facebook on that device today, tomorrow, next week, next month, next year... And never have to put my password in again.
Not really saying Facebook, but using Facebook as an example. They keep the session alive until you either delete the cookie, or the session from your control panel. Why deal with this email method when you can just keep the session alive forever unless they logout or delete cookies, after they have typed their password in?
First thing I thought too. The email validation step, in my opinion, is the most annoying part of signing up for any site. I often log in places on devices where I don't have access to my email, so this requirement would completely keep me off your site.
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.
Even most incompetent users like my mum save their password into the browser keychain so it ends up bring only a single click anyway.
Things like browserID are solving this far more simply.
Exactly. As a developer I get back the email address of the user that has authenticated with the BrowserID server. That way it is easy to build a list of authorized users.
I suspect they will make a browser specific login workflow in which case you would not even need to be presented with a form asking you to auth as a user. Your browser would know your credentials already (which I guess is similar to login details autocomplete).
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.
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.
Maybe have an option to have a token that can be entered or a link clicked.
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.
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.
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.
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.
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...
Back in the good old days of UUCP you might wait a day or two to get mail from across the globe...
Who really cares what it was designed to do? The fact is, almost the entire userbase is going to receive that email before they can switch tabs to their email inbox. So even though it wasn't designed to be immediate, it is in practice, and we have a whole list of technologies that we use despite intent (HTTP wasn't designed to be stateful, and yet we use it as such constantly).
Mail transmitting is only sometimes encrypted, which is disappointing, but I've yet to hear of an instance where a user account was compromised when the forgotten password link was hijacked by listening to the wire between two mail servers. If it really is a problem, this could also be mitigated easily by only allowing the link to work on the browser that initiated the request.
Frankly, though, I'd love it if this system were implemented if for no other reason than to encourage mail servers to enable TLS on their SMTP backend.
> So even though it wasn't designed to be immediate, it is in practice,
But that's by accident, not really by design, and because email isn't supposed to be immediate, and is often outside the user's control, there are very many things that can delay it.
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.
Very interesting idea! Although I'm not sure that it would actually make it easier for users that don't do tabbed navigation (mom) to log from a second/public computer.
So, if elegant for power users, and 'not easier' for mom-users, should we implement it?
I agree that the UX isn't perfect, but neither is our current login/password system for every site. For me personally, if I don't use a site regularly my login process turns into: click forgot password link, check my email, reset the password, then login. Then again the next time I visit the site 3 months later. So if that's what we're going up against, the email to login session flow isn't too bad.
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.
Please, somebody figure out that when you embed asymmetric keys in things, when people lose those things they'll get really angry
or
Please, somebody figure out that when you embed asymmetric keys in people's bodies, we'll end up with a lot of geeks with their hands hacked off with machetes.
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?
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.
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 authorized 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.
You only get locked out of a website if you delete your cookies while your email provider is down. How often does that happen?
This idea doesn't speed up the login process, but it accomplishes a few other useful things. The server doesn't store passwords, so a breach of the server doesn't compromise other services for which users had duplicate passwords. And users can't compromise their own accounts by choosing weak passwords. Both scenarios are commonplace.
To be fair, the user can still compromise all their accounts by choosing a weak password for their email account. It does reduce the onus on them from coming up with dozens of (hopefully) unique, strong passwords to one, which is certainly an improvement.
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.
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.
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.
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...
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.
It is titled "The $300 million button" and details actual user experience at an ecommerce site. Note how many users even know what email address they used, how many got the password right, daily password resets etc.
That article indicts registering to purchase and has almost nothing to do with the password topic in question. Can you imagine having to wait for a login email every time you tried to make a purchase? Ugh!!
That article indicts registering to purchase and has almost nothing to do with the password topic in question. Can you imagine having to wait for a login email every time you tried to make a purchase? Ugh!!
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.
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.
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.
This seems more ideal for mobile devices. Enter name -> email notification almost immediately and use that to log in. I personally think it would be easier and faster than attempting to enter a password using the on-screen keyboard.
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.
Anyway, I like the idea of questioning the current way of user authentication!
There's always the argument that the register process leaks the same data. But having it appear in a dropdown makes it easier to incidentally see someone you might know.
OK, so i am going to go out on a limb here and assume that this WILL piss off a portion of your users.
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.
What one could do is to simply reverse the prominence of the "enter password" and "reset password" steps of your login flow.
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"
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.
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.
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.
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!
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.
While True, isn't browserID piggybacking on this? Using your email as the "persona"? An accidental benefit would be any service that implanted this would be automatically two-factored for users who have a two-factor system enabled. I like the thought of that.
This is true already for pretty much every website that lets you recover password by email, and most allow this. Any that use a secret question wouldn't switch to this scheme anyway. It reduces the hassle, as if your email got compromised, and they change passwords to all your other accounts, you have to regain access one by one, changing passwords back and so on, when with this email system, you can just regain access to the email account and the rest are under your control again.
100 comments
[ 0.23 ms ] story [ 224 ms ] threadI 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.
Definitely not something I would want for my bank account, but who cares for logging on to a support forum or some other trivial account.
This just adds more waste...
Personally I would implement Facebook connect and have this email login system as an alternative.
Even most incompetent users like my mum save their password into the browser keychain so it ends up bring only a single click anyway.
Things like browserID are solving this far more simply.
Non-power users (11 yo kids) maybe don't always have their inbox open/session active.
Best case scenario with one e-mail entry for multiple devices stand in conflict with link only being usable once.
Don't get me wrong, I think passwords are horrible but this post was just made in too much of a hurry.
Interesting topic!
https://login.persona.org/
I suspect they will make a browser specific login workflow in which case you would not even need to be presented with a form asking you to auth as a user. Your browser would know your credentials already (which I guess is similar to login details autocomplete).
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.
Maybe have an option to have a token that can be entered or a link clicked.
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.
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.
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.
At work we have a policy that smart phones are locked by a PIN. No PIN, no email.
This is not ideal: no mechanism to enforce 'good' PINs, force a user to change them on a regular basis.
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...
Back in the good old days of UUCP you might wait a day or two to get mail from across the globe...
Mail transmitting is only sometimes encrypted, which is disappointing, but I've yet to hear of an instance where a user account was compromised when the forgotten password link was hijacked by listening to the wire between two mail servers. If it really is a problem, this could also be mitigated easily by only allowing the link to work on the browser that initiated the request.
Frankly, though, I'd love it if this system were implemented if for no other reason than to encourage mail servers to enable TLS on their SMTP backend.
But that's by accident, not really by design, and because email isn't supposed to be immediate, and is often outside the user's control, there are very many things that can delay it.
[1] http://staticloud.com/
http://news.ycombinator.com/item?id=4291856
So, if elegant for power users, and 'not easier' for mom-users, should we implement it?
We could suggest that Facebook implement something like this. Seeing a login control containing 950MM names would be rather comical.
or
Please, somebody figure out that when you embed asymmetric keys in people's bodies, we'll end up with a lot of geeks with their hands hacked off with machetes.
http://en.wikipedia.org/wiki/Security_token
Guess what? Even worse usability.
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.
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 authorized 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.
This idea doesn't speed up the login process, but it accomplishes a few other useful things. The server doesn't store passwords, so a breach of the server doesn't compromise other services for which users had duplicate passwords. And users can't compromise their own accounts by choosing weak passwords. Both scenarios are commonplace.
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.
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.
http://news.ycombinator.com/item?id=4291856
It is titled "The $300 million button" and details actual user experience at an ecommerce site. Note how many users even know what email address they used, how many got the password right, daily password resets etc.
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.
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.
Anyway, I like the idea of questioning the current way of user authentication!
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.
What one could do is to simply reverse the prominence of the "enter password" and "reset password" steps of your login flow.
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"
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.
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!
[1] - http://www.openrent.co.uk
[2] - https://developers.google.com/identity-toolkit/