Hacker News new | comments | show | ask | jobs | submit login
Why we love Mozilla Persona (zonino.co.uk)
319 points by 500and4 1206 days ago | hide | past | web | 160 comments | favorite



In principle, Persona is great. Not storing passwords is awesome, a non-FB/Google/Twitter identity option is important.

I would encourage you, though, to look carefully at your login completion metrics. I implemented Persona on my site (http://www.sixquestions.co) to have a pure email option and although users clearly prefer it, about 35% complete the Persona login flow successfully. That's 10 points lower than our next-worst performer (Twitter), and half the rate of our best performer (Facebook). For all the concerns people have with authorizing Facebook/Twitter access, that is (in my view) offset by the alien-ness of Persona's login flow. We've heard from lots of users that logging in with Persona is unusual and they thought they were doing something wrong because they'd never seen anything like that.

So, as much as I believe in Persona, I'm about to deploy a change that removes it entirely. It adds a lot of surface area to our testing and future development, but if it means we lose fewer users in their signup flow, it will be worth it.


Here's an example: I just failed to login to Zonino myself.

I enter in the Gmail address that I use for registrations and other junk. I get the message: "Accounts don't match. You are currently signed into Google as [my normal Gmail address]. ... Force Google logout?" Forget that. I'm not interested in logging out of Gmail. Logging out of #1, into #2, out of #2 and back into #1 is more work that simple registration. I expect that I'm not the only person with this problem. I hope a solution can be found, because it would be really helpful.


Gah. We still need to switch from OpenID to OAuth for our GMail bridge; OpenID doesn't allow us to tell Google what address we're trying to authenticate. Sorry!


Need any help with that/is there a ticket?



Normally, when you're logged into multiple Google accounts - Google Bridge in Persona lets you pick which Google account you want to use. This error you're seeing seems like some sort of bug/UX issue (?) in Persona -> Google flow where if you're already signed into multiple Google accounts, but not the extra one you're trying to use - things don't work as smoothly..


Interesting. Persona likely needs work when it comes to multiple Gmail accounts when using the Account Bridging.


They're working on it: https://github.com/mozilla/persona-yahoo-bridge/issues/178 You should post your findings there


That's for Yahoo, not Gmail.


Do you get this problem if you use a different browser for the other gmail account?


No, and that is what I would usually do since I understand how these things work. (IE does come in handy at times.) The point that I am trying to make is that normal users who don't know these tricks can run into this barrier.


I don't think normal users have multiple Google accounts, though.


Eh, that depends.

All it takes is a personal Gmail account plus working for a company that uses Google Apps.


Agreed. Although Persona's technical basis and privacy protections are second to none, the UX is nothing to write home about. It still feels too much like OpenID, and we know what happened to OpenID. Facebook and Twitter can get away with cross-site redirects because they're well known and people trust them. Persona doesn't have that benefit, so it can't get away with the same cumbersome UX. It needs to do better, much better. The market is unfair. Deal with it.

If you're in the business of implementing an alternative login system, you should also seriously think about what kind of UX you're competing against. Your ultimate competitor isn't Facebook or Twitter. It's the good old email-and-password login system that everyone is used to. You enter your email address, select a password, and you're in, without ever leaving the signup page! It's even easier if you use a password manager like LastPass. That's what you're competing against, and if your UX has any more steps or redirects than that, you're probably doomed.


The paradox here is that people are more familiar with the appearance of home-grown-style login systems and are more willing to follow through on those than the novel Persona flow, even though the security characteristics of Persona are stronger. It's a chicken and egg problem, and until someone really big takes the plunge and gets everyone comfortable with this style, anyone implementing it is going to be somewhat of a cost to signups.


I think you've hit the nail on the proverbial head here.


If the bridge supports the 3-4 major email providers, it effectively becomes "log in with your email address" (it already supports Gmail), and A LOT of the friction goes away.


OpenID never really made it not just because of their bad UX design but also because they never got major players to push it to the public. Google or Facebook would much rather have you use their service as login credentials as it makes more monetary sense to do so than to hand it over to some non-profit foundation like Mozilla or OpenID. Data = money in this world and everyone wants more money.


Google, Yahoo and AOL all support(ed) OpenId login using their site as an IDP.

Google's FriendConnect was built on it.

That's a fair bit of "push".


There's 2 issues with persona.

1) users don't already have a personna account setup. They're used to hit their "login with FB/Google" account instead. They don't know that persona is better privacy-wise. So for many, it's just friction.

