The low level protocol - BrowserID - is a federated system, so the "they" in your question can be someone you trust (and Mozilla isn't hardcoded)
You can use any browser and if it has native support, it will do the client side crypto. It will store your public/private keys in the client.
You can use any Identity provider (email provider probably) and if they have native support, they will store you password and do 2 factor auth or whatever.
This removes websites (relaying parties) from the password storage business. All they get is an email address and a way to cryptographically check to see that you owned it.
The crypto that powers the BrowserID protocol is an open standard, so you can vet it. It's been designed by crypto experts in an open forum.
One more correction. The identity/e-mail provider does not store your password, it merely signs your key for which it can use whatever authentication it wishes. Most probably the same user-id/password combo you use to read your mail, but the BrowserID does not dictate that, it is up to the provider to decide.
After that the identity provider just gets requests from services that do not know its public key yet, but typically it is asked only once per service as the key is stored in a local cache. And even when the key is asked, the provider cannot know for which email verification address it is needed.
All in all I think this is a great system. It puts a lot of trust in the e-mail provider, but I think that's all right as the provider already has full control of your personal e-mail anyway and hence is trusted by default.
I don't trust any "organization" to store and manage my passwords. A single subpoena to mozilla for a divorce proceeding or whatever could unleash cascading consequences upon you.
It's not really a "password manager", it uses signed assertions instead of plaintext passwords. It is similar to client certificates, but with a much better UI.
Also, in the future you probably won't even need to contact Mozilla anywhere in the process: your browser will store your certificates for you, natively.
I can not get Persona to work. I go to Mozilla developer network: https://developer.mozilla.org/en-US/ , see the login button and click on it and it redirects me back to the same page. I am using Firefox 15
Yea - there was nowhere for me to sign up. I think the problem may be the pop-up did not work on Firefox. I used Chrome and was able to create an account and then everything worked. I also tested on IE8 and had some javascript error, but just hit refresh twice and was able to login.
After reading the text twice and watching both videos i still have no clue what it actually does and how it solves the problem. I'm a few pages of skimming into the documentation now but there's no overview of what it actually does in the background.
Just a load of buzzwords and awesomeness!1 of how this will revolutionize my account management and how easy the API is.
Is it a password manager, a biometric system or some kind of account provider?
It's quite clever, essentially it's a system where your email address is your unique identifier, and you authenticate by clicking on a link sent to your email account.
My understanding is that it is designed to be a distributed variation to oAuth where you authenticate against an email address instead of a specific social account.
It's decentralized public-key based authentication, wrapped up in an extremely user- and dev-friendly package. Francois Marier did a good job of explaining it at Kiwi PyCon 2012: https://www.youtube.com/watch?v=iZBTc7iEkQY
(Think OpenID, but easier to use, easier to implement, and with better privacy protection.)
In brief: instead of a username and password at login, you get a user's email address and cryptographically signed assertion proving their ownership of that address. The assertions are ephemeral and scoped to your site, so once you verify it, you can set a session cookie and throw away the assertion. No more password column in your database, yet you still retain a direct relationship with your users.
Who has liability when a user of mine says their account got hacked? The email provider? My site? Mozilla?
If one of my users has $100 go missing from their account, then they are going to expect me to replace it, not the email provider, not mozilla. I don't like the idea of shifting security to a outside platform, because I still retain all the liability when things go bad, and they always will (key loggers, spyware...)
Sites that deal with financial transactions will be reluctant to adopt this for sure.
For financial items you could use two factor authentication. Or if your service has something that can be done with a lower set of privileges you could use persona there and fall back to "more secure" methods for anything with financial effects or account changes.
The use case seems to be more for sites like twitter, hacker news, reddit, etc...
Sites that deal with financial transactions are almost always 5-10 years behind on the adoption curve; of course they will be reluctant to use Persona. And that's not unreasonable.
How can any website protect a user against key loggers, spyware or any other form of a compromised client machine? If the client machine is compromised, any login method is broken.
Not really. All 2 factor authentication schemes that I've seen give no protection against a compromised client machine.
In theory you could probably device a scheme that would require the use of two independent devices to perform any sensitive action and that would guarantee that if only one of the devices is compromised, the attacker would have no way to perform any action in a name of the user. But I'm afraid any such scheme would be a complete failure from a usability perspective.
When the second factor is a "rich" device, such as a smart phone, attaching transaction information to the interaction would be a trivial - instead of texting "The code is 1234", text "Transfer $100 to account 9876" or "Login attempt from IP 1.2.3.4, FooCom Inc, Springfield, Oregon, USA.", followed by "If correct, enter code 1234. If not, DO NOT enter the code and contact us at .. "
Congratulations on this and thank you.
The links are useful and I recommend the video-I got a proof of concept onto our staging servers whilst listening to the video - fantastic.
Can I suggest a clearer explanation in the quick start guide of loggedInEmail and it's options and that there is a comparison of the name supplied from the site and name inside the browser - it is a bit confusing to see onlogin get called without a button being pressed. I would suggest walking a dev through what to expect - the code examples are great but the quick start is written by someone who understands what's going on behind the scenes - there is a sentence About currentusr that completely floored me - I could not understand how I was supposed to know bob was logged in if that was the first time he arrived at the site. In the end I gave up and read the docs !
Basically, your browser knows your identity, so it can automatically authenticate you with any supporting website. You never have to set up an account with the website and you never have to enter a password.
Someone needs to make a Persona Persona. We're our own worst SEO enemy :)
The Firefox themes were renamed to... background themes. It's just that the addons team (which owns getpersonas.org) has been hard at work on the new Mozilla Marketplace, and the Persona team has been hard at work on Persona. A few of the Persona devs are going to hack on this next month and try to get a disambiguation page deployed. We don't want theme-seekers to get lost, but we also don't want to lose people looking for the authentication system, so a straight 301 isn't ideal.
This link posted says they are looking to rename Personas to something different, but it doesn't look like its actually happened yet (or what it will be called). Given that the getpersonas.com website is still calling them Personas, I'd say the Personas name is still alive and well (and easily confused with the new Persona product)
Speaking of themes, how easy is it to customize the look&feel of the login prompt? It may be odd for the user to see an entirely different site when they try to sign-in to a site.
I think the general idea of building better auth into browsers is a wonderful and highly necessary development. However, this implementation will completely fail if the user has JavaScript blocked and there is no fallback. And yes, this is a real issue. (Though I will probably get a lot of replies that try to dismiss it in various ways.)
That's a great point. Persona doesn't work well in non-JS, non-browser contexts, yet. The nice thing is that you can use it for progressive enhancement. Users have JS? Auth with Persona. Users don't have JS? Use a traditional email address / password system.
So long as you can associate email addresses with accounts on your backend, you can use Persona with the same database you have right now.
Persona doesn't work well in non-JS, non-browser contexts, yet.
So are there built-in, HTML-only versions for this in the works? It seems it should be possible to build some of this functionality into the browser, making it work without JS.
The nice thing is that you can use it for progressive enhancement. Users have JS? Auth with Persona. Users don't have JS? Use a traditional email address / password system.
I wouldn't call that progressive enhancement. Depending on whether the client has JS enabled, they would go through entirely different registration and auithentication processes, using different credentials. That can be very confusing to the users.
I’m not in love with Persona because it puts everyone’s eggs in one basket.
I like OpenID because it works like email — choose whichever provider you fancy. If one goes sour or a nicer one pops up, websites don’t have to add support it before you can use it. And, websites can choose to expose nice “sign in with X” buttons instead of making you type in your OpenID address to sign in.
On the other hand, I realize that Mozilla has made big advances in ease-of-use (for users and developers). I just hope those advances turn into an open protocol someday.
P.S. I had a fleeting hope that they were announcing browser extensions (with a fallback to the way it works now). There’s still a risk of sketchy websites phishing for your Persona login.
- - -
All right, clearly I need to read some more docs. I apologize for making unfounded complaints against what seems to be a pretty darn awesome protocol.
> I like OpenID because it works like email — choose whichever provider you fancy.
Persona works like email because every identifier is an email address, not an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with OpenID Provider X, Y, or Z" login page if users can actually use an identifier that that already know. :) (To be fair, OpenID Connect is working on fixing that problem)
> I just hope those advances turn into an open protocol someday.
Mozilla operates a few centralized services to solve the chicken-and-egg problem while bootstrapping, but they're completely optional, and they automatically fall away when a browser or email provider have native support for the BrowserID protocol.
> Persona works like email because every identifier is an email address, not an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with OpenID Provider X, Y, or Z" login page if users can actually use an identifier that that already know.
OpenID URLs need not be opaque - I use my regular <realname>.com URL as my OpenID, and have a stub in the HTML of /index.html that points to the provider that I want to use when I authenticate (which I can change any time I please). It's called delegation. I think using DNS as an identifier is better than email (as that's kind of what it was built for), but not a viable option for the masses. Mozilla did a good job with Persona.
I believe different providers other than Mozilla can host it, and you can use one of them instead of Mozilla. That works just like email hosting. Persona is an API-level protocol. Whoever implements it can host it. It just means the end users need to maintain a separate password entry with the other hosting provider.
I can see why they're calling it a beta release. The UX during creating a profile on developer.mozilla.org has several rough edges. For example:
1. Clicked "Sign In" and successfully create a Persona account.
2. Created a profile on MDN, with the wrong user name (oops).
3. Cancelled my Persona account in a separate tab.
I'm still logged in on MDN and the "Sign Out" button doesn't work now. After 5-10 minutes, I get a "Permission Denied" page, which is correct, but not exactly the expected workflow.
Also, LastPass doesn't seem to play well with Persona, but I'm hopeful it will in the future.
Have been messing around with BrowserID since it first went public last year (with a node.js backend) and I love it. Its so much more straightforward to implement than oauth and openid, and the fact that it's tied to your email address is perfect. I'm definitely going to be using it as my primary auth system going forward. Great job Mozilla!
Do you have examples of sites that don't use Persona as the BrowserID implementation? I'd like to see how sites are handling the user prompt when there are going to be alternative providers to Mozilla's Persona service.
No since what I do is pretty experimental side projects and fine to just use the persona end of things. Also I don't currently have anything public running right now myself (as it just entered beta so I won't release until v1.0).
If you haven't tried it out yet I encourage you to do so...it only took me 30 minutes to get up and running the first time around.
Doesn't work that way; Mozilla's Persona service just serves as a shim for browsers without native support for BrowserID. On browsers with native support, Mozilla's server won't get involved at all.
Are there any websites with implementations that don't prompt directly for Mozilla's site(i.e. asking for your preferred BrowserID provider)? I'd like to see how clunky the interface becomes when there are more providers(such as if I want to become my own provider) than just Mozilla. Is the user then confused by asking for a provider..ala OpenID? Am I correct in presuming Persona is an implementation of BrowserID?
I'm not likely to use this myself as this little gem from Mozilla's privacy policy (https://login.persona.org/privacy) gives me the shivers:
"As part of the normal operation of the Persona service, Mozilla will retain a log of which sites you have disclosed your email to."
Enter DASD@eyedee.com - This is a Primary Identity provider, source at [1]
So you see there is no BrowserID provider choosing screen, it's naturally part of the flow. you enter DASD@eyedee.com and the system checks for support and delegates to eyedee.com.
Thanks for posting the process flow. So (https://login.persona.org/sign_in) will always be shown? If so, then how is this truly decentralized with my privacy concerns mentioned above?
If you had a browser, say Opera, with native support for the BrowserID protocol, then you would not see login.persona.org. No requests would be made to a Mozilla server.
login.persona.org is two things:
1) A JavaScript shim for cross platform support (Opera + BrowserID support would avoid this)
2) A Fallback Identity provider (eyedee.me avoids this)
> Are there any websites with implementations that don't prompt directly for Mozilla's site
That's the OpenID model. BrowserID works somewhat differently. Your ID is an email address, so your provider is that email's domain. Because few domains support it directly yet, Mozilla operates an optional, centralized authority that can issue credentials to other users. But you don't have to use that if you add support on your own domain.
After that, the UI is also provided by Mozilla's cross-browser JS shim, but it's just a polyfill for `navigator.id.`. If your browser has native support for those methods (Firefox will, soon), then Mozilla's UI is completely uninvolved.
Basically, we're starting with a single, optional point of centralization: login.persona.org. As native support comes online from various domains and browsers, our central fallback will automatically drop out of the picture.
> Am I correct in presuming Persona is an implementation of BrowserID?*
Yep! BrowserID is the protocol, Persona is Mozilla's cross-browser UI and optional centralized services. It's kind of like how Google Login is really OpenID/OAuth under the hood, but more meta.
> "As part of the normal operation of the Persona service, Mozilla will retain a log of which sites you have disclosed your email to."
Yeah, that line sounds super bad. IIRC, it's a relic of a previous design of the cross-browser shim that needs to be removed. I'll follow up with Mozilla's legal folks.
Are there any browsers that currently implement BrowserID? I just fired up Firefox 15 and still get the pop-up for login.persona. Or links to near future impementations?
Thanks for you and otzen for shedding light on all of this.
I believe Firefox OS will have the first enabled-by-default, user-visible implementation around Q1 next year. Bits are starting to land in Firefox, but they're super, super experimental and not totally functional yet.
Yep! You can delegate to another Identity Provider (IdP) by adding a JSON file to your domain (we're looking into DNS-based ways of doing the same), but afaik, there aren't any publicly available IdPs that accept delegation yet. Ozten is working on one.
Also, we still haven't completely shored up the IdP-facing API (there are a few rough edges to fix before committing to it), so the specifics are still subject to change. https://mockmyid.com/ and https://eyedee.me/ are both open source, example IdPs that we're using for testing.
It works quite well, with a few gotchas (mainly in the JS, handling the watch() event). If you're using Python the pyBrowserID library helps with some low-level details although it's easy enough with requests/urllib.
Awesome work by Mozilla. I've added this to a small project of mine, and it was super simple and fast to do. I really excited to see this gain traction.
What is the self-hosted equivalent of this ? I have been struggling with this problem quite a bit.
I have a bunch of web apps which are quite a bit different - off the shelf forum software, wordpress, custom code, etc. - and I want to tie them all together using a single signon. What should I be using ? I distrust myself enough to know that I would prefer not rolling my own security protocol.
I know that there are solutions like Kerberos, etc. but is it really practical for a bunch of websites running on Rackspace + EC2 ?
Note: You don't have to implement this yourself! You can POST assertions to https://verifier.login.persona.org/verify instead, and we'll return a JSON blob that lets you know if it was valid or not. Or you could run that same verifier locally (it's a stateless node.js server, code's on github in the mozilla/browserid repo). The exact data formats are still in flux (waiting / hoping for IETF standardization around some crypto things), so we don't recommend doing verification yourself just yet, unless you run our node.js verifier and frequently update it. We'll get that stuff locked down in one of the next Beta releases.
I just tried it on the Times Crossword page. The workflow is really simple and elegant. I put in my email address. It took a second to determine there was no Persona account, then asked for me to create a password. After that, I clicked on an authorization link in my email account and as soon as I did that it immediately logged me in. I clicked Log out and back in again and it immediately recognized me and logged me in.
This is really what I was hoping to see with OpenID when it came out, but the process to set up an account and get started is much more cumbersome.
I look forward to seeing native support for Persona in browsers.
It does seem a pretty elegant way to log in, the only concern i have is that it's kind of unclear what password i needed to use to login. I had already created a browserID password at some point in the past, so when i went to the times crossword and clicked sign in, i was prompted for a password. my first thought was maybe i had already signed up for the times crossword, so i tried the password i probably would have used to sign up for a site like that. nope, but it said "authenticating with your email provider". So then i tried my email password, thinking maybe it was integrating with my google account. nope. Third try was the password i had used to sign up for persona.
Maybe in the future, if this sees wide adoption, they can get away with just putting some mozilla branding in the corner, but for now there should really be some explanatory text on the login window telling you that you need to enter the password you created for mozilla persona, or this is just going to confuse users.
They've already stated that you'll be able to put your site logo and name into the login box [1].
As far as the password, I thought it was pretty clear that the password they are asking for is your Persona password, but maybe that's because I had just signed up.
The point is that you'll only ever need one password, so it'll be great to be able to have one strong password rather than tens of weaker ones.
>The point is that you'll only ever need one password
this will never be true. You'll only ever need one password for mozilla persona. The user expectation will still be one password per site, and allowing sites to brand the box will only make things even more confusing. It needs a stronger mozilla branding, not a stronger client branding.
The user will see the same Gmail Auth log in screen they have seen many times before. They only have to remember their gmail password (and any password manager works like it always has on this form).
Most likely if your provider is webmail, then you'll already have an active session... so you won't have to type a password in.
Every new site will, every site under active development will. The ones where two input boxes have been the same off grey colour for three years won't change much agreed. It's just a question of whether the sites that ask for username/password now are numerically the majority of login sites in three years or not?
Perhaps making signing in to websites really simple, in a way that verifies the users email address to the site, isn't a good idea. Once it's widely adopted spammers will start using it.
My major concern with this, beside the eggs-in-one-basket issue, is that this places even more value on my email account.
Years ago, my email account was simply used for exchanging short pieces of text with acquaintances and companies. Now it's the central key to all my authentication sessions and finances, and therefore presents a huge target for attackers.
I've been looking for ways to reduce the risk associated with losing access to my email account, should that ever happen. Yet for all its benefits, Persona still places yet more importance on protecting my single email password.
You could say the same about any traditional username/password signup that sends a confirmation email and allows you to reply to an email to reset your password. Ultimately, that's just relying on the security of your email, too. So while you are correct that Persona doesn't solve that problem, it doesn't make that problem any worse compared to the default option of an email-confirmed username and password.
I think that's what the parent post was getting at. Originally email was just used for exchanging messages, now that most sites use it to authenticate a user there is a much higher cost to losing access/having it hacked.
Yes, most authenticated web services offer a "forgot password" option, and their security is thus tied to your email account. However, each one of these decentralized services on its own is not as valuable as the entire ecosystem of Persona-enabled sites will be.
That is, the Persona "forgot password" is a single point of failure which, if compromised, can provide access to a whole ecosystem of sites. And it will be tied to your email account.
I'm still not seeing a distinction. Your email account is already a single point of failure for every account registered with that email that has a "forgot password" feature.
Maybe it would help if we considered two hypothetical scenarios. A: Your email is compromised, and you're registered on 15 websites with that email, each of which has a "forgot password" option. B: Your email is compromised, and you've used Persona to sign into 15 websites. In what concrete, practical way is B a more damaging situation than A?
Great point! And the recovery process is much easier in the Persona case... because you only have to fight to get back your Persona account. Today you'll have to
1) Fight to get your email account back
2) Visit each and every site and manually recover your account
Considering that it's a new protocol, why not try to solve that old problem? At the very least, they could allow you to disable email-based password reset in favor of printed code. That would be a smart thing to do.
You would get a random code or several codes you print out and put into a safe place. If you ever forgot your password, you would dig it our and supply to the website to trigger a reset (which could include or not include email-based verification). The codes would only be usable for passwords resets.
Persona, the protocol, doesn't actually rely on your email account's password. It uses the domain from your email account to figure out how to authenticate you; if you want to use some other way than via your email, that's fine.
If you log out, that's the password you'll use to log in again. The login session is good for a while so you can continue to login with already-authenticated identities (and you can have as many as you want) on persona-enabled sites.
Thanks for clarifying. I was assuming that was the case but the login/creation page needs to have a graphic or a narrative talking about what it does and how the process works a bit more before it reaches a more public audience. As a software developer I had an idea of how the thing worked but it wasn't spelled out enough. I understand that it's beta but the whole thing is weakly documented from a user's standpoint as to why it should be trusted.
That’s just how their fallback provider works. BrowserID — the protocol — does not rely on email in any way. There’s no guarantee that if you have valid assertion for joe@dns.tld there’s also an email account by that name.
I think the ship has mostly sailed on email -- most sites use email password recovery, so that choice isn't up to you unless you get a different email address for each site.
You should definitely use 2-factor authentication for your email!
You're right. Gmail does an excellent job with ensuring account integrity. I've lost and subsequently recovered access to Gmail accounts, and I must say they do it right. And like you said, I especially appreciate their two-factor auth.
I hope lay people are coming to realize the security importance of their email accounts.
People simply need to be very very careful about protecting their email account. Use two factor authentication, use a PIN on your smartphone, don't type your email address password on random internet cafe computers, etc.
No. Websites should stop outsourcing their security to third parties they know nothing about (such as email providers). It's not just a matter of immediate security, but overall architecture quality as well. Having your entire digital life depend on an account that, for most people, is hosted by a third party, for free and without any guarantees is dumb. Email simply wasn't mean for that kind of use.
This is just great. I do hope this replaces Facebook connect as authentication provider, though I doubt it since getting all that user info is priceless for most sites using Facebook connect.
I don't think it'll replace Facebook, it'll just be an alternative to it. We've integrated both Persona and Facebook into our site and it works great.
For my business, we need more personal details about each person that we get by default with Facebook (name/age/sex). So, that integration will always be cleaner than Persona because it is just a few clicks.
We've been working with BID/Persona for a while now (we're linked from the /about page) and we're huge fans. If you want to play around with it... https://www.voo.st/
I've seen some preliminary discussions of linking personal information to a Persona and optionally supplying it to the site at login time. If you have a need for that, you should chat with the Persona/BrowserID developers.
It wouldn't be ideal because there would only be a limited number of people who ever took advantage of it. The model for Persona is different than Facebook. Facebook requires this data on account creation and so do we... so we just present the user with a lock out until they give it to us.
Persona could potentially note at login time that you require that information to create an account, and thus require supplying it before attempting to log in.
That said, looking at what your site does, why do you need that information? I can understand why you want it, but what functionality of your site won't function without it?
Yes, we require it. Having the persons name is obvious. For the rest, the site is very specific in its purpose, which is to allow people to register for USA cycling events.
There are some crazy rules around who can enter which race (based on age/sex) and we do our best to help guide people into the right event during registration.
Location is a nice to have so that when we show the list of participants, they can see where each person lives. Future versions of the site will use this information to help people connect with ride sharing to events.
Keeping the UX of asking for this information within our site makes sense when logging in with Persona since it doesn't have the social networking aspects that Facebook has. Most people who are entering bike races won't lie about their age/sex on Facebook (because bike racing is a relatively small community), so generally this information is pretty accurate. Once someone gives us their USA Cycling license number we also validate against the database we have of that information too.
Seems pretty interesting, though I have to say that watching only the introduction video gives you basically NO IDEA of what the product solves or how.
When you click the "Sign in with Persona" button on a website, the dialog that pops up has a "This is not me" button which logs out the current user and allows you to login with a different email.
Have the fixed the fact that it doesn't support autofilling passwords? That alone makes it more annoying than any captcha that I've ever had to fill out.
206 comments
[ 3.3 ms ] story [ 195 ms ] threadYou can use any browser and if it has native support, it will do the client side crypto. It will store your public/private keys in the client.
You can use any Identity provider (email provider probably) and if they have native support, they will store you password and do 2 factor auth or whatever.
This removes websites (relaying parties) from the password storage business. All they get is an email address and a way to cryptographically check to see that you owned it.
The crypto that powers the BrowserID protocol is an open standard, so you can vet it. It's been designed by crypto experts in an open forum.
After that the identity provider just gets requests from services that do not know its public key yet, but typically it is asked only once per service as the key is stored in a local cache. And even when the key is asked, the provider cannot know for which email verification address it is needed.
All in all I think this is a great system. It puts a lot of trust in the e-mail provider, but I think that's all right as the provider already has full control of your personal e-mail anyway and hence is trusted by default.
Your identity provider just has to implement the BrowserID protocol https://developer.mozilla.org/en-US/docs/Persona/Identity_Pr...
Persona doesn't attempt to solve this existing problem.
Plus, your keys are stored in the browser, according to callahad, so Mozilla doesn't have to know where you signed up: http://news.ycombinator.com/item?id=4232774
Also, in the future you probably won't even need to contact Mozilla anywhere in the process: your browser will store your certificates for you, natively.
Does it work for you on http://crossword.thetimes.co.uk/ ?
If not, we'd love to help identify your issue https://github.com/mozilla/browserid/issues/new
Just a load of buzzwords and awesomeness!1 of how this will revolutionize my account management and how easy the API is.
Is it a password manager, a biometric system or some kind of account provider?
The developer reference has much more information: https://developer.mozilla.org/en-US/docs/persona
(Think OpenID, but easier to use, easier to implement, and with better privacy protection.)
In brief: instead of a username and password at login, you get a user's email address and cryptographically signed assertion proving their ownership of that address. The assertions are ephemeral and scoped to your site, so once you verify it, you can set a session cookie and throw away the assertion. No more password column in your database, yet you still retain a direct relationship with your users.
Here's the underlying spec (working on getting it updated for Beta 1, but the principles are all there) https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
Who has liability when a user of mine says their account got hacked? The email provider? My site? Mozilla?
If one of my users has $100 go missing from their account, then they are going to expect me to replace it, not the email provider, not mozilla. I don't like the idea of shifting security to a outside platform, because I still retain all the liability when things go bad, and they always will (key loggers, spyware...)
Sites that deal with financial transactions will be reluctant to adopt this for sure.
The use case seems to be more for sites like twitter, hacker news, reddit, etc...
In theory you could probably device a scheme that would require the use of two independent devices to perform any sensitive action and that would guarantee that if only one of the devices is compromised, the attacker would have no way to perform any action in a name of the user. But I'm afraid any such scheme would be a complete failure from a usability perspective.
Can I suggest a clearer explanation in the quick start guide of loggedInEmail and it's options and that there is a comparison of the name supplied from the site and name inside the browser - it is a bit confusing to see onlogin get called without a button being pressed. I would suggest walking a dev through what to expect - the code examples are great but the quick start is written by someone who understands what's going on behind the scenes - there is a sentence About currentusr that completely floored me - I could not understand how I was supposed to know bob was logged in if that was the first time he arrived at the site. In the end I gave up and read the docs !
Edit - needed bigger text box on ipad
Basically, your browser knows your identity, so it can automatically authenticate you with any supporting website. You never have to set up an account with the website and you never have to enter a password.
That's my understanding of it anyway.
Maybe not redirecting based on user location by default is a good idea.
[1] http://www.getpersonas.com/en-US/
Evidently I need to pay more attention.
The Firefox themes were renamed to... background themes. It's just that the addons team (which owns getpersonas.org) has been hard at work on the new Mozilla Marketplace, and the Persona team has been hard at work on Persona. A few of the Persona devs are going to hack on this next month and try to get a disambiguation page deployed. We don't want theme-seekers to get lost, but we also don't want to lose people looking for the authentication system, so a straight 301 isn't ideal.
So long as you can associate email addresses with accounts on your backend, you can use Persona with the same database you have right now.
We're working on an iOS SDK, to make this polished and easy.
Patches welcome, get involved!
* mozilla.dev.identity mailing list * #identity on irc.mozilla.org
So are there built-in, HTML-only versions for this in the works? It seems it should be possible to build some of this functionality into the browser, making it work without JS.
The nice thing is that you can use it for progressive enhancement. Users have JS? Auth with Persona. Users don't have JS? Use a traditional email address / password system.
I wouldn't call that progressive enhancement. Depending on whether the client has JS enabled, they would go through entirely different registration and auithentication processes, using different credentials. That can be very confusing to the users.
I like OpenID because it works like email — choose whichever provider you fancy. If one goes sour or a nicer one pops up, websites don’t have to add support it before you can use it. And, websites can choose to expose nice “sign in with X” buttons instead of making you type in your OpenID address to sign in.
On the other hand, I realize that Mozilla has made big advances in ease-of-use (for users and developers). I just hope those advances turn into an open protocol someday.
P.S. I had a fleeting hope that they were announcing browser extensions (with a fallback to the way it works now). There’s still a risk of sketchy websites phishing for your Persona login.
- - -
All right, clearly I need to read some more docs. I apologize for making unfounded complaints against what seems to be a pretty darn awesome protocol.
Persona works like email because every identifier is an email address, not an opaque OpenID URL. You don't have to have the NASCAR-esque "Sign in with OpenID Provider X, Y, or Z" login page if users can actually use an identifier that that already know. :) (To be fair, OpenID Connect is working on fixing that problem)
> I just hope those advances turn into an open protocol someday.
You're in luck! :) The protocol is open and completely decentralized: https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
Mozilla operates a few centralized services to solve the chicken-and-egg problem while bootstrapping, but they're completely optional, and they automatically fall away when a browser or email provider have native support for the BrowserID protocol.
OpenID URLs need not be opaque - I use my regular <realname>.com URL as my OpenID, and have a stub in the HTML of /index.html that points to the provider that I want to use when I authenticate (which I can change any time I please). It's called delegation. I think using DNS as an identifier is better than email (as that's kind of what it was built for), but not a viable option for the masses. Mozilla did a good job with Persona.
It's decentralized. It's an open protocol based on an older open protocol.
Also, LastPass doesn't seem to play well with Persona, but I'm hopeful it will in the future.
If you haven't tried it out yet I encourage you to do so...it only took me 30 minutes to get up and running the first time around.
I'm not likely to use this myself as this little gem from Mozilla's privacy policy (https://login.persona.org/privacy) gives me the shivers: "As part of the normal operation of the Persona service, Mozilla will retain a log of which sites you have disclosed your email to."
Go to http://crossword.thetimes.co.uk/ - this is a non-Mozilla RP
Enter DASD@eyedee.com - This is a Primary Identity provider, source at [1]
So you see there is no BrowserID provider choosing screen, it's naturally part of the flow. you enter DASD@eyedee.com and the system checks for support and delegates to eyedee.com.
[1] https://github.com/mozilla/eyedee.me
login.persona.org is two things:
1) A JavaScript shim for cross platform support (Opera + BrowserID support would avoid this)
2) A Fallback Identity provider (eyedee.me avoids this)
That's the OpenID model. BrowserID works somewhat differently. Your ID is an email address, so your provider is that email's domain. Because few domains support it directly yet, Mozilla operates an optional, centralized authority that can issue credentials to other users. But you don't have to use that if you add support on your own domain.
After that, the UI is also provided by Mozilla's cross-browser JS shim, but it's just a polyfill for `navigator.id.`. If your browser has native support for those methods (Firefox will, soon), then Mozilla's UI is completely uninvolved.
Basically, we're starting with a single, optional point of centralization: login.persona.org. As native support comes online from various domains and browsers, our central fallback will automatically drop out of the picture.
> Am I correct in presuming Persona is an implementation of BrowserID?*
Yep! BrowserID is the protocol, Persona is Mozilla's cross-browser UI and optional centralized services. It's kind of like how Google Login is really OpenID/OAuth under the hood, but more meta.
> "As part of the normal operation of the Persona service, Mozilla will retain a log of which sites you have disclosed your email to."
Yeah, that line sounds super bad. IIRC, it's a relic of a previous design of the cross-browser shim that needs to be removed. I'll follow up with Mozilla's legal folks.
Thanks for you and otzen for shedding light on all of this.
Also, we still haven't completely shored up the IdP-facing API (there are a few rough edges to fix before committing to it), so the specifics are still subject to change. https://mockmyid.com/ and https://eyedee.me/ are both open source, example IdPs that we're using for testing.
https://developer.mozilla.org/en-US/docs/DOM/navigator.id
I believe this merges the old BrowserID Session Management parts with Persona, or am I wrong?
It works quite well, with a few gotchas (mainly in the JS, handling the watch() event). If you're using Python the pyBrowserID library helps with some low-level details although it's easy enough with requests/urllib.
I have a bunch of web apps which are quite a bit different - off the shelf forum software, wordpress, custom code, etc. - and I want to tie them all together using a single signon. What should I be using ? I distrust myself enough to know that I would prefer not rolling my own security protocol.
I know that there are solutions like Kerberos, etc. but is it really practical for a bunch of websites running on Rackspace + EC2 ?
If you use Persona on all your sites, it feels very much like SSO.
I use the browserid plugin (http://wordpress.org/extend/plugins/browserid/) on my personal Wordpress site.
We actually had an SSO project based on CAS v2, which we killed because Persona was a better solution.
Since you built an SSO, could you point me in the right direction amongst self-hosted solutions. Some comparisons and pitfalls would be most welcome.
https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
* What the hell does the JS assertion object look like?
* How do I run an independent service?
* In a single page, walk me through the steps to integrate?
Videos, dodgy music, overenthusiastic PFYs appeal to me much less than good documentation
Needs to be updated a little bit, but check out the spec: https://github.com/mozilla/id-specs/blob/prod/browserid/inde...
Note: You don't have to implement this yourself! You can POST assertions to https://verifier.login.persona.org/verify instead, and we'll return a JSON blob that lets you know if it was valid or not. Or you could run that same verifier locally (it's a stateless node.js server, code's on github in the mozilla/browserid repo). The exact data formats are still in flux (waiting / hoping for IETF standardization around some crypto things), so we don't recommend doing verification yourself just yet, unless you run our node.js verifier and frequently update it. We'll get that stuff locked down in one of the next Beta releases.
> How do I run an independent service?
https://developer.mozilla.org/en-US/docs/Persona/Implementin...
> In a single page, walk me through the steps to integrate?
https://developer.mozilla.org/en-US/docs/Persona/Quick_Setup
This is really what I was hoping to see with OpenID when it came out, but the process to set up an account and get started is much more cumbersome.
I look forward to seeing native support for Persona in browsers.
Maybe in the future, if this sees wide adoption, they can get away with just putting some mozilla branding in the corner, but for now there should really be some explanatory text on the login window telling you that you need to enter the password you created for mozilla persona, or this is just going to confuse users.
As far as the password, I thought it was pretty clear that the password they are asking for is your Persona password, but maybe that's because I had just signed up.
The point is that you'll only ever need one password, so it'll be great to be able to have one strong password rather than tens of weaker ones.
[1] http://identity.mozilla.com/post/32395255498/announcing-the-...
this will never be true. You'll only ever need one password for mozilla persona. The user expectation will still be one password per site, and allowing sites to brand the box will only make things even more confusing. It needs a stronger mozilla branding, not a stronger client branding.
Primary IdPs host the log in page, not Mozilla...
Say Google implements BrowserID for Gmail.
The user will see the same Gmail Auth log in screen they have seen many times before. They only have to remember their gmail password (and any password manager works like it always has on this form).
Most likely if your provider is webmail, then you'll already have an active session... so you won't have to type a password in.
I give stackoverflow three days.
I've pasted your comments into a bug report: https://github.com/mozilla/browserid/issues/2539
Feel free to jump in if you have ideas on how we can phrase this better.
Years ago, my email account was simply used for exchanging short pieces of text with acquaintances and companies. Now it's the central key to all my authentication sessions and finances, and therefore presents a huge target for attackers.
I've been looking for ways to reduce the risk associated with losing access to my email account, should that ever happen. Yet for all its benefits, Persona still places yet more importance on protecting my single email password.
That is, the Persona "forgot password" is a single point of failure which, if compromised, can provide access to a whole ecosystem of sites. And it will be tied to your email account.
Maybe it would help if we considered two hypothetical scenarios. A: Your email is compromised, and you're registered on 15 websites with that email, each of which has a "forgot password" option. B: Your email is compromised, and you've used Persona to sign into 15 websites. In what concrete, practical way is B a more damaging situation than A?
1) Fight to get your email account back
2) Visit each and every site and manually recover your account
You would get a random code or several codes you print out and put into a safe place. If you ever forgot your password, you would dig it our and supply to the website to trigger a reset (which could include or not include email-based verification). The codes would only be usable for passwords resets.
This is my concern; a compromised email account means a compromise of your account on every Persona-enabled site.
That’s just how their fallback provider works. BrowserID — the protocol — does not rely on email in any way. There’s no guarantee that if you have valid assertion for joe@dns.tld there’s also an email account by that name.
You should definitely use 2-factor authentication for your email!
You're right. Gmail does an excellent job with ensuring account integrity. I've lost and subsequently recovered access to Gmail accounts, and I must say they do it right. And like you said, I especially appreciate their two-factor auth.
I hope lay people are coming to realize the security importance of their email accounts.
It looks very lovely.
For my business, we need more personal details about each person that we get by default with Facebook (name/age/sex). So, that integration will always be cleaner than Persona because it is just a few clicks.
We've been working with BID/Persona for a while now (we're linked from the /about page) and we're huge fans. If you want to play around with it... https://www.voo.st/
That said, looking at what your site does, why do you need that information? I can understand why you want it, but what functionality of your site won't function without it?
There are some crazy rules around who can enter which race (based on age/sex) and we do our best to help guide people into the right event during registration.
Location is a nice to have so that when we show the list of participants, they can see where each person lives. Future versions of the site will use this information to help people connect with ride sharing to events.
Keeping the UX of asking for this information within our site makes sense when logging in with Persona since it doesn't have the social networking aspects that Facebook has. Most people who are entering bike races won't lie about their age/sex on Facebook (because bike racing is a relatively small community), so generally this information is pretty accurate. Once someone gives us their USA Cycling license number we also validate against the database we have of that information too.