Introducing Mozilla Persona, An Identity System for the Web • Hacker News Board

Re: Introducing Mozilla Persona, An Identity System for the Web

#111

Post by carlesfe » Thu, Jul 12, 2012, 3:26 PM UTC

callahad wrote: post #73

carlesfe wrote: post #69

Okay, I have read the specs, the FAQ, the diagrams, and tried some examples, but I can't really understand how it works. Could somebody do a quick summary for me? I would appreciate it very much.

I really, really need to post something like this on our blog soon. Watch http://identity.mozilla.com/ for something more polished next week or so. I'd also strongly urge you to just try implementing it on a site. It'll literally take less than 30 lines each of javascript on the frontend and python on the backend, and it'll really demystify the flow between the site and the user. As an analogy, we work really similar…

Thank you so much for this explanation.

For me, the big question was about whether email providers supported key signing without having to click on an email. Now I see that both ways work the same.

Re: Introducing Mozilla Persona, An Identity System for the Web

#112

Post by Angostura » Thu, Jul 12, 2012, 3:26 PM UTC

gamzer wrote: post #61

shalmanese wrote: post #37

Earlier quoted context omitted.

Why don't they call them lightweight themes?

This comment sounds so innocent but it really started me thinking. When should one call things simply by their name and when should one create a new name? Would Twitter be the same if it was for short text messages? Or are Tweets so different that they deserve their own name?

Brands have value that can be protected with trade marks. You can't protect generics with trade marks (easily)

Re: Introducing Mozilla Persona, An Identity System for the Web

#113

Post by drcongo » Thu, Jul 12, 2012, 4:04 PM UTC

StavrosK wrote: post #88

drcongo wrote: post #86

Earlier quoted context omitted.

That provided a pretty confusing journey. First attempt: I clicked the Browser ID button, entered my email address on Persona, got redirected back to your site with no messaging. Tried again, it asked me to give a password this time. Did so, but then didn't redirect me back to your site. I then had to manually go back to your site and hit the BrowserID button for a 3rd time, which then took me to a Persona page to lo…

That's odd... The first time, you probably needed to verify your email, and I'm using the old API, so it doesn't sign you in right away. The second time, I don't know why it didn't log you in, I'll have to look into it...

I'm not sure it's your issue, it seemed more like it was problem at the Persona end. Unless of course Persona was sending useful messages back to your site but your end wasn't handling them.

Re: Introducing Mozilla Persona, An Identity System for the Web

#114

Post by StavrosK » Thu, Jul 12, 2012, 4:05 PM UTC

drcongo wrote: post #113

StavrosK wrote: post #88

Earlier quoted context omitted.

That's odd... The first time, you probably needed to verify your email, and I'm using the old API, so it doesn't sign you in right away. The second time, I don't know why it didn't log you in, I'll have to look into it...

I'm not sure it's your issue, it seemed more like it was problem at the Persona end. Unless of course Persona was sending useful messages back to your site but your end wasn't handling them.

I'm not sure it's my issue either, the whole thing is pretty much plug and play using their library... It's rather old, however, there might be something they've fixed. I'll have a look and see if I can upgrade it.

Re: Introducing Mozilla Persona, An Identity System for the Web

#115

Post by zaroth » Thu, Jul 12, 2012, 4:59 PM UTC

callahad wrote: post #67

zaroth wrote: post #57

Earlier quoted context omitted.

Thanks for taking the time to respond. At least in the case of password resets, it's the site deciding they want "email" to be the weakest link, and many sites will require at least a little bit more (like secret questions) after a reset. In this scheme, email is by definition the weakest link. The secondaries can never go away, unless sites are willing to straight up refuse customers based on their email address. Th…

Oh, sorry, there absolutely are prominent ways to log out / flush the keypair manually. It's after 02:00 local, so I need to get some sleep :). As to XSS, the assertion that's transmitted to a site is scoped to that specific site, and is only valid for, iirc, 2 minutes. So replay attacks are severely constrained. Plus, the only meaningful data they contain is the user's email address, so phishing doesn't get you much…

So that's a 'yes' this exposes authentication to XSS, albeit the attacker will have to hijack sessions in real-time as the assertions are forwarded to their server.

That's a huge step backwards in web security. Why pass the assertion to the RP via the most insecure channel possible, i.e. the client-side javascript? That was just the easiest way you could find so the RP could tie it to client's session id?!

Obviously the assertion must be sent from the browser plugin directly to the RP. You could do it by injecting an HttpOnly cookie for the RP's domain with the encoded assertion. Javascript can never see it.