2) persona login sometimes appears slightly slower


There's an OpenID bridge [1] to make it easier for GMail users to sign in using Persona if they're currently logged into GMail/Yahoo! [2]. I haven't used it but the end goal of Persona is that 3rd party email providers can be their own Persona identity providers.

We definitely need something like Persona but I share your concerns WRT friction. Chicken meets egg.

[1] http://identity.mozilla.com/post/56526022621/what-is-an-iden...

[2] http://identity.mozilla.com/post/57712756801/persona-makes-s...


Your data (especially the fact that users clearly prefer it) tells me that they're clicking it out of curiosity, to see how they can log in with their email.

Unless by "clearly prefer it" you don't mean the initial button click, but the final login?


You can see how we communicate it on our site if you're curious. Basically it's a modal dialog with four options:

* Facebook * Google * Twitter * Email

We don't use the persona messaging, and I think people's expectation when they click the 'email' button is that it's going to just be a normal email flow. We don't call it Persona or Browser ID or use any of their assets or messaging, because we didn't think anyone would click on it if we did.

But yes, we see a small preference for a button labeled 'email' versus facebook, and a medium preference for either over twitter.


I did try it (and signed in) to your site. I'll admit, I knew I was going there for Persona, and "sign in via email" got me curious to click on it, even though I already knew what it was.


Why not keep it as a (perhaps less prominent) alternative?


