Hacker News Reader

Comment by SeoxyS | Hacker News Reader

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 basically what this does:

* asymmetric crypto authentication in the backend.

* control over email address == authentication.

* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).

* falls back to regular email authentication we see every day.

I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?

View on HN

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 News) that uses BrowserID.

5. Your browser sends Hacker News an message saying "my user is whoever@gmail.com", that is signed with the private key generated in step 2.

6. Hacker News looks at the "gmail.com", grabs gmail's public key (the one that signed your public key in step 3) and verifies the signatures.

Hacker News now knows that you control whoever@gmail.com.

The process is described fairly well (diagrams and everything) at http://lloyd.io/how-browserid-works

Read through your link, and here's just an observation -

> BrowserID is a decentralized identity system

BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization, is it? Practically speaking.

(edit) Added practically speaking... and ease up on that downvoting, distinguished HN comrades. Non-natural post scores hurt my feelings.

"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 doesn't make this system less secure for you.

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 understood and easy to implement seems appropriate.

What's the alternative? Using some kind of pseudo-GUID and then maybe a derivative of the Paxos distributed consensus algorithm to decide if it is to be trusted? I'd imagine there would be a good number of PhDs in that approach before a system like that would be close to being ready for actual implementation.

This system seems just about as decentralized as is practical. If you disagree I'd be very happy to hear alternatives.

You can have fully decentralized identities quite trivially: just create a public/private key. No consensus algorithms required. With browsers now supporting synchronization features to connect the browsers on all systems used by a single user, such a system could actually work quite well now, without the usability issues it would once have had.

This is a variety of SPKI[1], right? I was thinking of a conventional PKI approach, with an adapted web of trust to verify identities [2].

You are right - theoretically this could work. But it would pretty much take a "boil the ocean" approach to make it work.

Browsers would need to implement a secure (private) keystore, and presumably some way to sync that to other browsers.

A whole new standardized authentication flow would need to be created, which wouldn't be the same as the existing certificate-based authentication (which no one uses anyway)

[1] http://en.wikipedia.org/wiki/Simple_public_key_infrastructur...

[2] http://en.wikipedia.org/wiki/Public_key_infrastructure#Web_o...

Huh? Browsers support client SSL certs today, but for some reason nobody uses them except intranets.

"boil the ocean"

This particular ocean should be fairly easy to boil with a browser extension for all popular browsers.

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

http://en.wikipedia.org/wiki/Zooko%27s_triangle

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

Uh, GMail users are a minority. Besides, the system is decentralized - the fact that most people can choose the same server is not a problem of the system.

Besides, the fact is that most websites already use email, so BrowserID is not any worse than the status quo.

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 e-mail provider.

Your link includes this line:

> 4. Public key(s) for gmail.com are attained from a well-known location on their servers (specifics TBD).

This service is absolutely necessary to get BrowserID working, but they haven't figured out the specifics yet. I think they need to get beyond that "TBD" pretty darned quick.

Something like DomainKeys Identified Mail (DKIM).

That sounds like such an obvious and fairly simple solution. Thanks for the explanation!

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.

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

See the teaser at https://browserid.org/primaries , and the documentation at http://lloyd.io/how-browserid-works .

I've read it more thoroughly now, but I'm still not sure where you're coming from. You'd rather use a secondary identity authority, even when a primary is available? Or are you saying you'd like to require a full send-me-an-email-and-i'll-click-on-a-link verification every time you log in to a relying party?

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 just use your browser to sign in? (No direct answer, but I assume so. Or will be this way soon.)

* Open source? Great.

I didn't really expect any technical answers. But they did mention the blog and there's got to be some good posts coming soon. Subscribed.

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?

And let's not forget that you can add any site to Lastpass, while with BrowserID you can add a site that already implemented it. That sucks.

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.

There are legitimate reasons to whitelist OpenID providers, especially if you are dealing with $$ or want to minimize support costs.

Why do you think a "properly implemented" OpenID site should allow the user to use any authentication provider? The relying party site is trusting the OpenID provider to authenticate its users. Wouldn't sites with real security requirements want to vet providers before trusting them?

Exactly right.

And all OpenID providers have different attribute exchange protocol extensions. If you use them, you can effectively allow only those you have tested.

I don't see the OpenID here. I see them restricting me to only 4 third-party sites. Since there doing that, using OpenID or using each third party's system makes no difference. OpenID's supposed to be decentralized, but how do I log in with http://stevearm.com?

I don't think it's widely used. The average site that doesn't want to provide their own username is using Facebook nowadays. Stack Overflow etc. seems to be the only bigger site that uses it, and it's kind of a mess over there.

Do an online poll and ask people "Do you know your openID" vs "Do you know your email". Users are trained to use emails for login, and that's a significant investment already.

That was a brief failure of communication when OpenID was new.

Have a Google or Yahoo account? Your email address is your OpenID. Of course nobody is going to manually enter an OpenID URL. Why would they need to?

Read the "Verified e-mail protocol" thingy instead. The blurb the link on HN points to is indeed completely useless.

They don't verify e-mail ownership through crypto means - they use the fact that e-mail is identity.

Basically, your mailhost (or a proxy, like browserID) holds your public key, while your browser holds your private key. Now, when you authenticate against any BrowserID auth site, you simply sign with your private key and provide the e-mail address. Since the browser stores both, that's a trivial interaction.

The site then verifies your signature with the mail host. (That's where the asymmetric crypto comes in)

At least that's how I understand it - their explanation is indeed a bit cryptic. Hope they clean it up.

i thought the video demo was pretty clear for the consumer perspective-- to a user, they click sign in, tell a site what email they want to identify with to that site, don't have to make a specific login to that site, and the browser handles everything.

They give you a token, you do a GET request to browserid.org with it and get the user's email, that's all. The user has to register their email with browserid.org first.

Wasn't one of the benefits that you don't need to rely on a third party service?

The third-party service handles the case where the user's browser doesn't handle BrowserID natively, which makes it possible to adopt this service without waiting for user's browsers to catch up.

I believe you will definately rely on one (of many possible) 3rd parties.

Reply on news.ycombinator.com