Passwordless Products
blog.bolt.co
blog.bolt.co
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.
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.
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?
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.
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.
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.
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'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 done to avoid silos and vendor lock-in, but effectively very similar to your suggestion.
Also check out Mozilla's BrowserID if you're interested specifically in the auth piece.
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.
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.
Illustrated guide here - http://www.sqrl.pl
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 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.
From the article your "password" is a:
short-lived one-time-use tokens delivered over a secure channel that they control
What to log in using a different browser, it's the same as before, get a new token.
You get the idea...
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.
waterken.sourceforge.net
See specifically:
http://waterken.sourceforge.net/web-key/
and