Just tried it on your site. It went easily enough. I entered my Gmail address in the Persona form, then it had me pick which Google account to use (strange that it wouldn't just choose the one for the Gmail address I entered), then it said I was signed in.


The gmail case is special, actually. For a few domains (gmail, yahoo, not sure which others) it will fall back to a flow that's more like OAuth. But for unknown domains it sends you an email with a link, and then requires you to create a new account (with a new password) that is persona-specific.


I agree. Though facebook tends to track users, people are so used to see the facebook login button that they feel comfortable with it. Persona, though really good, feels different and makes the me a bit uncomfortable as an end user.


How do you know users clearly prefer it?


We track clicks on each of the four login methods, and compare it with successful sign in events with each of them. So we know completion rates for each type, plus which types are preferred by users. Nothing fancy, just google analytics events + checking the users table.


Persona is an elegant, powerful idea that is 100% in the users interest. I dearly want to see it gain traction. Kudos for disseminating your enthusiasm.


Here's a crazy simple way to implement Persona authentication for your Apache-deployed apps/sites:

https://github.com/mozilla/mod_authnz_persona

(I know Apache may not be that popular with the HN crowd anymore, but I don't currently have the time to dive into nginx and do the same for it. Nevertheless, if anyone wants to do that, I'd be happy to answer questions and provide pointers into the Apache code.)


Oh wow, that's fantastic! I would love an nginx module that did this, although wishes don't go far.


You may try https://github.com/wrr/wwwhisper, although unlike the apache module, wwwhisper runs as a separate service (Django) that nginx communicates with using auth_request module.


Looks nice, thank you!


> I know Apache may not be that popular with the HN crowd anymore

I still love it. Thanks for the module.


I completely agree. I was just thinking about this earlier today, there was lots of hype last year about it but it seems to have died down, and the project seems to have stalled.

I really want to see it pick up steam and succeed, and I think the number one priority now is to implement plugins for major browsers. I hope the team picks up development again.


The team has been focused on Persona support in Firefox OS, the Firefox Accounts stuff which relies on some of the same code as Persona, and integration on Firefox desktop. They have by no means stopped working on Persona, but resources on the Identity team seem kind of limited relative to how much there is still to be done.


Hmm, right. It seems that interest has died down a bit, so maybe it'd be worth spending some man-hours keeping it alive, even if it takes away from development time. The community could maybe help with development? If not with Firefox OS/Accounts, at least with the web component.


I have, but not much of the community seems interested in helping out.

To be fair, it's also pretty hard to help out while the team is focused on doing other stuff.


I'd be glad to help any way I can, my email is in my profile. Persona is amazing and needs to survive and thrive in my opinion...


Hmm, right :/ What are some things you guys need help with? Maybe we could pitch in.


Not elegant at all, but the best option we have supported by some powerful force (Mozilla) that can push it onto users by embedding it into their browser.

Personally, I view Persona as just an awkward kludge that, while improves some important things, also does certain harm by pushing us one step away from making third parties mere notaries of one's identity, not its very providers.

Because it's me who's the source of my identity, nor my email provider nor domain registrar.


I've been using Persona as my sole login mechanism on http://letscodejavascript.com for over a year. I want to love it, but I don't.

The goals behind Persona are excellent: strong privacy protection and relieving website operators of cumbersome and error-prone authentication management. I love the idea. It's why I implemented Persona on my site.

The execution of Persona has been a bit wobbly. Logins are critical infrastructure and it doesn't feel like Mozilla is approaching Persona from that perspective. The team has been fantastic (thanks, callahad) but when things go wrong, it can take a long time for them to get resolved. Meanwhile, I'm left scrambling for a workaround.

An example: when the Yahoo bridge was implemented, it broke Persona for everyone who used a Yahoo alias [1]. A nasty break that returned a non-helpful error message. Something that serious merits an immediate rollback, in my opinion--but instead, it was left in place for several weeks until a interim solution was rolled out. The interim solution has some fairly serious UX problems, but the full solution has been open for 10 months now [2].

I want to love Persona, and I can't really afford the time required to do my own authentication, but it scares me that I'm so dependent on it.

[1] https://github.com/mozilla/persona-yahoo-bridge/issues/178

[2] https://github.com/mozilla/persona-yahoo-bridge/issues/201


I guess Mozilla limited resources would be used on other projects until it gets the right traction.

I believe it deserves it, but more collaborators should chip in, or more websites should use it in order to make it elegible for more resources.


  > ...I can't really afford the time required to do my own 
  > authentication...
Just curious: What does your perfect solution look like?


Perfect solution? It works like it was custom-built for my site, is as easy and predictable to implement as Persona's `get()` API, and of course has excellent security, privacy, and operations.

I would have been willing to pay for such a thing had it existed when I started. It would have needed to be proven, though, because I worry about longevity. The exact price isn't so important, within reason; say, less than $100/mo. At the higher end of that range, I'd expect it to have some serious word-of-mouth gushing.


Persona vouches for you when you sign in. Really neat, no more password leaking.

The important thing here is that as Persona protocol (BrowserID)'s creator, Mozilla really really wants someone else (potentially YOU the user) to run the Identity Bridge. Currently Mozilla does this for non-Gmail and non-Yahoo users too boost adoption. So when you sign up you are asked to give a new password on sign up. If you are paranoid, you should of course give a new password instead the one you use for your email (which I assume may be reused for multiple accounts...)

But being able to authenticate yourself on your own is what makes Persona useful.

edit: at realworld crypto, this was given as a talk. This is Google's possible direction.

http://www.ietf.org/proceedings/81/slides/tls-1.pdf


Biggest problem I have with Persona is one of it's main selling points; if you log in to one place you're logged into all the places. That may sound great, but it really isn't. It means that you can log out of a site because you don't want people sharing your machine to have access to it. You then log into a different, lower-security site. Instantly that first site is accessible again.

I wrote a whole thing on Persona a while back ( http://lepidllama.net/blog/trying-out-mozilla-persona-browse... ) but that ended up being the killer for me. It might be fine for activities like posting comments on a blog, but any site which stores or presents some aspect of who am I to the world needs to be a bit more secure than that!


I guess this is just a sign that I am getting crotchety, but headlines like this just anger me:

Why we love/like X, And why you should, too

My immediate reaction is always something along the lines of, don't presume to tell me why I should like anything. Tell me why you like it, and be done with it.


Your anger is misplaced. They did do exactly that.


I love Persona! I created a demo MVC3 application using Persona for authentication and its fantastic from a developers perspective.

https://github.com/sergiotapia/ASP.Net-MVC3-Persona-Demo

Authentication is simple to implement and you don't worry about user password protection.

I'm surprised interest has died down for the project given how easy it is to use. Maybe Mozilla should market it more?


Persona is _awesome_. I use it on all my sites.

But it also proof that being awesome not only is not good enough to be successful, but simply doesn't matter. The user is not interested in a solution that is awesome, but one that doesn't scare him. And a big ugly third-party popup is as scary as stuff on the web gets these days.

Remember Ogg Vorbis?


Vorbis ended up being very successful in some niches - audio for games springs to mind.

Persona might find its own niche, even if it never completely displaces Facebook user authentication on the web.


And Spotify uses it too - it just is not very visible https://support.spotify.com/uk/learn-more/faq/#!/article/Wha...


Absolutely. Ogg Vorbis could have crushed the big licensed formats, though, if the Xiph Foundation had had any clue about telling a good story.

I love Persona and I love Ogg Vorbis, but both fail(ed) at understanding what _normal_ people look for in authentication/audio compression formats.


But, this doesn't solve the issue that you're still trusting someone else with your secret (your password).

We need to move towards protocols like SRP[0] in general so that no matter where I'm logging in, noöne has my password.

[0]: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

EDIT: As ubernostrum points out, Persona is solving a different problem than SRP does. However, one of the reasons different identities (username/password combinations) are encouraged currently is because providers can't be trusted with the secret of your password.


this doesn't solve the issue that you're still trusting someone else with your secret (your password)

If you run your own identity provider, you are only trusting yourself with your secret.

Also, nothing about Persona requires password-based authentication -- you can use any mechanism you like to authenticate to your identity provider.


The problem I have with that is that I haven't found decent identity providers last time I checked.

Without some decent/proven implementations I'm hesitant to use it. I don't quite like using Mozilla's service (mostly not because of trust, it just feels half-assed not to go the extra mile and is considered an intermediate workaround/solution even by Mozilla, as far as I know). Without decent options to self host I guess I could implement it myself - but that's a big step.

So .. although I'm a fan of the concept, I'm still not using Persona anywhere.


Have a look at mine:

https://bitbucket.org/djc/persona-totp

It's less than 150 LOC of Python code (plus some HTML templates and a few basic tests).


Will do, thanks a lot. Since my infrastructure box is mostly python based (radicale, for example) this might fit in nicely.


Since everyone is plugging their own: here's a identity provider daemon written in Go:

https://github.com/wulczer/persona-idp

It uses my Mail Transfer Agent to identify, so I can just use me email password to log in to Persona-enabled sites, but you can easily swap it out for a different credentials checker.


That's quite cool - actually that'd be exactly what I want to host myself.

Not a fan of go (cough The stripe CTF made it again clear that go get isn't exactly what I want, ever), and don't want to build stuff on my box, but I'll certainly check it out. Thanks for chiming in!


Maybe you'll like the one I made: https://www.persowna.net/


I saw your link somewhere else in this thread.

I do like the site and I think it's a clever thing to build a service around it. But .. all of your options (well, all affordable ones, all that I even looked at for myself plus family) are hosted, right? I could use my own domain, but you'd be the endpoint?

Don't take that the wrong way, but you're not more trustworthy than the Mozilla Foundation.. :)

Please correct me if I missed something, but it seems as if you interpreted my self-hosted as 'can use your own domain name', no?


Yes, exactly. There are currently other options if you want to be completely self-hosted (and are not a large enterprise that has multiple users and wants a behind-the-firewall option). Persowna is a more featureful/(hopefully) secure option than the default bridge.


> If you run your own identity provider, you are only trusting yourself with your secret.

And the service I run the identity provider on. And the janitors they hire. And the legal jurisdiction it resides in. And the people (voters, oligarchs or dictators) who control that legal jurisdiction.

A secure log-in system does not require any secret which leaves my immediate personal control. This is not rocket science, and is not difficult.

My laptop browser should have an internal secret key; I should be able to get an account on a site with a site-specific key; I should be able to authorise a site-specific key on my desktop to access the same site. Heck, I should be able to connect from a public computer temporarily, and authorise the same usage with my phone. No passwords or long-term shared secrets required. If my laptop, phone or desktop is stolen I should be able to, with some inconvenience, kill the access for that device and only that device.

None of this is rocket science. It's all very possible, and the UI could (I think) be quite elegant. In part, I blame X.509 and the CA mafia for making it so tough: it was in their interest to have a rigid global hierarchy rather than a free-flowing ecosystem; it was in their interest to make certificate minting expensive rather than free (never mind that the root of any certificate hierarchy could still cost...); it was in their interest to tie identity and authorisation, which simply doesn't make sense.

One of these days I really do need to brush off SPKI, clean it up and try to push it as a solution. The guys who designed it thought long and hard about identity and authorisation, and they came up with some damned smart solutions.


> If you run your own identity provider, you are only trusting yourself with your secret.

Good point.

> Also, nothing about Persona requires password-based authentication -- you can use any mechanism you like to authenticate to your identity provider.

Good point. However, since noöne uses SRP or anything similar, de facto you're still sharing a secret (unless you're running your own provider).


SRP doesn't solve that problem. Applications that authenticate with SRP hold crackable password derivatives.


I got excited by SRP a few months ago and looked into it, but decided that it didn't have that many advantages compared to storing hashes properly on the server (with a strong KDF) and using TLS.


The 'storing hashes properly on the server' problem is the biggest problem with website authentication right now, as seen by the number of breaches resulting in weak-ass hash dumps.

With SRP the derivation of strong keys using a KDF is done by the client. Not only is this more scalable, it means users don't have to trust web developers, who are almost never cryptographers, to get the 'storing hashes properly' bit right. Not having to trust is great. Not having to trust websites with our chosen passwords also means most of the risk of reusing passwords across services just goes away. In short it's epic win for users, but it's extremely difficult to get people to see that the real problem is a bad trust model.

Another reason to like it is it's safe to use over vanilla unencrypted, unauthenticated connections, which could be important because certificate authority integrity is, imho, the second biggest trust issue on the web right now.

Persona and OpenID etc are flawed because they copy that very same CA trust model.


You may as well generate onetime junk password, feed it into persona and later rely on password manager to remember it for you.

You should avoid reusing your passwords across sites. BTW Persona helps you with that.


But my point is that you're still trusting your email provider with the password, and now if that get's leaked an attacker has access to (arguably/potentially) more sites than they would have before (via password resets).


How so? If an attacker gets your mail password, they can pretty much already password-reset every single site you use.


That is exactly why sites shouldn't provide password reset by email. Email shouldn't be used for authentication in any case. It's really insecure solution.


Unfortunately security questions aren't much better. The best solution is to expect the user to safely and securely store a reset-key (kind of like Mozilla's Sync).

