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