6 ms·
Passwordless Products
- d64f396930663ee 13y agoSo 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?
- hundchenkatze 13y agoNone 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...
- d64f396930663ee 13y agoNo, 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 13y agoA 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.
- justjohn 13y agoAssume 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 13y agoOK 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 13y agoThat'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 13y agoI 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 13y agoIt's exactly how 2-factor authentication works for banking sites such as Bank of America and Chase.
- thedufer 13y ago"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".
- keepontruckin 13y agoI 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 13y agoNo, 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.
- danielzarick 13y agoI really love when I see products take this route. I'm also currently working on something that is passwordless. I think there is a small cognitive hump that new users have to get over, but I'm working on ways to make it smoother. Nonetheless, I believe this route is the future & we will continue to see more passwordless products, which will increase the general understanding of how to use them.
- ossreality 13y agoWhy do people seem to think they're the first to dream this up? Dozens of products don't use passwords because they use federated login, or they use Persona/BrowserID, or because they use a secure token via email. It's been done for basically forever. Please just go the Persona route though, it's so much less annoying and less of a hack than the email a secure link route.
- rgbrgb 13y agoI 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).
- stanleydrew 13y agoTotally agree. GMail with two-factor auth is a good solution, but then we're back to hoping that users adopt a relatively niche and optional security improving feature.
- gagege 13y agoWhat 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'd totally be willing to pay that price though, if it meant never having to be responsible for thousands of user's data again. The user becomes responsible for their own data.
- stanleydrew 13y agoThis is essentially what Google and Facebook, and to some extent even Apple, are attempting to become: giant stores of user data that you auth against. Also check out Mozilla's BrowserID if you're interested specifically in the auth piece.
- gagege 13y agoYep, 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.
- 13y ago
- ruddct 13y agoI recently built passwordless, email-based authentication into the iOS app I develop (http://varka.la http://varka.la). Still tweaking how it's messaged, though, as folks seem to be a little confused about how it's different than a normal registration flow one might see in another app.
- nathancahill 13y agoHave you heard of 2-factor authentication? Sounds pretty much like what you described. Specifically, the way Duo Security implements SSH logins.
- stanleydrew 13y ago2-factor auth is great. The suggestion is that if you are only going to implement one factor, it should look more like the "traditional" second factor. Basically we should flip two-factor author on its head. A user-defined password should be the second factor, not the first as is currently assumed.
- umeshunni 13y agoThat's essentially a chip-and-pin like system, right?
- helipad 13y agoI've wanted to bite the bullet with this, but not enough of a security expert to do it confidently. How does this stack up? I like the idea of keeping someone logged in, then they can choose to log back using whichever means they decided when creating their account - email, SMS, authenticator app.
- conorclearshot 13y agoMy worry is not so much the front end attack or access, but the data on the hosting servers being peeked at without a record of it, or any hacking required.
- tptacek 13y agoThis 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 "log in via Google Mail" --- people still hate it. 2. It assumes that the small subset of users who care about this problem are comfortable having all their security rest on their email account. That's not necessarily true. For instance, a decent-sized chunk of the power-users who care about password security already use password managers like 1Password, which this idea is not trivially compatible with. Services that actually care about security (a) store authenticators in ways that aren't easily recoverable in the event of a breach, and (b) offer two-factor authentication, which is superior to "go fetch this login token over email".
- napoleond 13y agoIt 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 https://news.ycombinator.com/item?id=7139641), the idea is just to flip the default for products implementing a single factor.
- stanleydrew 13y agoI 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?
- tptacek 13y agoYou mean, like 2-factor authentication? I like 2FA. Use a TOTP/HOTP scheme, for instance.
- gagege 13y agoDo 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.
- omgitstom 13y agoThe 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.
- redblacktree 13y agoBut 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.
- omgitstom 13y agoDefinitely 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.
- spellboots 13y agoMozilla Persona is basically this but better thought out. There is a good talk about it here: https://www.youtube.com/watch?v=nJff23UdNAI https://www.youtube.com/watch?v=nJff23UdNAI
- stanleydrew 13y agoThe 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?
- spellboots 13y agoYes: https://github.com/mozilla/persona-ios https://github.com/mozilla/persona-ios
- Nate630 13y agoSounds like we need an 'Internet' http://en.wikipedia.org/wiki/Kerberos_(protocol) http://en.wikipedia.org/wiki/Kerberos_(protocol)
- pgrous 13y agoTake a look at Steve Gibson's SQRL system (pronounced “squirrel”) SQRL = Secure Quick Reliable Login https://www.grc.com/sqrl/sqrl.htm https://www.grc.com/sqrl/sqrl.htm Illustrated guide here - http://www.sqrl.pl http://www.sqrl.pl
- simonhamp 13y agoWe've been doing password-less entry for years over SSH with certificates. You generate a key, share the public parts and do some magic with your private parts (ahem) and it all works. What I think the OP is looking for is a similar pattern for the web and browsers. Is there no way we could use the FileAPI to check for a keyfile? http://caniuse.com/fileapi http://caniuse.com/fileapi
- ryan-c 13y agoSSL/TLS client auth is an option, though the UI isn't great. http://en.wikipedia.org/wiki/SPKAC http://en.wikipedia.org/wiki/SPKAC
- jader201 13y agoThese 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 with a password -- and I have to have the phone on me. There are only three ways, that I can think of, to authenticate someone: 1) a password (or some other secret) 2) a token stored as a cookie or some other file on your computer/device 3) a token sent to/stored on a personal device. Most products already implement #1 and #2. They will look for a token, and if not present, will prompt for a password. In the case of third-party authentication (Facebook/Google/email), this authentication is still done via a token, and if not present, will prompt for password -- it's basically pass-through authentication. I don't think anything can be done to revolutionize either of these. That really only leaves us with #3. Texting a token to a phone works and prevents having to remember a password (or use an unsafe password), but it's still inconvenient. 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? This is about the only thing I can think of that would be a step in the right direction, but even then, there are probably still a handful of reasons why that would be problematic.
- stanleydrew 13y ago"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.
- jader201 13y agoRight, 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.
- lhgaghl 13y agoWaterken has solved phishing/authentication/CSRF/clickjacking all at once by doing approximately nothing. It has existed for years. waterken.sourceforge.net See specifically: http://waterken.sourceforge.net/web-key/ http://waterken.sourceforge.net/web-key/ and http://waterken.sourceforge.net/clickjacking/ http://waterken.sourceforge.net/clickjacking/