3 ms·

I recently investigated using Persona for a web service and mobile app that I am building. I think I will be using it. However there is one aspect that bugs me.

I recently investigated using Persona for a web service and mobile app that I am building. I think I will be using it. However there is one aspect that bugs me. I'm not very knowledgeable about crypto stuff so maybe someone else here can enlighten me. The part that bugs me is that it seems to rely on clients keeping a private key secret and I'm not sure we can trust clients that are often programs downloaded off the internet to do so. What stops a maliciously coded BrowserID client from sending the user generated private key to a web service (the RP) along with the identity assertion? Wouldn't this allow this malicious RP to login to other services that support Persona on the user's behalf and read and write info from his other accounts at least for the duration of the certificate? This certainly wouldn't happen in the Mozilla implementation of the browserID client and I'm not sure it's a huge concern. Since the certificates are of short duration it's certainly not as bad as people using the same password across different services. And of course all single signin systems have risks when malicious services are involved such as the impersonation of the login page to get users to reveal their passwords but still, can someone put my mind at ease about this particular case?

anonymoushn 14y ago
Services should reject any "identity assertion" that claims to be for the wrong service, so having a malicious client log in to my LivingBook won't allow you to compromise my Twindr account. You can read more if you like: https://developer.mozilla.org/en-US/docs/Persona/Protocol_Overview https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov... Edit: Before I talked about some stuff that you obviously already knew :)
- BenoitEssiambre 14y ago
  What I'm talking about here is a malicious service (Relying Party) that provides his own malicious BrowserID client to the user. Web services or mobile apps often provide their own clients. If the user's private key is leaked to a malicious RP when the user logs in this RP, can't it generate fake identity assertions (using the leaked key) to use along with the user certificate to login to any other Persona account? The faked identity assertion can claim to be for any service.
  - anonymoushn 14y ago
    Ah, yes, a valid user certificate and the corresponding private key would allow you to impersonate the user for other RPs for the duration of the cert. That is troublesome. Edited more: If you ship the user a malicious client and the user runs it, you can just keep his email password. This probably grants you access to all of his accounts for longer than the cert would last anyway. If the user uses 2-factor auth, the private key + cert combo is more useful than the password though.
    - lukeh 14y ago
      Having a browser native client will help.

anonymoushn 14y ago

Services should reject any "identity assertion" that claims to be for the wrong service, so having a malicious client log in to my LivingBook won't allow you to compromise my Twindr account. You can read more if you like: https://developer.mozilla.org/en-US/docs/Persona/Protocol_Overview https://developer.mozilla.org/en-US/docs/Persona/Protocol_Ov... Edit: Before I talked about some stuff that you obviously already knew :)

BenoitEssiambre 14y ago
What I'm talking about here is a malicious service (Relying Party) that provides his own malicious BrowserID client to the user. Web services or mobile apps often provide their own clients. If the user's private key is leaked to a malicious RP when the user logs in this RP, can't it generate fake identity assertions (using the leaked key) to use along with the user certificate to login to any other Persona account? The faked identity assertion can claim to be for any service.
- anonymoushn 14y ago
  Ah, yes, a valid user certificate and the corresponding private key would allow you to impersonate the user for other RPs for the duration of the cert. That is troublesome. Edited more: If you ship the user a malicious client and the user runs it, you can just keep his email password. This probably grants you access to all of his accounts for longer than the cert would last anyway. If the user uses 2-factor auth, the private key + cert combo is more useful than the password though.
  - lukeh 14y ago
    Having a browser native client will help.