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

51–59 of 59 posts

Re: Passwordless Products

#51

Post by hamburglar »

keepontruckin wrote: post #27
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...

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

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.

Re: Passwordless Products

#52

Post by bradbatt »

gagege wrote: post #28
TylerE wrote: post #17

Earlier quoted context omitted.

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.

It comes down to educating users in a way they understand. Part of the problem is that they simply do not grasp the risks or the issues involved. The problems are either too technical or confusing or they may simply not even know that the issue exists.

When wireless routers first came out almost none of them defaulted to having security. Unless you were fairly technical minded, you simply left the defaults in place. Not because you were clueless, but because you trusted that the manufacturer must know what they are doing...and you certainly don't.

Now they all come with security enabled, plus, users have been educated as to why they should use it. They don't need to know how it works-just why it is important and what it means to them.

Same thing goes for enabling HTTPS on websites, adding two-factor auth to your email, having unique passwords on different sites, etc. Part of the responsibility of users' cluelessness falls on us. We need to find better ways to communicate to the average user, who has a minimal understanding of technology, in a way that is meaningful to them.

Re: Passwordless Products

#53

Post by tptacek »

stanleydrew wrote: post #35
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 "…

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…

You mean, like 2-factor authentication? I like 2FA. Use a TOTP/HOTP scheme, for instance.

Re: Passwordless Products

#54

Post by omgitstom »

redblacktree wrote: post #37
omgitstom wrote: post #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.

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.

Definitely is worth thinking about. Defaulting to another factor would still be an issue as well. There are a few discussions on this post that highlight them.

Re: Passwordless Products

#55

Post by BWStearns »

stanleydrew wrote: post #35
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 "…

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…

It could be done as a desktop application or a browser extension. Reduce the password burden to one password and then generate keys for a PKI based on that (and maybe some other data to make it less guessable) If you sign up for something using this imaginary extension it would simply send your browser a token encrypted with your public key and your browser would decrypt it and would redirect to whatever.com/welcome/. This would put the burden on the user not to accidentally trash their extension and lose their keys, but you could do key-reset the same way that we currently do with password resets.

Re: Passwordless Products

#56

Post by jader201 »

stanleydrew wrote: post #48
jader201 wrote: post #45

These sites/articles that try to solve authentication by getting rid of passwords seem to keep forgetting something -- you still need a password/authentication to something else. If I sign on w/ Facebook/Google, they still have to authenticate me with a password. If I have a token emailed to me, I still have to access my email with a password. If I have a token sent to me via text, I may still have to unlock my phone…

"Has someone tried creating another device that serves as a "key" and connects to your device via USB/bluetooth that can be used for authentication purposes?" As far as I know many banks outside the US issue a key fob which generates tokens. Those are essentially equivalent to something like the Google Authenticator app.

Right, but even key fobs are no better than sending a token to your phone.

If this was to really get adopted -- by both the issuer and the user -- it would have to be easy. A bluetooth device would be ideal, as it would allow wireless communication to the target device being authenticated. Stick it on your keychain and forget about it.

Re: Passwordless Products

#57

Post by stanleydrew »

tptacek wrote: post #53
stanleydrew wrote: post #35

Earlier quoted context omitted.

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…

You mean, like 2-factor authentication? I like 2FA. Use a TOTP/HOTP scheme, for instance.

I love 2FA as well, and always set it up when I can. But if you are going to argue that it is "tremendously inconvenient" to have users fetch a token from email or some other channel, I don't see how 2FA does any better.

The argument is that if you are not implementing full 2FA, at least implement your single factor as "something you have" rather than "something you know".

Adding a password as an optional second factor instead of vice versa seems preferable to me.

Re: Passwordless Products

#59

Post by spellboots »

stanleydrew wrote: post #46
spellboots wrote: post #39

Mozilla Persona is basically this but better thought out. There is a good talk about it here: https://www.youtube.com/watch?v=nJff23UdNAI

The thought that's been put into Persona (formerly BrowserID) is excellent, but as far as I can tell it is intended for use on websites. Perhaps it could be made to work in a mobile app though?

Yes: https://github.com/mozilla/persona-ios
Post reply on HN