45

Mozilla went live with a new service called BrowserID/Persona (announcement, background). It is intended to replace current single-sign-on solutions such as OpenID, OAuth and Facebook.

One advantage is that a future integration into the browsers will reduce the phishing risks. Also, the identity provider will not be notified about the sites someone logs in to, which is good from a privacy point of view.

What are the issues with BrowserID/Persona compared to OpenID/OAuth/Facebook?

3

5 Answers 5

31

I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme.

I am concerned about (in no particular order) :

  1. Unauthorized use of the private key
  2. Rich client support (Outlook, Notes, etc.)
  3. Using from multiple computers
  4. Private key protection or encryption (on the client)
  5. Authentication of key generation requests
  6. Privacy

Details below. First a one line summary (in bold italic) and some clarifications.

1. Unauthorized use of the private key

The private key will be protected by the client, with varying degrees of security.

I am worried that any the private key will be used without my consent. When trying to authenticate, a signing operation will take place. I must be prompted before it is used, or else a rogue script could get my browser to sign a logon ticket and submit it. Rogue script could come from a widget, add or other XSS. Implementation of this mechanism will vary in every browser, and even on different platforms for the same browser, or different versions, etc. With a somewhat inconsistent visual, users are at a greater risk to being lured to approve a logon request.

2. Rich client support (Outlook, Notes, etc.)

It was desinged to work with web mail accounts. Enterprise "fat" mail clients are somewhat left behind.

For Browser ID to work, you need a browser that supports it. In the meantime, some browserid.org issued "JavaScript shim that implements the missing functionality using standard HTML5 techniques and cryptographic routines implemented in JavaScript".

Users in a corporate environment who use fat mail client (Outlook, Notes, Thunderbird) will be late adopters, because the protocol will have to be implemented in those clients too. Not to mention that Outlook does not share a keystore with Firefox, or Thunderbird with IE.

3. Using from multiple computers

It leads to a proliferation of private keys, because the scheme does not to have a central authority.

And there is a mobility problem. I will have to register (generate a private key) for every computer I use. How will I go about deleting my private key in an internet kiosk, or a borrowed computer ? Even with a single computer, how will I revoke a key stored in a stolen computer ? Since for a single user, multiple signature keys are valid (because each of my computers have its own valid private key), from the service provider point of view, any access token signed by a known authority must be valid.

4. Private key protection or encryption (on the client)

Access to the key must be authenticated, which brings passwords back in the picture.

It can protected by a password (limiting its malicious reuse), but if I ever change my password somewhere, it will not synchronize unless I use some browser/cloud based sync network. Having a password to remember somewhat defeats the purpose of this scheme. Chances are the same password will be used to secure every key, much like the same password is used now to authenticate to multiple websites.

5. Authentication of key generation requests

There is a gap between the access request and key generation, wich an attacker could use for phishing.

It is unclear to me how the email provider/certificate authority will handle CSRF issues. How will they know that a request for key generation is legitimate ? Will my spam folder be filled with certificate generation requests ? Or will key issued only with DKIM email servers ? What if the request was intercepted on its SMTP way to the server, could it be modified ?

6. Privacy

Using a tag allows browserid.org to break the same origin policy.

And using a script tag to include the browserid.js allows them to bypass the same origin policy. BrowserID.org will (have the power to) know about every logon attempt you make. Or you will have to host the script yourself (assuming it is self contained), and upgrade it if/when security flaws will be identified in it.

