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

131–140 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#131

Post by JoshTriplett »

superuser2 wrote: post #125
bct wrote: post #42

Earlier quoted context omitted.

Ok, but only In the same way that typing in a username and password on a website allows them to track you.

To have a conversation with someone, you have to uniquely identify them, and correlate all the words they've said as coming out of their mouth and not somebody else's, then put all these words (which you've identified as being part of the same sentence) together into meaning. As you get to know someone, you correlate all these meanings into a mental model of the person, and use this to guide how you interact with the…

I agree with almost everything you just said, with one exception: while sites often need to have a notion of identity for their users, that identity should not correlate with the identity used on any other site, or with other alternate identities on the same site, unless the user wants that correlation.

A system based on pseudonyms allows anonymity through the creation of arbitrary new identities. With care, such a system can also support reputations for a given identity.

Re: Introducing BrowserID: A better way to sign in

#132

Post by ggchappell »

bct wrote: post #65
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…

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

Re: Introducing BrowserID: A better way to sign in

#133

Post by caf »

newman314 wrote: post #128

Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?). So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom. IMO, I think this needs a rethink.

The idea is that you would use this in situations where you currently would offer a "reset password via email" option - since this means you already treats control of the email address as identity.

Re: Introducing BrowserID: A better way to sign in

#134

Post by sid0 »

arkitaip wrote: post #45
stickfigure wrote: post #34

One huge problem: Email address != identity. I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy. Really this product should be called BrowserEmailAddress, n…

I understand the sentiment but simply because a solution doesn't cover all use cases (users must be able to change email addresses) doesn't mean it can't be usable. Also, we constantly use services were you cannot change your email address because that's how the system identifies you, so this dependency of email addresses isn't new at all. (One work-around would be to use an disposable e-mail address service and redi…

aka add a level of indirection, just like the solution to every other problem in computer science. :)

Re: Introducing BrowserID: A better way to sign in

#135

Post by nl »

JoshTriplett wrote: post #129
nl wrote: post #119

Earlier quoted context omitted.

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…

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

Re: Introducing BrowserID: A better way to sign in

#136

Post by lojack »

Do people really consider OAuth2 difficult to implement?

Also, not trying to knock BrowserID or say that it'll never work, but due to browser compatibility this is still probably 5 years off before I'd begin using it. From what I can gather it requires postMessage which alienates IE7 users.

Re: Introducing BrowserID: A better way to sign in

#137

Post by bct »

JoshTriplett wrote: post #116
bct wrote: post #109

Earlier quoted context omitted.

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?

Re: Introducing BrowserID: A better way to sign in

#138

Post by bct »

pavel_lishin wrote: post #130
Osiris wrote: post #51

Earlier quoted context omitted.

Isn't one of the advantages of this system is that your password doesn't get stored by the website? Just some type of token? If their database gets stolen or leaked, they shouldn't be able to hash attack your password and gain access to it since it's not there. I'm just assuming it works this way, as passing the password along would defeat the security of the system and make you more vulnerable.

You still have to enter your e-mail and a password into the BrowserID popup; and with OAuth, the sites using it didn't store your password either. I literally don't see a major difference here, except that now we're using email instead of whatever bullshit identifier you could have used with other OAuth providers (e.g., your Livejournal username, your Facebook account, etc., etc.) If I'm wrong, I would love to be enl…

browserid.org ("the BrowserID popup") is just a way to bootstrap the system. The idea is that browsers and email providers will support this protocol and browserid.org will be totally unneccessary.

The major difference is it's totally irrelevant to the site (relying party) what provider you're using. The site doesn't need a login page with a facebook button, a twitter button, a livejournal button, etc., it just needs a "sign in" button.

Re: Introducing BrowserID: A better way to sign in

#139

Post by bct »

dendory wrote: post #112

How is this any different than current single signon systems, like Microsoft Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and anyone can run their own but lets not forget users dont care at all about that..

As a user, once your browser and email provider support it, it's single-click login (and signup), without any redirects.

As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".

Re: Introducing BrowserID: A better way to sign in

#140

Post by ora600 »

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…

You see, passwords suck. Big time. They are extremely vulnerable to brute-force attacks, people forget them, people write them down on post-it notes, and people use the same password on every single site. Not to mention that the website has to store your password securely, and not every website has amazing track record doing that.

Passwords make the world less secure.

So we need to replace them with something. And that "something" has to be secure and easy to use.

Turns out that this is a difficult problem to solve, so we keep trying. I agree that OpenID is not exactly the perfect solution, but it doesn't mean that there is no problem to solve.

Post reply on HN