11–20 of 59 posts
Have you heard of 2-factor authentication? Sounds pretty much like what you described. Specifically, the way Duo Security implements SSH logins.
So if the token expires, how do you log back in? What happens if you want to use a different browser? Or buy a new computer?
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...
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.…
Also check out Mozilla's BrowserID if you're interested specifically in the auth piece.
Earlier quoted context omitted.
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.…
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.
So if the token expires, how do you log back in? What happens if you want to use a different browser? Or buy a new computer?
None of these would be an issue... From the article your "password" is a: short-lived one-time-use tokens delivered over a secure channel that they control So, your session times out, log in again by requesting a new one-time-use token delivered over the channel of your choosing. What to log in using a different browser, it's the same as before, get a new token. You get the idea...
Earlier quoted context omitted.
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.
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.…
Have you heard of 2-factor authentication? Sounds pretty much like what you described. Specifically, the way Duo Security implements SSH logins.
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".