8 ms·

Don’t Use Mozilla Persona to Secure High-Value Data

47 points by zobzu 13y ago

fournm 13y ago
I'm sorry, I might just be misunderstanding so please correct me if I'm wrong but... The main vulnerability he talks about is if a major provider were to be hacked and have their file replaced (or go rogue, entirely). In either case, is any login system that doesn't use two factor authentication and allows for password resets via email really going to do any better? Edit: I realize he points out that 2 factor auth really is the only solution here, just, it seems like the criticism applies much more widely than just against Persona.
- callahad 13y ago
  It's more than just 2-factor, your site has to control the second factor. E.g., even if you're using Google OAuth and requiring folks to have 2FA turned on, Google still effectively controls both of the factors.
- drdaeman 13y ago
  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.
  - callahad 13y ago
    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 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. :)
    - Perseids 13y ago
      Zooko's triangle is about secure name systems like DNSSec or Namecoin, not about user logins.
      - dllthomas 13y ago
        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.
        drdaeman 13y ago
        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.
        dllthomas 13y ago
        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...
        drdaeman 13y ago
        > the problem of uniquely naming you to the site Ahem. Did we (consumers, not site owners) really have this problem, to begin with?
        dllthomas 13y ago
        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.
  - Steuard 13y ago
    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.
    - drdaeman 13y ago
      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.
      - Steuard 13y ago
        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.
        drdaeman 13y ago
        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.
  - maxerickson 13y ago
    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)
    - drdaeman 13y ago
      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.
      - maxerickson 13y ago
        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)
      - dochtman 13y ago
        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.
  - yeukhon 13y ago
    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?
    - drdaeman 13y ago
      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.
- _wmd 13y ago
  A slightly less overloaded summary might be "users must trust their identity provider", which is true of every authentication scheme I'm aware of except for perhaps PGP, which itself is a usability nightmare for 99% of the planet No clue what point this post was trying to make
  - wtbob 13y ago
    > A slightly less overloaded summary might be "users must trust their identity provider" And every CA in the world. And trust that the identity provider is always competent (i.e., that the .well-known/browserid file is never compromised). Which isn't really true of usernames & passwords--at least that way a mistake at my mail provider doesn't automatically expose my banking account to risk.
  - yeukhon 13y ago
    > which is true of every authentication scheme I'm aware of except for perhaps PGP I am not getting your point about PGP. Using PGP as Identity authentication? Wouldn't it just be the same as running your own IdP?
callahad 13y ago
Hi, I hack on Persona at Mozilla. Persona is not a panacea, but this post is disingenuous. Benjamin is concerned about user impersonation by identity (email) providers. 1. The identical risk of silent impersonation is present with any OpenID or OAuth-based system. 2. With password-based systems, a malicious provider could also intercept reset emails, creating similar risk. Benjamin notes that "a user will be aware of the attack then next time they try to login," but that's a poor mitigation, since the attacker has already gained access. Benjamin agrees: "On bugzilla.mozilla.org, we disabled password reset emails for users with access to security bugs." If you're operating under the same constraints as Benjamin, then I agree: Persona alone is not sufficient. Nor is any other normal authentication system.
- deleted 13y ago
  [deleted]