However, to the average, non-techie user this is

* Bad UX * They won't store it securely * They'll lose it

Another option is using public keys with some form of transition mechanism.


Last time I looked into persona, it was essentially unusable for my usage - there's no reasonable way to use a different email address to sign up for every site. I like to know who leaked my email address when I start getting spammed.

Edit: looks like they may have have fixed it: http://support.mozilla.org/en-US/kb/how-do-i-manage-my-perso...

Though I'm not sure if it remains usable with hundreds of email addresses.


That's one of the things I needed too, so I built this (sorry for posting it so much here): https://www.persowna.net/

You can add your domain as a catch-all, so you can authenticate with anything@your-domain.com and it will use a single account to authenticate. Services will still see your custom email address, but you only need one password.


If there is one company I can trust my data with, it's Mozilla.


It's funny that the few entities we'd be more inclined to trust are the ones that go out of their way to make sure we don't have to trust them: Firefox Sync does client-side encryption so you don't have to trust the server, Persona does authentication via an identity provider so you don't have to trust persona.org...


I didn't mean persona when I said trusting with my data. I am just saying if ever I could trust a company with my data, it would be Mozilla (shows how much I trust them).


I don't get why persona needs its own branding... Nobody knows what persona is. It should say login with Firefox. Did fb create a new brand for its login system? No it's just login with fb, same with literally every login service except freaking persona. Use your most popular brand instead of forcing all developers to evangelize a new brand. That's just not going to freaking work.


