Hacker News new | ask | show | jobs
by qikquestion 5008 days ago
Let me add my understanding. Please correct me if it is wrong.

Actual user case if everything is in place:

1. you are in a website using browserid protocol/persona (eg. http://crossword.thetimes.co.uk/)

2.hit the login link. Give your email address (superuser123@gmail.com or superuser123@yahoo.com)

3.it prompts for your password - gmail password or yahoo password

4.post authentication it takes you to the website with user session as superuser123@gmail.com/superuser123@yahoo.com - eg crossword.thetimes.co.uk

5.In a nutshell, end user doesn't need to create a new userid & password for using the website, as long as he knows his emailuserd/emailpassword

Present use case - since few things are missing

1. you are in a website using browserid protocol/persona (eg. http://crossword.thetimes.co.uk/)

2.hit the login link. since gmail & yahoo as email providers not implemented browserid/persona protocol, you will asked to create an account in persona.org with any of your existing email address.(gmail / yahoo).

persona.org will send you a verification link to check if you really own your email address. Click on the verification link and you are verified to use persona.org account in all the places where browserid is supported

3.in the login page - it prompts for a new password if you are a new user or existing password if you are a returning user - this is the password for the email address used in persona.org registration.

4.post authentication it takes you to the website with user session as superuser123@gmail.com/superuser123@yahoo.com - eg crossword.thetimes.co.uk

5.In a nutshell, two things will change in future - no login window from persona.org & no need to create account in persona.org

2 comments

That's completely spot on. Right now, if your email provider doesn't have native support, we ask you to create a persona.org account so that Mozilla can vouch for you. In the future, this goes away.

Similarly, the UI is all displayed in response to navigator.id.* functions. If a browser implements those natively, the Persona UI at login.persona.org completely goes away.

The more successful Persona is, the less Mozilla is involved in the login process. :)

So if i signup now with my @gmail account through persona.org, what happens when google starts supporting browserid natively?
Then you'll start seeing an authentication page hosted by Google, instead of the Persona fallback. Native options are always tried first, both for client-side navigator.id functions, and for server-side authentication. If one of those is missing, then login.persona.org fills in for that component.
The BrowserID protocol states that Google should be used for authentication, instead of the fallback persona.org account.
> 3.it prompts for your password - gmail password or yahoo password

Yes. In this case the "it" that prompts for your password will be an iframe served from gmail/yahoo. Once they support Persona natively, login.persona.org is no longer in the loop and your gmail/yahoo password goes directly to gmail/yahoo.

Having the (say) GMail in an iframe sounds worrying. It's not clear immediately that the embedded page came from GMail, as we cannot see the https scheme in the URL for the iframe - much less any indication that the certificate is trusted etc. This provides an attacker with the possibility to create a fake GMail login page

Why not redirect to GMail (openid-style) with a callback (or failing that, use a pop-up)?

You're talking about a phishing attack and it's actually worse for OpenID http://identity.mozilla.com/post/7669886219/how-browserid-di... Once Persona is integrated into browsers it will offer better security. BTW, the iframe is always in a pop-up for this exact reason. It's never an iframe within the context of the website that initiated the login.