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

141–150 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#141

Post by starwed »

kpanghmc wrote: post #110

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…

Did you read the article? This is an attempt to fix all those issues you list.

Re: Introducing BrowserID: A better way to sign in

#142

Post by bct »

nl wrote: post #123
codyrobbins wrote: post #53

Earlier quoted context omitted.

To this day I still do not understand how this inane argument happened to be the single thing that killed OpenID. How is ‘cody.my-open-id-provider.com’ more confusing as a login than ‘cody@my-email-provider.com’? Hint: it’s not. I’m not one for conspiracy theories, but the whole URL-versus-email argument against OpenID seemed like the excuse various people used to put a nail in OpenID’s coffin when they didn’t like i…

I'm a reasonably competent web user. I've implemented OpenID. I run my own Open ID server. I've implemented Shibboleth (and lived!). I know that Yahoo is an open ID provider, and I think Google is too, but when I'm presented with an old-style (URL) OpenId login I don't have a clue what to enter to use either my Yahoo or Google account to login. Yes, I know that now most login forms provide easy links to use Google or…

Google/Yahoo/etc. could have given you a memorable OpenID if they wanted.

It's a good point though, the fact that email addresses have to be somewhat memorable/human-readable by nature is a good thing for BrowserID.

Re: Introducing BrowserID: A better way to sign in

#143

Post by rlpb »

This looked great until I got to certification. At this point I think they've just re-invented X.509 and added browser/Javascript integration.

Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of mail=me@example.com, Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does.

This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.

Re: Introducing BrowserID: A better way to sign in

#144

Post by billforsternz »

Iaks wrote: post #108
lucian1900 wrote: post #28

Earlier quoted context omitted.

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

This is the new +1

Re: Introducing BrowserID: A better way to sign in

#145

Post by rednaught »

ggchappell wrote: post #132
bct wrote: post #65

Earlier quoted context omitted.

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

This is very thought-provoking. One observation: I don't completely understand all this yet, but it appears that what distinguishes the system from one that is entirely trusting of client-side JS code, is the fact that the e-mail provider signs user's key. That means that we must be able to get the e-mail provider's public key somehow. There is supposed to be no central authority, so we must get it directly from the…

Something like DomainKeys Identified Mail (DKIM).

Re: Introducing BrowserID: A better way to sign in

#146

Post by dschobel »

joeyespo wrote: post #97
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…

Wow, I had exactly the opposite experience. Tons of thoughts popped into mind as I watched. If my brain had a replay button, it would say: * Ok, what if I have multiple accounts? Ahh, nice. * Hmm it would be cool if it worked like LastPass, where you get great security and only one password to remem... ha, nice, it's very similar! * Email verification? ....yep, check. * Can you lock the browser so that nobody can jus…

Exactly, I think most users of LastPass or 1Password had the same thoughts.

The question I do have: why would I use this over something like LastPass which already has plugins for every browser and device most people will ever care about?

Re: Introducing BrowserID: A better way to sign in

#147

Post by bct »

nl wrote: post #119
huhtenberg wrote: post #92

Earlier quoted context omitted.

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.

The last numbers I saw put Gmail at under 10% of email account marketshare. Hotmail and Yahoo both had much bigger shares. It's difficult to imagine an authentication system that doesn't have some kind of centralized mechanism for making sure identities aren't duplicated. In this case, delegating that to a combination of two existing technologies (DNS for the domain, then email for the username) that are open, well u…

Zooko's triangle[1] in action:

A BrowserID (like an email address) is memorable and secure, but not decentralized (it's centralized in DNS).

A cryptographic key is decentralized and secure, but not memorable.

Systems that are memorable and decentralized, but not secure, don't address these use cases at all.

(And then there's Namecoin[2], which is a fascinating development, but not likely to see broad adoption in the near future.)

[1]: http://en.wikipedia.org/wiki/Zookos_triangle [2]: https://en.bitcoin.it/wiki/Namecoin

Re: Introducing BrowserID: A better way to sign in

#148

Post by NHQ »

This is just another web based open sign-in. Why did they tie this to email, of all things?

My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.

Re: Introducing BrowserID: A better way to sign in

#149

Post by tzs »

swaits wrote: post #94
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.

Will you and the website owner each verify the key fingerprints? What I'm getting at is it's a hard problem to solve, because users want it to be quick and easy. But that often works against the stated goal of security.

I don't see why the website would need to verify my key fingerprint. Verification is needed when you care who a key comes from. For typical websites, they don't need to know who I am. They only need to know enough to recognize on subsequent logins that I'm the same person who provided the key at account creation, and the key itself has all they need for that.
Post reply on HN