Persona works across browsers, so "log in with Firefox" is worse IMO.


If this is the case, why not just use pseudo-crypto cross-branding and just call it: "What does the Fox say?" 350M youtube views can't be wrong, can it?

Popularity is one thing, but if a user is using Persona login on Chrome or some non-FF supporting browser, and it says "Firefox login", they're probably going to be confused, and possibly close the tab. As a site owner who's implementing Persona, that's the exact opposite of seamless.


"login with your email" is IMO the most adequate wording


This may sound paradoxical, but Persona has nothing to do with actual email. Well, except for Mozilla-provided fallback/compatibility authenticator that, indeed, uses actual email.

It just a protocol that - oversimplifying things - allows a certain server (identified by domain name) to issue you a certificate that says that you have a name associated with that server.

It's usually an email, but can be anything that could be represented as (name, domain) pair by concatenating those with "@" character. For example, XMPP ID, forum nickname or system account.


That is true, however "login with your email" will be understood by The Average Internet User. Any discourse on login identifiers, domains, xmpp, certificates, et al will just scare them. That's a non-starter.

We use "login with your email".


The problem with that is confusing users. When you have a "login with firefox" option you will get "but I don't use firefox anymore, I switched to chrome".


How many people here know BrowserID/Mozilla Persona was based on the http://swiftlogin.com project? http://www.youtube.com/watch?v=dGQYHOzLMUk


