Hacker News new | past | comments | ask | show | jobs | submit login

The main problem with Persona (and OpenID and OAuth) is that you don't own your identity, by design. The identity is completely managed by provider, so anything that uses Persona is inherently prone to all sorts of identity provider abuse.

Analogy: you don't have any keys to your safe deposit box at bank, but a warden may open it for you after a phone call to your landlord, who'd assert your identity. The obvious question is why we need a landlord in this scenario.

Unfortunately, gpgAuth is practically dead and WebID WG had no progress for two years.




It's a delicate balance between security and usability. Zooko's triangle applies here. To wit, GPG and client-side SSL certificates have pretty ideal security properties, but impose upon the user to manage storing and syncing key material between devices.

http://en.wikipedia.org/wiki/Zooko%27s_triangle

EDIT: Heh. Actually Zooko's doesn't fully apply here, but it's still a fun read. Thanks Perseids and drdaeman. :)


> Zooko's triangle applies here.

Certificates fit into Zooko's triangle just fine. They're decentralized and secure, but those keys don't mean anything to humans. Is lack of human-meaningful global identifier (like an email address) a problem? I believe we're pretty much fine with choosing a name (usually, a pseudonym) when registering with a service. Actually, I believe we even enjoy an ability to name ourselves as we see fit, and there's no real need for human-meaningful global identity identifiers. Or I'm wrong on this matter?

> impose upon the user to manage storing and syncing key material between devices

I don't see any serious problems with storing keys. Could you explain this a bit more? Did you mean that keystores are less secure than a browser logged into Persona/email account? If so, TPMs/HSMs are also getting more and more widespread (although rarely supported and used in practice, which is regrettable) and can further improve situation with secure key storage.

Password sync can be made both usable and reasonably secure (proven both by both Mozilla and Chrome), why key sync can't? One can sync a single key over multiple devices using some kind of key escrow, or trade a bit of convenience for security with the necessity for one-time initial device setup (signing device key with a master key).

I'm no security expert, but I think the most problematic part with certificate-based credentials is not syncing or storage but revocation of compromised credentials. But it's the same with passwords, certificates, emails and every other credential system out there.


Zooko's triangle is about secure name systems like DNSSec or Namecoin, not about user logins.


According to the wiki page, it's "a conjecture for any system for giving names to participants in a network protocol".

"Nicknames users choose for themselves" is listed as one example point in the space.


From what I've seen Persona is mostly advertised as solving problem with credentials (passwords, OpenIDs, etc.), not nicknames.

Actually, I don't think there's anything wrong with nicknames and their lack of global uniqueness. Moreover, I believe it's a good thing.


Persona solves the problem of uniquely naming you to the site, on the assumption that you already have a unique email. There's more pieces here with their own issues, but I think Zooko's triangle is still relevant.

"Actually, I don't think there's anything wrong with nicknames and their lack of global uniqueness. Moreover, I believe it's a good thing."

That depends entirely on the applications you're intending to put them to...


> the problem of uniquely naming you to the site

Ahem. Did we (consumers, not site owners) really have this problem, to begin with?


That's irrelevant to whether Zooko's triangle applies, which was all I was weighing in on.

That said, yes, consumers totally have this problem. We encounter it visibly every time a username we want is taken when we try to sign up for a site. The effectiveness with which Personal eliminates it entirely, ameliorates it, or merely pushes it off to other parts of the system depends on other details of the service in question.

It's also not the only problem Persona purports to solve, simply the relevant one.


If I understand Persona correctly, you are entirely welcome to have the bank keep your cell phone number on file instead of your landlord's number. You only need to rely on a landlord if you don't want to go to the trouble of carrying a phone of your own.


If you meant I can setup my own Persona auth server on my "own" domain, then it's just that my landlord is my domain registrar. It's probably less likely that one would be stripped off "their" domain name than of "their" email account, but the problem still remains. The fundamental principles don't change in this scenario - none of credentials are in your direct possession.

If you meant that Persona consumer site can consider Persona to be not an identity but a credential, and ask me for a secondary one (2FA), then you're right. But the question on why need a landlord as a part of authentication protocol remains open.


Ah, I see your point now: my cell phone carrier can still trick the bank into unlocking my safe deposit box.

But can't we do something similar for every possible system? By controlling my computer's OS, Apple could in principle have a copy of my GPG keys and passwords right now. Ok, I'll use Linux... but do I need to worry about Intel recording the same data somehow? The point is, I'm constantly being forced to store my credentials in someone else's hands.


Well, not really. You could build your own HSM, that would store your keys and sign things for you. Obviously, only with your physical permission (a button press or even a PIN entry).

An AVR (like Arduino) would suffice without much need to trust hardware vendor. It has no communication channels except for the one you define (and you can and should define quite a restricted one) and not much die space (and too low cost) to have a backdoor to begin with. (And really paranoid ones could always go with TTL.)

The only serious problems are cryptographer-vetted RSA implementation that would fit in an AVR and writing a PKCS#11 driver for such HSM.

Yeah, this is totally on tinfoil-hat-grade paranoid side of things, but a CPU-level backdoors are not far from that.


People don't want to understand or care about identity and authentication. In that context, a nice thing about persona is that it makes things easier without really introducing any new problems (email is already a control point).

(I'm tempted to say people don't care, but I agree that they mostly don't want other people accessing their accounts)


Most don't. Some do.

For those who don't it shouldn't matter whatever they're using (some third party account or a personal certificate or a saved password) to authenticate. They click "login" and they get what they want.

For a minority of those who do, leasing their identity from a third party probably don't looks like a good idea.


On the other hand, those people can mostly run their own IdP, so they depend on fewer/more trustable parties (just the DNS registrar, and their colo?), but still get the same user experience.

Which I think is an important property: if you can come up with a better or more secure IdP experience, you can enter the ecosystem without the ecosystem (that is, Relying Parties) having to change anything. That's a huge win over the current state of login.


Sure, but if the question is between medium value sites leaning on sending emails to control accounts and medium value sites leaning on persona for identity assertions, there aren't really any new issues, and all those people get rid of some passwords. It doesn't solve your problems, but it doesn't make them significantly worse and it is a step forward for most people.

(I actually think the use of an email address in persona is genius, anybody who wanted valid email addresses would never consume something like OpenID)


The main problem with Persona (and OpenID and OAuth) is that you don't own your identity, by design

All three work alike if you run your own IdP. If you are yourself OAuth provider then you can control your own identity. If you don't trust Mozilla being your IdP (which you probably shouldn't if you are paranoid), you run your own IdP. Am I wrong?


You can't really own an IdP as you can't truly own a domain name, by which IdPs are identified in OpenID/OAuth/Persona protocols.

With your own server you'll have to lease your identity from the domain registrar. In contrast, with certificate-based credentials you actually possess the keypair.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: