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…
Passwordless Products
31–40 of 59 posts
Re: Passwordless Products
#32Earlier 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.
Re: Passwordless Products
#33Re: Passwordless Products
#34Re: Passwordless Products
#35This 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 "…
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
#36This 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 "…
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
#37The 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
#38Earlier 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?