In the case of a secondary, the secondary already has an HttpOnly session id with the end user, since they're authenticated in the first place. The secondary would post the assertion back to the RP directly at a well known URL, and the RP returns a URL to the secondary with a nonce built in. The secondary redirects the end-user to that nonce URL so the RP can give them an HttpOnly authenticated session id. I think you can do this in a way such that neither the assertion nor the nonce will be visible to client javascript.

Saying, 'oh your account can only be logged into by attackers for 2 minutes if they can XSS the RP' is beyond disappointing, it's borderline negligent.

Re: Introducing Mozilla Persona, An Identity System for the Web

#116

Post by callahad » Thu, Jul 12, 2012, 5:18 PM UTC

jackalope wrote: post #99

jstalin wrote: post #93

Earlier quoted context omitted.

I just tried it and once I entered my email address, it then asked: "Next, choose a new password you'll use when you sign in with Persona." Not sure why you're confused.

From https://developer.mozilla.org/en/BrowserID/ "Website operators still get a verified email address for their users, and users only have to remember a single password. BrowserID is also intuitive, since email addresses are commonly understood to be associated with identities." Mozilla is really stressing the "email address/single password" concept. If they really mean "email address/separate dedicated Persona pass…

The language around the number of passwords you need is really hard to get right. If you have suggestions, please let me know.

In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add many other unsupported addresses, without needing more passwords. So it's an "at most one new password" system.

Re: Introducing Mozilla Persona, An Identity System for the Web

#117

Post by callahad » Thu, Jul 12, 2012, 5:45 PM UTC

Flimm wrote: post #91

Mozilla Persona (AKA BrowserID) is exciting stuff. However, it doesn't seem to have changed much since the last time it hit Hacker News [0]. There are websites that have chosen Persona as an authentication method. We now need to see the following two pieces implemented: - It needs to be implemented in the browser's GUI, like in this old screenshot [1]. People will be able to see the usability and security benefits of…

Much has changed, but we haven't written about it yet. We're working on it. This post to HN caught me by surprise. The new design went live, but we weren't planning on announcing things until early next month. Trying to stabilize and polish the new APIs, etc.

Native support should be coming in Firefox 17, albeit off-by-default. Native support will be enabled on phones running Boot2Gecko, which ship in Q1 next year.

Re: Introducing Mozilla Persona, An Identity System for the Web

#118

Post by uvtc » Thu, Jul 12, 2012, 6:17 PM UTC

callahad wrote: post #116

jackalope wrote: post #99

Earlier quoted context omitted.

From https://developer.mozilla.org/en/BrowserID/ "Website operators still get a verified email address for their users, and users only have to remember a single password. BrowserID is also intuitive, since email addresses are commonly understood to be associated with identities." Mozilla is really stressing the "email address/single password" concept. If they really mean "email address/separate dedicated Persona pass…

The language around the number of passwords you need is really hard to get right. If you have suggestions, please let me know. In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add man…

Simply always refer to the Persona password as "Persona password".

> In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider.

I don't know what this means. I won't give Persona my gmail/yahoo-mail email password.

Re: Introducing Mozilla Persona, An Identity System for the Web

#119

Post by 27182818284 » Thu, Jul 12, 2012, 6:45 PM UTC

Angostura wrote: post #110

dendory wrote: post #75

For most people, it goes like this: click on the Facebook login button, done. OR, click on personaID, have a new window open, enter email, enter password, go through setup, get back to site. This will be hard for most web users to adopt.

For other people it goes 'click the Facebook login button' - What? This POS uses Facebook? What access does it get to my Facebook account? Is it one of those weird things that posts all over my Facebook wall? [cancel]

Generally I've noticed people are fine with FB login as long as you add "Don't worry we won't spam your friends without your permission" or "We won't spam your feed, we just want to know it's you." or something like that

Re: Introducing Mozilla Persona, An Identity System for the Web

#120

Post by callahad » Thu, Jul 12, 2012, 7:07 PM UTC

uvtc wrote: post #118

callahad wrote: post #116

Earlier quoted context omitted.

The language around the number of passwords you need is really hard to get right. If you have suggestions, please let me know. In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. If your email address isn't supported, Persona asks you to create a single new password at login.persona.org. You can then add man…

Simply always refer to the Persona password as "Persona password". > In a world where every email provider supports Persona natively, Persona truly is a "no new passwords" authentication system, since it delegates to your provider. I don't know what this means. I won't give Persona my gmail/yahoo-mail email password.

Yeah, it's confusing. If your email provider is supported, your browser talks directly to your email provider, without Mozilla in the middle. We don't want your passwords, honest! :)

You can try out the supported email provider workflow by signing up for a dummy account at eyedee.me, and then using that account to sign in at, say, 123done.org.