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.
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...
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.
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.
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.
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.
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!
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).
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).
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.
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.
Bam, login nirvana.
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"
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).
So, if elegant for power users, and 'not easier' for mom-users, should we implement it?
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 and something you have), but we want to avoid passwords.
Anyway, I like the idea of questioning the current way of user authentication!
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.
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.
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.
Not only can you register and login with only and email, you can review and revoke your active sessions.
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.
I'd also like to integrate SMS to support optional dual-factor authentication, which should get help fix the single point of trust problem.
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!
Combined with a simple standard for credential exchange (get request to example.com/login to get the list of required fields, post to https://example.com/login 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.
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.
That makes me sad, that kind of stagnation cuts off whole important areas of progress for web users.
Ugly solution that didn't expose a UI for sites that didn't support it and still had plain username/password forms. So it's completely impossible to bootstrap this by making some of the features useful to browser users before it was widespread.
Needed a js library because it worked at the wrong level of abstraction and put browserid.org in the middle of the transaction for no sensible reason (well no sensible technical reason but a perfectly sensible political one).
This was not developed by someone thinking "how can we solve a problem our users have" but by someone thinking "it would be advantageous to be in the middle of login transactions and there is a user problem we could bolt that functionality on to".
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.
I don't have to enter my second factor with credential or even my password when using Gmail from my phone, tablet, laptop or desktop.
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.
This gets to the heart of identity! It often doesn't matter. For example, one could clone HN using anonymous accounts. You'd give up only karma and connection between messages. It would be, essentially, something like usenet where you have a choice to "brand" every message you send with an identity - or not. Let's call this "Broadcast Identity".
Then there is something else which is your "Legal Identity" and it's the one most closely associated with all things money. It's the one that you need to deal with financial obligation, going in both directions. When you buy something, you want it to come to you, not to some one else.
Interestingly, I don't think that targeted ads really care about the connection between Broadcast and Legal identity. This implies that, no, you probably won't lose much by losing user accounts.
Actually, I take that back. The one thing that sites want and need is a way to proactively contact you. Aha! I think I just stumbled on the real reason we keep logins around - to get the email address, so we can send newsletters, reminders, etc. To prod the user into using our service more. To remind them that we exist, to be obtrusive, because our value isn't intrinsically strong enough to remind them.
http://www.fastcodesign.com/1670097/ford-schools-apple-with-...
We could suggest that Facebook implement something like this. Seeing a login control containing 950MM names would be rather comical.
This is just silly and a login form like this would drive me crazy
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.
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.
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.
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.
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.
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.
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.
I'd assume that if you used the email to login and since the article talks about also using cookies with expiry dates in the future the codes in emails would be single use.
Just use BrowserID.
