It doesn't fare well in the real world for two reasons:
1. It is tremendously inconvenient for normal users, who do not find it simple to flip to their "secure channel" to recover their "token" (or, for that matter, have any freaking idea what a "token" delivered over mail actually means). Even when the concept is implemented "transparently" --- "log in via Facebook" or "log in via Google Mail" --- people still hate it.
2. It assumes that the small subset of users who care about this problem are comfortable having all their security rest on their email account. That's not necessarily true. For instance, a decent-sized chunk of the power-users who care about password security already use password managers like 1Password, which this idea is not trivially compatible with.
Services that actually care about security (a) store authenticators in ways that aren't easily recoverable in the event of a breach, and (b) offer two-factor authentication, which is superior to "go fetch this login token over email".
What if the website I wanted to login to sent me a text with the token? Then all I had to do was reply to the text with a Y or N to log me in (or enter the code directly into the site if I wanted to).
When the text back is received by the host, my browser finishes the login request.
If you can sync your texts with your PC, maybe it could all be done right on the same screen where you are trying to login.
I think this could be mainstream. The hurdles don't seem that huge, and you can still leave passwords in place for a while until everyone is on board.
Be careful here. The SMS "from" number can be spoofed. So it doesn't quite work to have a user simply reply with 'Y' to an authentication text, unless the reply includes something only known to the service and the user.
This is already mainstream. Facebook even pulls the code directly from your SMS if you are logging into their Android app.
It's just that it's a second factor to the password. Your phone can be stolen as well (although such theft is harder to scale) - so keeping the knowledge-test around is important.
I agree though, if you don't care about security, OTPs are potentially much more convenient than traditional passwords.
I agree that the assumption of email is problematic. I would love to hear some constructive suggestions for alternatives to email as a token delivery channel. The reality is that password reset already runs over email, so we are already in pretty deep.
1. It isn't that inconvenient once you get used to it. I've been setting a completely random password for all services and not storing it anywhere for awhile now. I do password reset every time. It's a small price to pay.
2. Again we should not assume email. What are some alternatives? Are there none?
It could be done as a desktop application or a browser extension. Reduce the password burden to one password and then generate keys for a PKI based on that (and maybe some other data to make it less guessable) If you sign up for something using this imaginary extension it would simply send your browser a token encrypted with your public key and your browser would decrypt it and would redirect to whatever.com/welcome/<gianttokenhere>. This would put the burden on the user not to accidentally trash their extension and lose their keys, but you could do key-reset the same way that we currently do with password resets.
I love 2FA as well, and always set it up when I can. But if you are going to argue that it is "tremendously inconvenient" to have users fetch a token from email or some other channel, I don't see how 2FA does any better.
The argument is that if you are not implementing full 2FA, at least implement your single factor as "something you have" rather than "something you know".
Adding a password as an optional second factor instead of vice versa seems preferable to me.
It might work better now with the ubiquity of SMS, especially since the UI concept of "enter this code we just sent to your phone" is becoming increasingly common. Basically, like 'stanleydrew says elsewhere in the thread (https://news.ycombinator.com/item?id=7139641), the idea is just to flip the default for products implementing a single factor.
These sites/articles that try to solve authentication by getting rid of passwords seem to keep forgetting something -- you still need a password/authentication to something else.
If I sign on w/ Facebook/Google, they still have to authenticate me with a password.
If I have a token emailed to me, I still have to access my email with a password.
If I have a token sent to me via text, I may still have to unlock my phone with a password -- and I have to have the phone on me.
There are only three ways, that I can think of, to authenticate someone:
1) a password (or some other secret)
2) a token stored as a cookie or some other file on your computer/device
3) a token sent to/stored on a personal device.
Most products already implement #1 and #2. They will look for a token, and if not present, will prompt for a password. In the case of third-party authentication (Facebook/Google/email), this authentication is still done via a token, and if not present, will prompt for password -- it's basically pass-through authentication. I don't think anything can be done to revolutionize either of these.
That really only leaves us with #3. Texting a token to a phone works and prevents having to remember a password (or use an unsafe password), but it's still inconvenient.
Has someone tried creating another device that serves as a "key" and connects to your device via USB/bluetooth that can be used for authentication purposes?
This is about the only thing I can think of that would be a step in the right direction, but even then, there are probably still a handful of reasons why that would be problematic.
"Has someone tried creating another device that serves as a "key" and connects to your device via USB/bluetooth that can be used for authentication purposes?"
As far as I know many banks outside the US issue a key fob which generates tokens. Those are essentially equivalent to something like the Google Authenticator app.
Right, but even key fobs are no better than sending a token to your phone.
If this was to really get adopted -- by both the issuer and the user -- it would have to be easy. A bluetooth device would be ideal, as it would allow wireless communication to the target device being authenticated. Stick it on your keychain and forget about it.
I think this is generally an improvement over the status quo but it doesn't solve the problem we've created with email being our single point of security failure. From where I stand, the only sane way forward is to stop storing data in these big juicy silos that are very attractive targets for hackers (gmail).
What if each user had a personal data store, either running on a server they pay for, or one that they host themselves, at home? All their blog posts, comments, pictures, videos, location history, and everything else, is owned by them. They just give sites permission to access (create, read, update, delete) their data.
I'd love something like that, as a user. As a developer, it may make some things harder or slower. I'd totally be willing to pay that price though, if it meant never having to be responsible for thousands of user's data again. The user becomes responsible for their own data.
This is essentially what Google and Facebook, and to some extent even Apple, are attempting to become: giant stores of user data that you auth against.
Also check out Mozilla's BrowserID if you're interested specifically in the auth piece.
Yep, exactly. That's where I got the idea. I feel like, if someone's going hold all of a user's data in one place, and be their online identity, in a sense, it should be the user.
Really? Users are clueless. Always have been, always will be. Give control to the user and it'll end up sitting on a Windows shared drive on open wifi because that's "easy".
People learned, over time, that they have to lock their doors and keep their wallet safe. How is this different? Just make the learning curve as shallow as possible.
It comes down to educating users in a way they understand. Part of the problem is that they simply do not grasp the risks or the issues involved. The problems are either too technical or confusing or they may simply not even know that the issue exists.
When wireless routers first came out almost none of them defaulted to having security. Unless you were fairly technical minded, you simply left the defaults in place. Not because you were clueless, but because you trusted that the manufacturer must know what they are doing...and you certainly don't.
Now they all come with security enabled, plus, users have been educated as to why they should use it. They don't need to know how it works-just why it is important and what it means to them.
Same thing goes for enabling HTTPS on websites, adding two-factor auth to your email, having unique passwords on different sites, etc. Part of the responsibility of users' cluelessness falls on us. We need to find better ways to communicate to the average user, who has a minimal understanding of technology, in a way that is meaningful to them.
I like the self-hosted approach, but it's vulnerable to power and internet outages, which make it more or less a non-starter if you really need access to it everywhere. If it's not self-hosted it seems like it will naturally gravitate towards the same issues that existing services face.
True, which is why I think it might open up a nice new revenue channel for VPS hosts. Pay a company a monthly fee and they host your personal API. Also, it's encrypted, so they can't get to it.
Someone else mentioned user stupidity. Why should we let that dictate what we do? Just work really hard to make it easy for them to keep it secure. Give them less options, and so forth.
Totally agree. GMail with two-factor auth is a good solution, but then we're back to hoping that users adopt a relatively niche and optional security improving feature.
The thought that's been put into Persona (formerly BrowserID) is excellent, but as far as I can tell it is intended for use on websites. Perhaps it could be made to work in a mobile app though?
I really love when I see products take this route. I'm also currently working on something that is passwordless. I think there is a small cognitive hump that new users have to get over, but I'm working on ways to make it smoother. Nonetheless, I believe this route is the future & we will continue to see more passwordless products, which will increase the general understanding of how to use them.
We've been doing password-less entry for years over SSH with certificates. You generate a key, share the public parts and do some magic with your private parts (ahem) and it all works.
What I think the OP is looking for is a similar pattern for the web and browsers. Is there no way we could use the FileAPI to check for a keyfile?
I've wanted to bite the bullet with this, but not enough of a security expert to do it confidently. How does this stack up?
I like the idea of keeping someone logged in, then they can choose to log back using whichever means they decided when creating their account - email, SMS, authenticator app.
My worry is not so much the front end attack or access, but the data on the hosting servers being peeked at without a record of it, or any hacking required.
I recently built passwordless, email-based authentication into the iOS app I develop (http://varka.la). Still tweaking how it's messaged, though, as folks seem to be a little confused about how it's different than a normal registration flow one might see in another app.
I don't really get it, either, since in most cases the secure channel is something like email, where the token travels around in cleartext. I understand one-time session tokens are typically how password resets are accomplished, but that happens relatively infrequently for a given user. For users who don't like to stay logged in to a service, frequently sending out new session tokens via email or SMS seems like a step down from passwords. I think I must not understand, though, so thanks for correcting any incorrect assumptions I'm making here.
No, I think you get it. It's the equivalent of doing a password reset every time, generating a new random password each time, and simply never writing that password down. The idea is interesting but it has a few drawbacks. The one drawback that hasn't been pointed out by any comments I've seen is that email suuuuuucks as a transport for something you want to happen quickly (e.g. logging in). Occasional hiccups in delivery and spam false positives make it a serious pain in the butt if you have to receive an email in order to log in somewhere.
No, I don't get the idea. If I'm requesting a token for a certain user, how can the server reliably determine if I actually am that user? If it just authenticates every request, what's the point of even having a password?
A new "password" is sent to you over a secure channel you control each time you log in.
For example, say your session has timed out. You click the log in button and provide your username, and a couple of moments later you receive an email with a one-time-use link that you click to take you back to the site and log you in.
Another example: you click log in and provide your username. A few moments later you receive a text message with a 6-7 character one-time-use token that you type into a text field on the web site. The web site then logs you in.
In both cases the login requires you have immediate access to a secure channel you specified at the time you set up the account. The token or link provided via those channels are only valid for a single use and if left unused expire in a fairly brief period regardless.
"delivered over the channel of your choosing" is the key phrase, where that channel is usually email. Essentially, they've defined "User A" as "people with access to email address B" instead of the more standard "people who know password C".
Assume the channel delivering the token is email. Then to login you provide your user ID or email, identifying who you are, they immediately email you a token (or link containing the token) to login with.
OK nevermind. I get it now, it's just emailing you a new token everytime you want to use the site, or something like that. It's just such a terrible idea I couldn't wrap my mind around it. Who would ever want to use a website like this?
That's kind of a stretch. There might be valid issues with the approach, but it isn't as mind-numbingly terrible as you're suggesting. You'd just authenticate new devices/browsers every time you needed to--you wouldn't be doing it every time you used the site.
I like the idea of getting a text message on your phone with a very quickly expiring key (60 seconds), or having an authentication app like Google's, which works for a bunch of websites. I do admit, even that's kind of annoying. That's why I started using a password manager.
The password isn't the problem. If PSN / Adobe / Etc used large random salt for each password stored, industry approved hashing algorithms and other best practices while storing passwords, there would have been less of an issue with getting those hashes exposed.
But just as users don't generally pick secure passwords, lazy/time-pressured/incompetent (pick one) developers don't create secure password storage mechanisms. If the fix is as simple as defaulting to the other factor of two-factor auth for single-factor auth, it's worth thinking about.
Definitely is worth thinking about. Defaulting to another factor would still be an issue as well. There are a few discussions on this post that highlight them.
Do phones send some kind of unique Bluetooth signature that could be used to authenticate a user? The user would have to just tether their their phone to the computer. A browser plugin would authenticate sites that way. That seems like it'd be pretty painless.
2-factor auth is great. The suggestion is that if you are only going to implement one factor, it should look more like the "traditional" second factor. Basically we should flip two-factor author on its head. A user-defined password should be the second factor, not the first as is currently assumed.
It doesn't fare well in the real world for two reasons:
1. It is tremendously inconvenient for normal users, who do not find it simple to flip to their "secure channel" to recover their "token" (or, for that matter, have any freaking idea what a "token" delivered over mail actually means). Even when the concept is implemented "transparently" --- "log in via Facebook" or "log in via Google Mail" --- people still hate it.
2. It assumes that the small subset of users who care about this problem are comfortable having all their security rest on their email account. That's not necessarily true. For instance, a decent-sized chunk of the power-users who care about password security already use password managers like 1Password, which this idea is not trivially compatible with.
Services that actually care about security (a) store authenticators in ways that aren't easily recoverable in the event of a breach, and (b) offer two-factor authentication, which is superior to "go fetch this login token over email".