Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Passwordless Products

blog.bolt.co

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Passwordless Products

#21

Post by Zikes »

d64f396930663ee wrote: post #16
hundchenkatze wrote: post #12

Earlier quoted context omitted.

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

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.

Re: Passwordless Products

#22

Post by justjohn »

d64f396930663ee wrote: post #16
hundchenkatze wrote: post #12

Earlier quoted context omitted.

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

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?

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.

Re: Passwordless Products

#23

Post by d64f396930663ee »

d64f396930663ee wrote: post #16
hundchenkatze wrote: post #12

Earlier quoted context omitted.

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

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?

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?

Re: Passwordless Products

#24

Post by gagege »

zevyoura wrote: post #18
gagege wrote: post #7

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

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.

Re: Passwordless Products

#25

Post by thedufer »

d64f396930663ee wrote: post #16
hundchenkatze wrote: post #12

Earlier quoted context omitted.

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

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?

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

Re: Passwordless Products

#26

Post by tombrossman »

gagege wrote: post #7
rgbrgb wrote: post #4

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

In a similar vein is the 'Publish on your own own site, syndicate elsewhere' idea behind the IndieWeb movement. http://indiewebcamp.com/POSSE

This is done to avoid silos and vendor lock-in, but effectively very similar to your suggestion.

Re: Passwordless Products

#27

Post by keepontruckin »

hundchenkatze wrote: post #12
d64f396930663ee wrote: post #8

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

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.

Re: Passwordless Products

#28

Post by gagege »

TylerE wrote: post #17
gagege wrote: post #14

Earlier quoted context omitted.

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.

Re: Passwordless Products

#29

Post by napoleond »

d64f396930663ee wrote: post #23
d64f396930663ee wrote: post #16

Earlier quoted context omitted.

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?

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.

Re: Passwordless Products

#30

Post by napoleond »

tptacek wrote: post #20

This idea is approximately as old as webmail. 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 "…

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.
Post reply on HN