Re: OpenId, WebID and BrowserID - contributions on the web

On stack exchange there was a question: What are the downsides of BrowserID compared to OpenID/OAuth/Facebook?
http://security.stackexchange.com/questions/5323/what-are-the-downsides-of-browserid-compared-to-openid-oauth-facebook

It's probably easier to read the interaction there by going to that web site. Below is the content as it is now for archival purposes.

[[
Mozilla went live with an experimental service called BrowserID (announcement, background). It shall replace the current single sign in solutions such as openid, oauth and facebook.

Advantages are that a future integration into the browsers will reduce the phishing risks. 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 compared to OpenID/OAuth/Facebook?
]]

The first answer put 6 questions

[[
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) :

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

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

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

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)

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

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

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.
]]

I added the following answers :

[[

Hi BrowserId is very close to WebID ( http://webid.info/ a W3C Incubator Group at the W3C ) as I argued on the mailing list there this morning [1].

So I feel that your questions apply equally to WebID, and will therefore answer for both of those protocols.

[ Btw, for spam prevention reasons Stack Exchange only allows me to post 2 urls as a newbie. So I have placed the URLs here: http://pastebin.com/QWrsaiQk . Notice that if they used a Web of trust system, they could work out if I was known by someone on stack exchange and so drop these restricitons even if I came here the first time in my life. This is what WebID is trying to help enable! ]

	• 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 as been dealt with a long time ago :-)
	• 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.
	• 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" [2]
	• 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" [3] - 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.
	• 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 comercial grade security there out of the box.
	• 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.
]]


[1] WebID and BrowserId comparison on W3C WebID XG mailing list http://bit.ly/o5VkEE
[2] "WebID creation and use in 4 minutes" http://www.youtube.com/watch?v=S4dlMTZhUDc
[3] "W3C Identity in the Browser Workshop" . See the video "Cryptokeys, WebID and Internet Cafes" http://bblfish.net/blog/2011/05/25/

Received on Sunday, 17 July 2011 10:07:32 UTC