Live data from Hacker News

Passwordless Products

blog.bolt.co

31–40 of 59 posts

Re: Passwordless Products

#31
post #21

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?

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

"a text message" is not a secure channel.

Re: Passwordless Products

#32

Earlier quoted context omitted.

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.

Re: Passwordless Products

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

Re: Passwordless Products

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

Re: Passwordless Products

#35
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 "…

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?

Re: Passwordless Products

#36
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 "…

But it could.

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.

Re: Passwordless Products

#37

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.

Re: Passwordless Products

#38

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?

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