Live data from Hacker News

A bold but simple login system

notes.xoxco.com

61–70 of 101 posts

Re: A bold but simple login system

#61
post #23

The problem with "solutions" like these is that they start with faulty premise that "passwords are broken". This particular idea sounds like death by a million cuts.

Read this article from a few years ago http://www.uie.com/articles/three_hund_million_button/ It is titled "The $300 million button" and details actual user experience at an ecommerce site. Note how many users even know what email address they used, how many got the password right, daily password resets etc.

That article indicts registering to purchase and has almost nothing to do with the password topic in question. Can you imagine having to wait for a login email every time you tried to make a purchase? Ugh!!

Re: A bold but simple login system

#62
So what happens when someone's email account is compromised?

Currently there's a fair chance that the victim can reset passwords and change contact info for their online services before the hacker bothers to do so. But this would be impossible if email were used as the sole form of authentication.

Re: A bold but simple login system

#63

I had to read this article twice to make sure I was understanding it right. I honestly see zero benefit in this approach. It does not speed up the login process at all. The only thing it accomplishes is not requiring the user to remember a password. Additionally, it puts way too much power in the hands of random email servers. What if my email system at the office goes down for a few hours. Am I locked out of all web…

You only get locked out of a website if you delete your cookies while your email provider is down. How often does that happen? This idea doesn't speed up the login process, but it accomplishes a few other useful things. The server doesn't store passwords, so a breach of the server doesn't compromise other services for which users had duplicate passwords. And users can't compromise their own accounts by choosing weak…

Valid points, especially the security issues.

Re: A bold but simple login system

#64
post #48
post #2

This would drive me up the wall. I don't want to have to sit in my mail client, waiting for it to pull down the message that may-or-may-not have arrived at my mail host yet, when it's incredibly easy to use a password manager for everything without having to leave my browser. He bemoans the number of controls you need to interact with to log in, but to get to log in with his method, I need to put in my email address…

The idea here is you only need to log in on a device once (or as often as you delete all your cookies). After that the site would remember you, so there really wouldn't be that much waiting on emails to arrive. Definitely not something I would want for my bank account, but who cares for logging on to a support forum or some other trivial account.

So why not just make the session last forever the same way, but using a password instead of requiring me to login to my email and click a link? I logged into Facebook the first time and as long as I didn't delete cookies, I could go to Facebook on that device today, tomorrow, next week, next month, next year... And never have to put my password in again.

This just adds more waste...

Re: A bold but simple login system

#65
Am I crazy in thinking that this whole problem should have been solved a long time ago by making password management a responsibility of the browser, either by baking it in or mediating the exchange?

Combined with a simple standard for credential exchange (get request to example.com/login to get the list of required fields, post to https://example.com/login to login. Or more likely, some existing standard that handles more cases and is already thought out) this whole annoying problem is no longer affecting every person who uses the web.

Is it too late for this? I feel that it probably would be very difficult to make this work now, it's too late and the browsers wouldn't go up against google and facebook who now want to own and track your identity.

That makes me sad, that kind of stagnation cuts off whole important areas of progress for web users.

Re: A bold but simple login system

#66
I remember being intrigued by Google's "Sesame" experiment (covered on HN at https://news.ycombinator.com/item?id=3469692) where they logged you in via a QR code processed via your mobile.

Relying on something you have (mobile phone with a trusted app on a trusted network) instead of something you know (passwords) can be an interesting choice. Ideally you'd require both (something you know and something you have), but we want to avoid passwords.

Re: A bold but simple login system

#67

Am I crazy in thinking that this whole problem should have been solved a long time ago by making password management a responsibility of the browser, either by baking it in or mediating the exchange? Combined with a simple standard for credential exchange (get request to example.com/login to get the list of required fields, post to https://example.com/login to login. Or more likely, some existing standard that handle…

Check out Mozilla Persona (used to be called BrowserID).

https://login.persona.org/about

Re: A bold but simple login system

#68
Ben, I like where you're going but I think we need to go just a little bit further to make it viable. In particular, it's email that's the weak link (so to speak). But it's entirely possible and desirable to replace email with something that has emails positive qualities without it's drawbacks. I'm thinking a secure, realtime channel to which only you have access, and a notification system that let's you see (on all your devices) what got posted there. Anyone (or anything) in the world can post to it, and they are guaranteed that you'll get first crack at the data. (In this case the data is a one time URL).

What sort of thing represents a secure, real-time channel to which only you have access? Note that, unlike email, we are not interested in queueing messages in this channel. My first thought runs to a public URL, a place where anyone can post anything, and it will appear on all your devices (possibly within the browser).

So basically as long as you maintain credentials to access that channel, sites have a good way to give you a one-use login URL.

In an ideal world, you're browser would have a password protected private key and knowledge of what your personal URL is. All sites requiring login would ask the browser for that URL, and the site would send a one-time login URL to the channel URL, and the browser would be smart enough to just follow the link.

Bam, login nirvana.

Re: A bold but simple login system

#69

I had to read this article twice to make sure I was understanding it right. I honestly see zero benefit in this approach. It does not speed up the login process at all. The only thing it accomplishes is not requiring the user to remember a password. Additionally, it puts way too much power in the hands of random email servers. What if my email system at the office goes down for a few hours. Am I locked out of all web…

You only get locked out of a website if you delete your cookies while your email provider is down. How often does that happen? This idea doesn't speed up the login process, but it accomplishes a few other useful things. The server doesn't store passwords, so a breach of the server doesn't compromise other services for which users had duplicate passwords. And users can't compromise their own accounts by choosing weak…

To be fair, the user can still compromise all their accounts by choosing a weak password for their email account. It does reduce the onus on them from coming up with dozens of (hopefully) unique, strong passwords to one, which is certainly an improvement.

Re: A bold but simple login system

#70
Outside of transfering money, I think you should structure your site so that logins are not necessary. For example, if I wasn't the only "drcube" on Hacker News, I wouldn't be upset. Names in meat space aren't unique, why should we expect them to be on the web?

Next time you think about starting a web service (that doesn't handle money!), think about what you lose by getting rid of user accounts entirely. It probably isn't much.

Post reply on HN