6
  • 2
    very nice writeup. And what about backups? If the keys are all stored in browser-space, as opposed to at an online provider, are there builtin mechanisms to support backup? Recovery mechanism? etc...
    – AviD
    Jul 18, 2011 at 10:44
  • nice set of questions but they don't answer the question. I am told that they should, since other answers cannot answer other answers. And if other answers cannot answer the questions posed by other answers then there is not way to show that these questions have very good answers by themselves.
    – bblfish
    Jul 18, 2011 at 11:45
  • Indeed. Think of my questions as concerns you don't have with OpenID et al. I will edit my answer to use correct style. English is not my primary language, feel free to edit.
    – ixe013
    Jul 18, 2011 at 13:00
  • I think there's a few major misconceptions in this answer. Firstly, Persona doesn't extend SMTP or require mail clients to do anything. Mail providers are supposed to provide a HTTP page where they authenticate the user (by whatever means) then sign keys. Webmail sites would accept a password and check it against their login credential database, typical Microsoft enterprise setups would accept a password and check it against Active Directory. (To be continued - I'm running out of characters.) Feb 17, 2014 at 5:35
  • Continuing on: Secondly, in Persona, private keys aren't special, rather they act sort of like session cookies. Before signing a keypair, the IdP presents the user with a login UI (not unlike oAuth, just provider-independent). The certificate also has a (short) expiration date, similar to a cookie. So, if a key is expired/lost, the user just types in their password again. Multiple keys can also exist connected to the same identity, so there's no need to sync keys between devices or anything; you just type your password in the first time you use the second device. Feb 17, 2014 at 5:57
12

Stack exchange also has a detailed comparison of BrowserId and WebID. As argued there BrowserId is very close to WebID (a W3C Incubator Group at the W3C). Here are some points that need to be made in defence of both protocols usually as they are very different from how public key cryptography is usually done.

  1. Unauthorized script use of key. Agree that this will need to be implemented very carefully by the BrowserID folk. As WebID relies on built in browser certificates that have been around for 13 years, I think that part has been dealt with a long time ago :-)
  2. If you want Rich Client support, use WebID. It just requires a TLS layer - tweaked a bit on the server side. All Operating Systems and all programming languages come with TLS inbuilt.
  3. Using from Multiple computers: both BrowserID and WebID allow you to have any number of certificates, one for each computer. This is not a problem. For WebID see this video WebID creation and use in 4 minutes
  4. Private key encryption on the client: All modern computers come with a keychain that stores your passwords and keys, and that are protected with a password.

    There is a lot that OS vendors can work on to improve security here. On OSX I get asked for a special password, and I can give different tools access to the keychain more or less easily. Of course the keychain should NEVER give out the private key. Giving out the public key is not a problem at all of course :-)

    But of course for desktops one can go even further and use crypto keys as shown in the video Cryptokeys, WebID and Internet Cafes - though it would require browser vendors to improve the UI somewhat. Here you have a hardware token to guarantee that the private key has not been copied. Anyway for BrowserID they would need to integrate this into the keychain, or find a JavaScript way of sending x509 certificates stored in the keychain over the wire.

  5. Authentication of key generation requests: Using e-mail is practical but inherently unsafe. Still people are using it, and the advantage of BrowserID is that it works with this, without requiring people to upgrade to TLS. WebID does all over TLS, so you get commercial grade security there out of the box.
  6. Privacy: I am not very good at JavaScript myself and have it on my list of things to learn - just having too much fun right now with Scala. Anyway, I cannot comment on this JavaScript issue with BrowserId - but would like to understand it better. With WebID there is no JavaScript involved at present, so there is no same-origin policy issue to deal with. The Identity selection is straight in the browser, as shown with in the video mentioned above.

Oh God! I should create an account here once again to post this comment! No wonder Facebook has destroyed the Blogosphere. There you just need 1 password and you can comment on everything you wish.

7
  • 2
    It may be a good idea to delete this posting and post it into a new thread on webid instead. There are so many issues that webid inherits from depending on client certificates that it would get extremely crowded here. Jul 17, 2011 at 22:31
  • 1
    the general question that started this thread was BrowserId versus pretty much every other identity service. WebID is such a service. Here it is coming to the defence of BrowserId, underlining a few differences. There should probably be a symetrical question, not of WebID versus BrowserID, but WebID versus all the other protocols...
    – bblfish
    Jul 18, 2011 at 3:37
  • More precisely: Browserid versus the identity service that are in common use today. The other question is pretty much a jeopardy to your answer because the number of votes - despite your answer being very vague and speculative on browserid - shows that there is interest in webid. And since there are now two alternatives it does make sense to compare them to each other. Jul 18, 2011 at 6:55
  • 1
    The problem is that the previous post asked 6 qestions of BrowserID. Perhaps those 6 questions should also be move to it's own space? After all it does not answer the question of how BrowserId compares to OAuth, OpenId or others either it seems to me. Perhaps the easiest is to change the original question a little so that it fits with the answers given. Clearly before comparing BrowserId to anything else you first need to understand it. And the question is very biased since it asks only for the downsides...
    – bblfish
    Jul 18, 2011 at 11:18
9

I'm submitting a response to the six points in the accepted answer as a new answer ...

1. Unauthorized use of the private key

In the case of the Javascript BrowserID implementation, the private key is stored in local storage under the login.persona.org domain. So a rogue script would have to be hosted on that domain to have access to it. Scripts hosted elsewhere can only access the key indirectly through a restricted PostMessage-based API.

2. Rich client support (Outlook, Notes, etc.)