- lazyjones 13y ago
  > 2. With password-based systems, a malicious provider could also intercept reset emails, He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.
  - jrochkind1 13y ago
    > webmail login form => the password is typically sent in plain text to the server [regardless of transport security I don't understand what you mean. If the form submit is over https, isn't the password neccesarily (not just typically, but always) _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?
    - natrius 13y ago
      I think the point is that if your email provider is hacked or malicious, your email password is hacked, but that's really only a problem if you use the same password on multiple sites. Don't do that.
natrius 13y ago
A more PR-friendly headline would be, "Use Two-Factor Authentication to Secure High-Value Data." Persona is not the problem.
- pdpi 13y ago
  No, the problem is, as is often the case, people selling silver bullets.
  - dochtman 13y ago
    I don't really agree Persona is trying to sell a silver bullet. If you review the site here, I don't see anything that says Persona is great for all use cases: https://www.persona.org/developers/ https://www.persona.org/developers/
    - pdpi 13y ago
      I meant that strictly in the context of the article saying that "I have seen a trend recently of people within Mozilla insisting that we should use Persona for all logins."
- StavrosK 13y ago
  You mean two-factor auth on the IdP, or on the site itself? The former wouldn't solve the problem, but the latter would.
  - natrius 13y ago
    You're correct. The latter.
dllthomas 13y ago
I think the reason Persona is singled out here is simply that this guy is commenting from Mozilla.
- jessaustin 13y ago
  Yeah it's cool that they tolerate a diversity of thought on core issues.
  - sabbatic13 13y ago
    It is, but there's also some historical friction between the people who hack on gecko (like smedberg) and the people who hack on the services that tie into the browser, so sometimes it's diversity of opinion, and sometimes it's tribalism. In this case, I'd be more inclined to listen to the commenter on his blog, Monica Chew. She's the security/privacy developer. Smedberg is a stone-cold genius who brought such things as Electronlysis to FFx, but he isn't blogging as a security expert. So, it's an informed and intelligent opinion, but it's not quite an expert one and the wording may be somewhat colored by the long-standing tradition of Platform Engineering pointing out where Services Development is getting it wrong.. IMHO at least.
    - jessaustin 13y ago
      Thanks for the interesting background on the personalities. Smedberg isn't wrong about the specific set of circumstances he cites: if an IdP (or someone who controls one, in whatever fashion) knows an RP to which a particular user auths, and wants to fool them both, it can. I think at this point we're supposed to advocate "defense in depth" and observe that there is nothing to prevent layering other mechanisms alongside Persona. For example: client certs, tokens, OTP systems, old-fashioned HTTP-auth, etc. For that matter, you could require the use of more than one IdP! (Not sure if the current javascript lib would tolerate this, but one could certainly modify it to do so... could this get on the roadmap for the rumored browser integration?) I think most IdPs people are likely to use are strongly incentivized not to screw this up, but if it becomes an issue then some IdPs might be able to create value by being more trusted or auditable.
wtbob 13y ago
It seems to me that the issue with respect to the .well-known/browserid which he raises is itself an issue with the CA system; the assumptions are a) that the key serving the site is verified by a trusted CA and b) that the key is serving the correct file. In fact, it's quite possible that a trusted CA is compromised, and it's even possible that the key has been misled into serving (and authenticating) the wrong file. In short, we're entrusting every single CA in the world with the login of every single user in the world. That doesn't seem terribly good to me. A better system, IMHO, would involve offline keys for each identity provider; these keys would each sign an online key (or online keys) which would be used to authenticate the users. Each relying party would have to make a decision on how to handle hitherto-unseen keys (TOFUPOP backed up by SSL is, while imperfect, no indefensible). TOFUPOP would protect against bad-faith CAs, and offline long-term keys would enable key mobility. Note that with a properly-specified certificate calculus, the offline key could authorise its own backups...

47 points by zobzu 13y ago

I'm sorry, I might just be misunderstanding so please correct me if I'm wrong but... The main vulnerability he talks about is if a major provider were to be hacked and have their file replaced (or go rogue, entirely). In either case, is any login system that doesn't use two factor authentication and allows for password resets via email really going to do any better? Edit: I realize he points out that 2 factor auth really is the only solution here, just, it seems like the criticism applies much more widely than just against Persona.

callahad 13y ago
It's more than just 2-factor, your site has to control the second factor. E.g., even if you're using Google OAuth and requiring folks to have 2FA turned on, Google still effectively controls both of the factors.
drdaeman 13y ago
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.
- callahad 13y ago
  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 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. :)
  - Perseids 13y ago
    Zooko's triangle is about secure name systems like DNSSec or Namecoin, not about user logins.
    - dllthomas 13y ago
      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.
      - drdaeman 13y ago
        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.
        dllthomas 13y ago
        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...
        drdaeman 13y ago
        > the problem of uniquely naming you to the site Ahem. Did we (consumers, not site owners) really have this problem, to begin with?
        dllthomas 13y ago
        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.
- Steuard 13y ago
  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.
  - drdaeman 13y ago
    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.
    - Steuard 13y ago
      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.
      - drdaeman 13y ago
        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.
- maxerickson 13y ago
  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)
  - drdaeman 13y ago
    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.
    - maxerickson 13y ago
      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)
    - dochtman 13y ago
      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.
- yeukhon 13y ago
  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?
  - drdaeman 13y ago
    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.
_wmd 13y ago
A slightly less overloaded summary might be "users must trust their identity provider", which is true of every authentication scheme I'm aware of except for perhaps PGP, which itself is a usability nightmare for 99% of the planet No clue what point this post was trying to make
- wtbob 13y ago
  > A slightly less overloaded summary might be "users must trust their identity provider" And every CA in the world. And trust that the identity provider is always competent (i.e., that the .well-known/browserid file is never compromised). Which isn't really true of usernames & passwords--at least that way a mistake at my mail provider doesn't automatically expose my banking account to risk.
- yeukhon 13y ago
  > which is true of every authentication scheme I'm aware of except for perhaps PGP I am not getting your point about PGP. Using PGP as Identity authentication? Wouldn't it just be the same as running your own IdP?

callahad 13y ago

Hi, I hack on Persona at Mozilla. Persona is not a panacea, but this post is disingenuous. Benjamin is concerned about user impersonation by identity (email) providers. 1. The identical risk of silent impersonation is present with any OpenID or OAuth-based system. 2. With password-based systems, a malicious provider could also intercept reset emails, creating similar risk. Benjamin notes that "a user will be aware of the attack then next time they try to login," but that's a poor mitigation, since the attacker has already gained access. Benjamin agrees: "On bugzilla.mozilla.org, we disabled password reset emails for users with access to security bugs." If you're operating under the same constraints as Benjamin, then I agree: Persona alone is not sufficient. Nor is any other normal authentication system.

deleted 13y ago
[deleted]
lazyjones 13y ago
> 2. With password-based systems, a malicious provider could also intercept reset emails, He could also intercept the login attempts (e.g. webmail login form => the password is typically sent in plain text to the server [regardless of transport security]), the user will never notice.
- jrochkind1 13y ago
  > webmail login form => the password is typically sent in plain text to the server [regardless of transport security I don't understand what you mean. If the form submit is over https, isn't the password neccesarily (not just typically, but always) _not_ sent in plain text to the server, but sent encrypted via SSL/TLS cause that's the whole point of https?
  - natrius 13y ago
    I think the point is that if your email provider is hacked or malicious, your email password is hacked, but that's really only a problem if you use the same password on multiple sites. Don't do that.

natrius 13y ago

A more PR-friendly headline would be, "Use Two-Factor Authentication to Secure High-Value Data." Persona is not the problem.

pdpi 13y ago
No, the problem is, as is often the case, people selling silver bullets.
- dochtman 13y ago
  I don't really agree Persona is trying to sell a silver bullet. If you review the site here, I don't see anything that says Persona is great for all use cases: https://www.persona.org/developers/ https://www.persona.org/developers/
  - pdpi 13y ago
    I meant that strictly in the context of the article saying that "I have seen a trend recently of people within Mozilla insisting that we should use Persona for all logins."
StavrosK 13y ago
You mean two-factor auth on the IdP, or on the site itself? The former wouldn't solve the problem, but the latter would.
- natrius 13y ago
  You're correct. The latter.

dllthomas 13y ago

I think the reason Persona is singled out here is simply that this guy is commenting from Mozilla.

jessaustin 13y ago
Yeah it's cool that they tolerate a diversity of thought on core issues.
- sabbatic13 13y ago
  It is, but there's also some historical friction between the people who hack on gecko (like smedberg) and the people who hack on the services that tie into the browser, so sometimes it's diversity of opinion, and sometimes it's tribalism. In this case, I'd be more inclined to listen to the commenter on his blog, Monica Chew. She's the security/privacy developer. Smedberg is a stone-cold genius who brought such things as Electronlysis to FFx, but he isn't blogging as a security expert. So, it's an informed and intelligent opinion, but it's not quite an expert one and the wording may be somewhat colored by the long-standing tradition of Platform Engineering pointing out where Services Development is getting it wrong.. IMHO at least.
  - jessaustin 13y ago
    Thanks for the interesting background on the personalities. Smedberg isn't wrong about the specific set of circumstances he cites: if an IdP (or someone who controls one, in whatever fashion) knows an RP to which a particular user auths, and wants to fool them both, it can. I think at this point we're supposed to advocate "defense in depth" and observe that there is nothing to prevent layering other mechanisms alongside Persona. For example: client certs, tokens, OTP systems, old-fashioned HTTP-auth, etc. For that matter, you could require the use of more than one IdP! (Not sure if the current javascript lib would tolerate this, but one could certainly modify it to do so... could this get on the roadmap for the rumored browser integration?) I think most IdPs people are likely to use are strongly incentivized not to screw this up, but if it becomes an issue then some IdPs might be able to create value by being more trusted or auditable.

wtbob 13y ago

It seems to me that the issue with respect to the .well-known/browserid which he raises is itself an issue with the CA system; the assumptions are a) that the key serving the site is verified by a trusted CA and b) that the key is serving the correct file. In fact, it's quite possible that a trusted CA is compromised, and it's even possible that the key has been misled into serving (and authenticating) the wrong file. In short, we're entrusting every single CA in the world with the login of every single user in the world. That doesn't seem terribly good to me. A better system, IMHO, would involve offline keys for each identity provider; these keys would each sign an online key (or online keys) which would be used to authenticate the users. Each relying party would have to make a decision on how to handle hitherto-unseen keys (TOFUPOP backed up by SSL is, while imperfect, no indefensible). TOFUPOP would protect against bad-faith CAs, and offline long-term keys would enable key mobility. Note that with a properly-specified certificate calculus, the offline key could authorise its own backups...