[hundchenkatze]

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...

[keepontruckin]

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.

[hamburglar]

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.

[d64f396930663ee]

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?

[Zikes]

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.

[pgeorgi]

"a text message" is not a secure channel.

[kelnos]

No, but for many use cases it's secure enough. Especially when you consider the tokens are short-lived and single-use

[thedufer]

"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".

[justjohn]

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.

[d64f396930663ee]

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?

[napoleond]

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.

[gagege]

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.

[thematt]

It's exactly how 2-factor authentication works for banking sites such as Bank of America and Chase.