BrowserID works with any email account or mail client. The Javascript shim is there to support browsers without a native implementation. Nothing needs to be added to mail clients.

3. Using from multiple computers

An important thing to point out here is that keys are short-lived. If you are on an Internet kiosk, keys are valid for only 1 hour, if you are on your own device, they are valid for 1 day. A new one will generated as needed once it has expired, provided that you are still authenticated with login.persona.org. No need for backups.

If you want to clear your private key, just clear cookies (which also clears local storage -- where the keys are stored).

If your computer is stolen, there is a small window during which an attacker could use the key, but as long as you change your password on login.persona.org, the login.persona.org will be invalidated and the thief won't be able to get a new key.

4. Private key protection or encryption (on the client)

In order to get a new key signed by your identity provider, you need to be authenticated with it. If that authentication expires, then you'll need to type your password again. This is similar to cookie-based sessions that seem to be the norm on the web.

The private key is not all that valuable because it is short-lived. In that respect, it has more in common with cookies than with X.509 client certificates.

5. Authentication of key generation requests

The identity provider knows that a request is legitimate because the user is authenticated with them. The fallback identity provider only signs keys after it has confirmed ownership of the email address (in the standard "send users a link with a random token to click on" manner).

The certificate generation / signing happens between the browser and the identity provider via a Javascript API. It's not based on sending emails, so users will not receive any emails beyond the "please confirm your email address" message that the fallback identity provider sends at account creation time.

6. Privacy

Once the API is stable enough, it will be possible for others to host include.js themselves. Right now, we recommend against that.

Another point at which persona.org can see the sites you log into is with the online verification tool at https://verifier.login.persona.org/verify. Once the data format is settled, we will encourage people to verify assertions themselves (e.g. using an Open Source library) and persona.org will not be getting this data anymore.

BrowserID is designed to be a fully decentralized protocol to enable real privacy. However, it also provides centralized fallbacks to work-around the current lack of native support.

1
  • So, with browser-id your identity is vouched by login.persona.org and if that service is unavailable you're stuck?
    – Jasen
    Feb 14, 2018 at 3:54
6

One disadvantage of BrowserID in its current form compared to some of the alternatives is that anything beyond the core functionality is difficult: further discovery of information requires other protocols such as WebFinger, whereas e.g. an OpenID URL can provide links. For instance, it is difficult to get a display name or profile picture from BrowserID (although, since BrowserID gives you an email address, you can get the latter from Gravatar).

One more competing protocol to add to the list: WebID : http://webid.info/

4
  • Thanks for the helpful links and answer, @Danny. Can you say more about what you mean by "anything beyond the core functionality" and "further discovery of information"? Can you give some examples that are likely to come up in practice?
    – D.W.
    Jul 18, 2011 at 1:54
  • 1
    Thanks - interesting. It would reduce confusion if you would identify up-front who Henry is and why anyone would care about his links.
    – nealmcb
    Jul 18, 2011 at 2:25
  • @D.W. The ones that spring to mind for me are 'display name' and 'profile picture'. You can get the latter from Gravatar (since you have an email address) but I've yet to come up with a way to get the former without asking the user to type it in. Feb 17, 2014 at 6:05
  • Thanks, @AdamBrenecki. I've edited the answer to add that information to it. Appreciate it.
    – D.W.
    Feb 17, 2014 at 19:08
5

For more extensive information on BrowserId/Persona, I eventually found what Daniel contributed to the related Q&A on BrowserId/Persona and WebID. (I tried to convince him to post here, but he suggested I do so.)


Security, Privacy and Usability Requirements for Federated Identity by Michael Hackett and Kirstie Hawkey provides a comparison between WebID and Mozilla Persona, which at the time was still referred to as BrowserID.

The main differences that were noted (in Table 1) are:

  • Persona keys are short lived, and should be protected with a password. WebID keys are long lived but can easily be disabled from a password protected profile.
  • The current Persona implementation uses standard browser windows so it is difficult to spot spoofing (this may change once browsers get native Persona support). WebID uses the browsers native certificate selection UI so no chance of phishing.
  • Both Persona and WebID identities can be compromised if control over the owners email/URI is lost.
  • Persona IdPs have no knowledge of SPs that use an identity. WebID IdPs know every SP that uses an identity.
  • If a Persona SP has a cache of the IdP's public key and the browser still has a valid certificate it should still be possible to verify identities. WebID profiles must be reachable otherwise identities will not be usable.
  • Persona has good UX design, whereas WebID is the opposite.

I suggest reading the paper for more detail. It is freely available online, no digital library access needed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .