Introducing BrowserID: A better way to sign in • Hacker News Board

Re: Introducing BrowserID: A better way to sign in

#181

Post by 21echoes » Sat, Jul 16, 2011, 7:40 AM UTC

speckledjim wrote: post #166

starwed wrote: post #141

Earlier quoted context omitted.

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

So now when your email address gets hacked, ALL your usernames and passwords to every website are also hacked! At least with normal un/pw you need to request a password reset from the website. I don't think we should be tying logins to email.

by tying all your logins to email, you're left with only one account that you can focus on keeping secure and un-hacked (or a few, as BrowserID allows for multiple emails). The BrowserID is also in talks about support one-off identity generation via the browser, bypassing email on sites which you don't want to identify with.

BrowserID supports password reset requests, which can be built into the browser

email is the single most user-recognized signifier of identity we have on the internet today. tying identity to anything other than email just seems silly

Re: Introducing BrowserID: A better way to sign in

#182

Post by 21echoes » Sat, Jul 16, 2011, 7:41 AM UTC

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…

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.

Re: Introducing BrowserID: A better way to sign in

#183

Post by 21echoes » Sat, Jul 16, 2011, 7:48 AM UTC

stickfigure wrote: post #79

paulosman wrote: post #63

Earlier quoted context omitted.

"Sure, every website can implement this flow, and users could could go to every website they've ever logged into and update their email address... assuming it all works properly even though they might not have access to the old email address anymore." And how is this different than the current situation? Nearly all web sites require an email address. With BrowserID, you at some point confirmed ownership of that email…

Fast forward another ten years. Do you really think typical websites will still ask people to create usernames and passwords? I predict that the current trend of "offload that crap to Facebook/Google/BrowserID" will continue. Even BrowserID.org makes that assumption. The question is whether a BrowserID identity is as useful as one of the established identity providers. You start out with a chicken-and-egg problem; we…

facebook, i agree, makes sense for an assertion of your public, real-name identity. there will always be sites and situations where i do not want my real name associated with what i do there.

google auth is just one provider of the same identity as browserID-- an email login. so, imo, browserID is a strict improvement, in that it is more seamless than google auth in regular usage (leveraging the browser as the user agent), and works with more providers.

Re: Introducing BrowserID: A better way to sign in

#184

Post by 21echoes » Sat, Jul 16, 2011, 7:50 AM UTC

ignifero wrote: post #66

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…

OTOH, facebook id != identity, neither is twitter username. There will always be some id that you won't be able to change. But you are right that email is a bad choice, and i was surprised they give away the email address to developers. They should provide the browserid.org ID only.

it's a compromise move-- the reason most sites today rely on email, fb, or twitter is that it's a way to 1) contact the user, and 2) tell/help the user to tell his/her friends about something.

the team is in talks now about cooperation with another mozilla labs project centered around 1-off email generation for quick and easy anonymity with sites

Re: Introducing BrowserID: A better way to sign in

#185

Post by pornel » Sat, Jul 16, 2011, 12:37 PM UTC

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.

> you are trusting your email provider to be absolutely secure

Yes, because e-mailed password reminders are keys to my kingdom already.

Re: Introducing BrowserID: A better way to sign in

#186

Post by bxc » Sat, Jul 16, 2011, 6:23 PM UTC

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.

if you're interested in ssh-like functionality and http, I just wired browserid into my shell server for in-browser logins: http://benctechnicalblog.blogspot.com/2011/07/browserid-in-b...

Re: Introducing BrowserID: A better way to sign in

#187

Post by bxc » Sat, Jul 16, 2011, 6:30 PM UTC

Dove wrote: post #169

newman314 wrote: post #163

Earlier quoted context omitted.

Wondering why I was downvoted for pointing this out. But anyways, my impression from reading the page was this is not just used as a password reset scenario but as a general login method. Which if you agree with, leads us back to the scenario where authentication & authorization lies solely with the email account, which if compromised is the single point of failure. I would appreciate it if someone were to help point…

If an email account can be used for password reset, a compromised email account can be used to log in. Since much of the internet already works this way, the proposed system has a neutral effect on security, while making things easier for users. In effect, any site that offers a password reset via email is already using your email as your identity.

I actually use this as the primary authentication mechanism for sites I rarely/occasionally visit... password reset at every login!

Re: Introducing BrowserID: A better way to sign in

#188

Post by a3_nm » Mon, Jul 25, 2011, 4:26 AM UTC

a3_nm wrote: post #105

paulosman wrote: post #30

Earlier quoted context omitted.

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

Apparently, it does not do what I hoped it would. Assertions are about ownership of an email address, not about control of the private part of a key pair.