Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing BrowserID: A better way to sign in

identity.mozilla.com

Post reply on HN
Print view View original

101–110 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#101

Post by joeyespo »

wmf wrote: post #38
ora600 wrote: post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

This already exists, but the UX is terrible and there's a chicken-and-egg problem in getting it fixed in every (deployed) browser. http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...

Yeah, even using them over at GitHub (well, pushing with Git over SSH in general) has proven to be a rather steep learning curve for a lot of people. But hey, it's being widely adopted there, so that's a step in the right direction for this.

Re: Introducing BrowserID: A better way to sign in

#102

Post by bct »

huhtenberg wrote: post #92
JoshTriplett wrote: post #87

Earlier quoted context omitted.

"decentralization" doesn't mean "forced decentralization". Anyone can register a domain name and have their own email at that domain, so anyone can create an identity. And ignoring the transitional bits in BrowserID, eventually that identity gets controlled entirely by the public/private keys in the user's browser. Or, in other words: if you don't trust Google, don't use gmail; that someone else chooses to do so does…

Sure, I understand that of course. I am just saying that practically speaking this property is not going to matter much in the world where everyone and their dog is on GMail. It is certainly nice to have though.

A system that assumes that everyone is on GMail will tend to ensure that everyone is on GMail, whether or not that's a good thing.

Decentralization leaves the possibility of that situation changing open. That matters.

(Or, less philosophically: there was a time that everyone and their dog were on Internet Explorer. I think we're all glad that we didn't close the door to browsers other than IE.)

Re: Introducing BrowserID: A better way to sign in

#103

Post by JoshTriplett »

TillE wrote: post #69
SeoxyS wrote: post #52

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…

How did OpenID fail (it's widely used)? How is it complicated for the user? Properly implemented, OpenID looks like this to the user: http://springpadit.com/login And something like this for the average developer: https://github.com/omab/django-social-auth

That site fails terribly at supporting OpenID: it only supports four authentication providers, and doesn't allow a user to enter an arbitrary OpenID URL.

"Properly implemented", OpenID looks like http://ikiwiki.info/ikiwiki.cgi?page=index&do=edit : a choice of common OpenID providers to help users who don't understand OpenID, an option to use an arbitrary OpenID, and an option to use a username and password.

Properly implemented, BrowserID looks like one big shiny "sign in" button, and yet it still supports any service the user wants to use, and better yet no third-party service at all. Seems like a big improvement to me.

Re: Introducing BrowserID: A better way to sign in

#105

Post by a3_nm »

paulosman wrote: post #30
ora600 wrote: post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

Have you read the spec? https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol That's essentially what this is... with a verification service and web based UI to help bootstrap it.

A good way to check if does the right thing is to make sure it does not depend on the security of DNS. Is this the case? (I'm still trying to find out.)

Re: Introducing BrowserID: A better way to sign in

#106

Post by JoshTriplett »

bct wrote: post #93
JoshTriplett wrote: post #90

Earlier quoted context omitted.

Why would you want your email provider to support BrowserID? I'd consider it invasive for my email provider to do anything different to interfere with the email verification process for another site.

I don't follow you, what's invasive/interfering about it? You & your browser can decide whether any of the steps of this process actually happen.

The proposed BrowserID standard specifically suggests that the browser should ask the email provider to validate the email, and only fall back to the usual email-me-a-link validation if the email provider doesn't "natively" support BrowserID. I'd prefer to always go through email-me-a-link verification (ideally with some kind of crypto involved), rather than involving the email provider in any way other than SMTP and IMAP.

Re: Introducing BrowserID: A better way to sign in

#107

Post by bct »

JoshTriplett wrote: post #100
stickfigure wrote: post #58

Earlier quoted context omitted.

Is there some sort of account ID other than an email address? It looks like the email is all that gets sent to the website (although I didn't read deeply enough to be sure). If you change (add new, remove old) your email address at browserid.org then revisit a site you authenticated to before, what happens?

Indeed. Ideally, the site would end up with the user's public key, and optionally their email address; they should use the former as the primary key in their database, and the latter as an easily-changed property.

That would be nice except I think that you will have different keys for different browsers, and for different machines.

Presumably you could sync them up if you really wanted to, but it would be an awful user experience if that was mandatory.

Re: Introducing BrowserID: A better way to sign in

#108

Post by Iaks »

lucian1900 wrote: post #28
ora600 wrote: post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

This. Perhaps ssh+http is the solution.

Where is 'this.' coming from? Coding syntax?

I just don't get it. I've seen it in HN comments for a few days now, but I fail to understand how 'this.' relates any new information. Reply indenting already tells me you are referring to an antecedent post. (A specific post in fact.)

Am I missing something, or is this just a new web fad I'm not savvy too? (Second option is not entirely unlikely...)

Re: Introducing BrowserID: A better way to sign in

#109

Post by bct »

JoshTriplett wrote: post #106
bct wrote: post #93

Earlier quoted context omitted.

I don't follow you, what's invasive/interfering about it? You & your browser can decide whether any of the steps of this process actually happen.

The proposed BrowserID standard specifically suggests that the browser should ask the email provider to validate the email, and only fall back to the usual email-me-a-link validation if the email provider doesn't "natively" support BrowserID. I'd prefer to always go through email-me-a-link verification (ideally with some kind of crypto involved), rather than involving the email provider in any way other than SMTP and…

Can you link me to where you're reading that? I don't see anything like that (but I've only skimmed the documentation).

Re: Introducing BrowserID: A better way to sign in

#110

Post by kpanghmc »

Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another.

Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.

Post reply on HN