Live data from Hacker News

Introducing BrowserID: A better way to sign in

identity.mozilla.com

151–160 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#151

Earlier quoted context omitted.

"My Facebook account is an identity first and foremost." Now imagine 5 years ago you said "My Friendster account is an identity first and foremost."

I'm not saying that identity management won't be an ongoing problem, especially if large repositories of identity rise and fall with fashion. On the other hand, email is already known to be an unstable key for identity. And the "market" for identity providers is a lot more mature than it was 5 years ago. Besides, what if Friendster had established itself as a public identity provider 5 years ago? Maybe we would be us…

Downvotes? Wow, that's unnecessarily harsh.

Two close friends of mine were the #2 and #4 employees of Friendster. I seriously considered becoming #3. I had a pretty good outsider's view of the early years.

Yeah, they screwed up the scaling pretty badly. But even worse they screwed up the business - after you set up your profile and looked around, there wasn't much more to do (unless you were single and looking). People were already using Friendster as an identity (emailing links as a "you mean this person, right?"). Maybe if they'd opened an API and enabled third-party apps, they could have maintained this position. It's a big "what if" but it can't be dismissed outright.

Re: Introducing BrowserID: A better way to sign in

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

Something like this already exists. Your browser can already identify itself with a certificate. The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.

Dartmouth does this as well, and I agree the interface sucks in browsers. Especially since most browsers will gladly show expired certificates for you to choose so you have to manually prune your list.

Re: Introducing BrowserID: A better way to sign in

#153
post #65
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…

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

Re: Introducing BrowserID: A better way to sign in

#154
BrowserID is a good first step, but ultimately as a website owner I'd much rather authenticate with Twitter/Facebook, since it makes it easier for me to figure out who the user is/ask them to share with friends.

Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication.

I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.

Re: Introducing BrowserID: A better way to sign in

#155

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.

BrowserID only fixes those issues if it ends up as the only game in town. Otherwise, it's simply going to be tacked onto the end of a daunting list of other OpenID / BrowserID providers that users will have to choose from.

Re: Introducing BrowserID: A better way to sign in

#156
post #140

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 th…

I never said that there wasn't a problem. I'm simply saying that the solutions we've come up with so far have not yielded a net gain. If anything, the site owners that I know who have incorporated OpenID / Facebook Connect / etc. into their sign up / login forms have said that they have to answer more questions from users having login issues than ever before.

Re: Introducing BrowserID: A better way to sign in

#157
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…

It's a step forward. There were security issues. Some sites used "name" as the user identifier, because obviously nobody on Facebook shares the same name (sarcasm).

Even email isn't safe, unless all the OAuth providers validate the email. Does Twitter allow me to change my email address to "president@whitehouse.com", and then return that to OAuth consumers as my email? I don't know.

There's too many things ways to shoot yourself (or someone else) in the foot.

Re: Introducing BrowserID: A better way to sign in

#159
post #123

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…

What bearing does the fact that Google and Yahoo chose shitty hard-to-remember OpenID URLs have to do with the overall fact that OpenID uses URLs for authentication? That’s like saying using email addresses for authentication is a terrible idea because mail administrators can assign really hard-to-remember email addresses. The solution is simple: set things up so they’re not hard to remember. Again, there is no reason why your OpenID login can’t be ‘name.my-open-id-provider.com’.

I would be willing to bet Google and Yahoo made their OpenID URLs hard to remember because they already had single sign on products that they wanted in the limelight preferentially over OpenID. However, cursory support of OpenID made them both look like supporters of open standards even if their implementation (hard-to-remember URLs) doomed it to underuse.

Post reply on HN