We use it at Mighty Spring (http://www.mightyspring.com) and it's pretty good! The documentation around backend setup is a bit confusing and doesn't cover some corner cases (like testing on dev servers) but with enough hacking you can get it to work. The front end plugin I went with (https://github.com/altryne/browserID-jQuery) needed a bit of tweaking (to both the code and docs, which was submitted to them), but other than that, relatively easy setup.

Our site is uniquely targeted at developers, so I felt that using Persona as a login option was only natural.


I use it for http://www.4four.org and really like it.

The one small complaint I would have is that it would be great if (after initial setup) the login process was a bit faster. It should be quicker than the old-school username and password IMHO, but with the animations and latency on authentication it all seems to feel a bit sluggish. Especially as the cookie for it expires frequently - which is a bit shit for users of a forum where you're normally signed in until you decide otherwise.

This is still in my minor complaint box because I suspect there's tweaks I could do which I haven't had time to explore yet.


The site cookie doesn't have much to do with the Persona bridge cookie. For example, for my sites, I expire users after a month, so they don't have to log in more frequently than that.

Persona never comes into it, unless they manually log out.


If you're like me and this is the first time you're hearing about this, and want to know more about the implementation, check the bottom of this page:

https://developer.mozilla.org/en-US/Persona?redirectlocale=e...

Edit: I've checked out the login process in the linked site, and it works well, but the popup window U/I seems like it's ripe for phishing attempts. It would be very easy to replicate the look of that window and fool people into thinking they're using Persona when they're not.


The FIDO alliance is the other major industry standard that is being started. http://www.fidoalliance.org/


We used Persona for http://bit.ly/blibonline - and one of the problems we faced was that we would have liked the registration process to let our users tell us the name / icon (avatar), which was missing in Persona then. Any news on the timeline for these additions to Persona? (OpenID gives those two elements from registration/usage)


I think the preferred way to implement this is with an interstitial after the login, and then they can be changed from the settings page, as usual.


I really like the idea of Persona, and it's very easy to integrate with your own site. However, it's still a bit unreliable. For example, clicking on the zonino login button just opened a mostly-blank page for me (white on the left, light grey on the right, with a pointy arrow in the middle; a bar at the bottom says "Mozilla Person...", but no way to log in.

If I do "F10 -> View -> Page Style -> No Style" I see various boxes, but it's not obvious how to proceed. I entered my email into the top-most box and tried clicking the "next", "sign in" and "OK" buttons, but none of them responded (there's also "continue", but that's greyed out). I think I had the same problem when I tried it last year.

Probably just some browser plugin issue, but would be nice if it were easier to debug... Works in Chromium though.


Do you use NoScript? Persona is heavily Javascript-reliant.


OK, I finally figured this out. The persona tab is replacing the web-page. So, to log in:

1. open two copies of the page

2. click the "Sign In" button on both

3. a working Persona sign in appears in the first tab


I do, but it's disabled for persona.org. Even if I "Allow Scripts Globally" it still doesn't work.


On of my biggest problems with Persona (and why I stopped using it almost exclusively) is that the popup dialog is badly designed. For instance it has email and password as two consecutive fields which confuses my password manager greatly with different accounts. Secondly does it not work at all for me on mobile devices.


What happens to my account if Persona dies or is temporarily down? Does that mean that I'm locked out?


The online component of Persona only matters in the interim (nothing it provides is necessary to the protocol, it is all about lowering the bar for implementers/providing support for browsers without a built in implementation). In the long term, you have to worry about whatever identity provider you are using.


Nothing depends on Persona. For example, see https://persowna.net/, which I wrote and which you can use with your own domain for authentication. You can also install your own ID provider on your site and not rely on any third party.


And if "your" domain is suspended, revoked or just expired?

You don't own a domain, you only temporarily lease it from a registrar. Just like with the email account with an email provider.


Yep, and that doesn't stop us from relying on email for our identity.


I doubt if it's true. From my experience, email is usually used only as a credential, not an identity.

Some cloud evangelists try really hard to change that, though.


The goal is to not require a 3rd party server. If they could get the protocol in browsers natively, they don't need it.


Your cookie stays valid if you haven't logged out.


Here is one of the reasons why I personally believe in and feel we really need persona: https://news.ycombinator.com/item?id=7133965


The UK government is about to launch an Identity assurance scheme where different providers (Post Office etc) check your drivers license then give you an account hw in is then oauth'able

in short Facebook logins but with actual real names that like governments can trust

just saying that this might be the start of what usually happens to private companies colonising what turns out to be a public good


Sounds great. I need an e-mail provider that implements the protocol? Are there any? How can I implement it on my self-hosted e-mail?


Not necessarily. If the email provider doesn't implement the protocol, it will send you an email to verify when you log in.

Thanks to Identity Bridging on the Mozilla Identity Provider, Persona can also use the APIs of supported providers to verify your identity: it can verify a Gmail address by connecting with your Google Account, and has something similar for Yahoo! Mail as well.


Ah, I kind of understand... Thanks for your help :)


So what happens when my Person account gets compromised?

I'll stick to my many accounts / many passwords approach, I think.


Use 2 factor auth to mitigate that? To me that seems safer than having 100s of different accounts with no support for 2 auth.


2FA is a nice add one but not a panacea.

Any account will be compromised - it's only a matter of time. When that happens, it's best (as recent articles in Wired, Ars Technica and others demonstrate) to have a broad account "ecosystem".


Hm, interesting. I see your point.

What about Facebook/Google/Twitter Sign In buttons - do you think Persona is an improvement over those?


technically - yes, it frees me from being part of (google/fb/twitter... whatever network is trendy now) and still sign in, practically,at the present moment, no - only geeks know about it

Edit/update: if compromised, you loose all linked accounts, however, with google/fb/.... it is the same, but this is less leaky to 3rd party, if this comes as default login, then we would have only a dozen of logins (persona/email, + important accounts, e.g. banking something similar... ), not ~100 of them, thus resetting 100 passwords is just 1 action


What happens when your email account gets compromised and the attacker uses the "forgot my password" feature on each site?

If you say you use multiple email accounts, then you can also use multiple Persona accounts. In fact, support for multiple accounts is part of the plan.


Like any sensible person, all my security question answers are of the "Correct Horse Battery Staple" type.

I don't see how introducing a single untrusted third party, many accounts or otherwise, is better than using a couple of trusted third parties such as gmail and hotmail.


The goal of Persona is that you should be able to use Hotmail and Gmail as your trusted identity provider; the current system is just a stopgap until there's more support from providers.


you can have multiple personna accounts if you want to separate accounts assertions.

i actually don't think this argument holds water.

it's the same with any auth system. you can use 2FA, etc. in the end if someone compromise your laptop you're screwed, they get all the passwords/assertions anyway.

They can't make assertions from the server side.


What happens if someone picks my lock.

I think I'll stick with my 20 doors with 20 locks.


Shameless plug: I've made some code examples of how to integrate Persona with your site: https://github.com/workhere-io/personaexamples. The examples are for Python (Flask) and PHP.


This doesn't work with JS disabled, with no indication that it doesn't work as intended (it just bounces the visitor back and forth between 2 pages).

Persona is very convenient for users, but it would be more secure to not trust a 3rd party.


My understanding of the technology is that the endgame for persona is that you don't have to trust a third party. Instead, the authentication will be provided by the browser itself (the protocol behind Persona is called Browser ID). The current implementation is just a shim until browsers provide support for it natively.


The authentication will actually be provided by your identity provider (which will usually, but not necessarily, be your email provider).


Did they give up on the in-browser stuff? Or did I just get the plan completely wrong then?


If I recall correctly, the in-browser stuff is just a UI for selecting your email address and contacting your identity provider.


I wouln't say "just". It solves an important problem, the fact that the site you are logging in could have a javascript keylogger to read the password you are going to enter.


Oh, certainly, I meant "just" as in "just the client-side part of the protocol".


And what's the timeline for Mozilla providing it in Firefox?


As JavaScript is basically a required feature on the web these days, who cares? All web browsers that anyone tests for come with JS enabled. Anyone who runs NoScript or similar knows that when sites randomly break, they need to either enable JS or accept the fact that they can't visit that site without it.

You can run your own Persona provider, meaning you don't have to trust a 3rd party.


>As JavaScript is basically a required feature on the web these days, who cares?

People who don't live in a fantasy bubble world where that is true? "Hey, just throw away 1% of your potential user base for no reason" isn't a very compelling sales pitch.


I'd be very, very surprised if the number of people with JavaScript disabled is as high as 1%.

The number of people who have JavaScript disabled and don't know how and when to re-enable it is so small as to be irrelevant.


It's generally less than 0.5% and the few techies that do it via NoScript are well aware of what to do when things break. And you'll spend far more than 0.5% of your time and budget working to make a JS-less fallback version of all your work.

It's like supporting IE6 at this point. It's a tradeoff. And for the vast majority of us, it's a near-complete waste of resources to cater to them.


Depends... if it takes 20% of your time to make your site work for 1% of your potential users who have a feature disabled, I say forget it.

The caveat to this rule is, of course, if you have a site that is very heavily trafficked.


That's an arbitrary and useless guideline, using made up numbers. If losing 1% of your potential users costs $100k in lost sales a year, and 20% of my time costs $20k, then spending that 20% time seems like a pretty good idea.


See listed caveat. If 1% of your users are netting you 100k, your site is likely heavily trafficked.


Real teams are doing that all the time, you have to prioritize bugs, they rather fix important stuff and not care for people using IE6-8 and people using linx.


Yet another OpenID/OAuth/Whatever? Another SPOF.

Give me separate logins and KeePass any day.


The protocol itself doesn't come with an SPOF. Only the transitional current implementation, required for bootstrapping purposes, does require the JavaScript shim hosted by Mozilla. In the future, at least Firefox itself (on desktop, Android, and Firefox OS) will come with built-in support.

And, quite importantly, running your own identity provider (which is another SPOF in many systems) is pretty straightforward and well-defined in the Persona ecosystem.


If Identity Provider goes down, it is a SPOF for the account, but the same is with FB/Twitter login


In Persona, the Identity Provider is not involved in each login, it just signs a temporary certificate which can be re-used by the browser, so as long as the downtime is under a few hours, the user shouldn't have much of a problem.


And if the Identity Provider's gone for a prolonged period now you've lost your identity with (almost) no means of recovery. Mostly, because, while you might believed the contrary, you didn't ever own your "own" identity in this scheme.

That's exactly what SPOF is.


simply wrong. This is NOT another OpenID. Your judgment is an ignorant one. The long-term vision is even further from the current substantial departure from OpenID: to be verified by your browser instead via JS etc.


That sounds even less secure, if anything.


OpenID was far, far worse from a usability perspective.


"We're sorry, but your browser is not currently supported." --Persona, from Safari on iPad, iOS 7.


...What? That's just bizarre. I tried the Persona signup form just now on a site and I had to enter my email address, pick a Google account, and it was done. Pretty much like any other OAuth signup, so I don't see why Safari in iOS wouldn't be supported.


I had private mode enabled. Works with private mode disabled.


I use Persona and I wish more websites supported it.


We don't know your password. Google doesn't know you're signing in to Zonino... mozilla knows ;)


Except the way the Persona protocol is designed means that Mozilla doesn't know either.


As someone else pointed out, Mozilla won't have to know once the protocol is more supported. Currently they're acting as a transitionary bridge, not a required element.

Also, iirc, Google doesn't have to know where you're signing in either. I'll have to double check that part.


The identity provider/bridge doesn't know either. They sign an assertion, so they know that you want to log in somewhere once, but not where or when.


> We think that Persona is a great attempt at improving usability, security and privacy...

We use Persona and love it. However, I wouldn't trust Persona for securing sensitive information. There seems to be no password requirements (at least when I checked months ago.)


That's incorrect, the identity provider is not specified by the protocol. Each user can use whatever IdP they want, with arbitrary password requirements.

I built my own IdP that has 2-factor auth, for example: https://www.persowna.net/


It's possible to implement an identity provider, sure. But that doesn't change the fact that there are no password requirements using Mozilla's default provider. Poor default design.

Btw, your service sounds very nice for those interested in securing a domain, but I was a little surprised by the pricing. Nearly as much as a Google Apps license itself.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: