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

41–50 of 59 posts

Re: Passwordless Products

#41

Post by pauljohncleary »

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

this exists as a new protocol for app developers to build on, see: https://tent.io

Re: Passwordless Products

#43

Post by kelnos »

pgeorgi wrote: post #31
Zikes wrote: post #21

Earlier quoted context omitted.

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.

No, but for many use cases it's secure enough. Especially when you consider the tokens are short-lived and single-use

Re: Passwordless Products

#44

Post by simonhamp »

We'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

Re: Passwordless Products

#45

Post by jader201 »

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

Re: Passwordless Products

#46

Post by stanleydrew »

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?

Re: Passwordless Products

#47

Post by ryan-c »

simonhamp wrote: post #44

We'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

SSL/TLS client auth is an option, though the UI isn't great.

http://en.wikipedia.org/wiki/SPKAC

Re: Passwordless Products

#48

Post by stanleydrew »

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.

Re: Passwordless Products

#49

Post by arnarbi »

dpcan wrote: post #36
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 "…

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…

This is already mainstream. Facebook even pulls the code directly from your SMS if you are logging into their Android app.

It's just that it's a second factor to the password. Your phone can be stolen as well (although such theft is harder to scale) - so keeping the knowledge-test around is important.

I agree though, if you don't care about security, OTPs are potentially much more convenient than traditional passwords.

Re: Passwordless Products

#50

Post by stanleydrew »

dpcan wrote: post #36
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 "…

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…

Be careful here. The SMS "from" number can be spoofed. So it doesn't quite work to have a user simply reply with 'Y' to an authentication text, unless the reply includes something only known to the service and the user.
Post reply on HN