W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: WebID security picture

From: Mo McRoberts <Mo.McRoberts@bbc.co.uk>
Date: Fri, 8 Apr 2011 13:30:23 +0100
Cc: WebID XG <public-xg-webid@w3.org>
Message-Id: <3C03FDA3-1C1A-48C4-9586-FD5BB7B738A6@bbc.co.uk>
To: Henry Story <henry.story@bblfish.net>

On 8 Apr 2011, at 12:45, Henry Story wrote:

> If you publish the foaf "anywhere at all" you still are dependent on what that agent publishes about you there. If you have to sign those documents with your private key there then you are not going to be able to generate very dynamic web pages without placing the private key there too. 

It depends on which parts need to be very dynamic surely? Bearing in mind the only assertion we might care about as being concrete (because it's the only one which is relevant to the basic relying party processes) is the public key listing, and so that's the only part of it which needs to be signed — maybe you have detached counter-signatures just for those, referenced as a property of the rsa:RSAPublicKey (e.g., <ex:counterSignature rdf:resource="keysigs.asc" />), or you sign the 'identity' FOAF but use rdfs:seeAlso as a way of associating more dynamic documents… there are plenty of possibilities for that.

> If you want to reduce the surface of attack, the best would be for your foaf to be hosted on the same device you are connecting from. WebID does not exclude that possibility: in fact it is quite possible, especially if your computer is always on. 

Increasing proportions of computers *aren't*, or are behind restrictive firewalls, or layers of NAT… it's fine in the home, but what about on my mobile phone or tablet, or my laptop which moves between networks regularly, for example?

> We are trying to stay very open to all these possibilities by being as light weight as possible. We are just specifying the minimum to get going. This should allow many different implementations of webid to emerge and a network effect to get going. Being too restrictive early on for the sake of security, that people have trouble understanding is not going to enable adoption.

By the same token, this has to be balanced by usefulness, surely? If there are lots of WebIDs out there but they have limited usefulness, then that's not necessarily a great result if you could have lots of WebIDs out there which are more useful by being a little more restrictive and making efforts to mitigate those restrictions?

Here's a concrete example of why I'm concerned about this:

I use the EasyWebID Facebook application to generate the FOAF document for my WebID, because some of my friends did the same thing. It produces FOAF automatically based upon data it has access to in Facebook, along with a list of public keys I supply of WebID certificates.

I log into a bunch of sites using WebID certificates. These sites don't care deeply about the public keys that I use, because to do so would be annoying: as far as they're concerned, my user ID is http://apps.facebook.com/easywebid/nevali#person and I authenticate by providing a certificate with that URI in the SAN and checking that the FOAF document has a matching public key entry. If my login was my certificate's public key, then I'd only be able to log in from devices/browsers which included that particular certificate, which is both annoying and risky (I have to transfer pkcs#12 bundles about, increasing chances of compromising security on the private keys, and everything becomes reliant me not losing that key…).

Somebody later gains access to my Facebook account, and adds their own certificate's public key to my FOAF document. Now, they can log in to everything I've used my WebID for previously, impersonating me.

One could say “well, the EasyWebID Facebook application should take steps to prevent this from happening”, but there's every chance they won't; we can't rely on users being able to differentiate between a provider who is good at security and one who isn't if we can't rely on users knowing how and why private keys work and how to protect them…

So, lending more weight to the IDs of the key in the client certificate isn't an option because it massively reduces the utility of WebID as a proposition, and similarly increases chances of lost identity. But relying on the subject URI means that if somebody gains access to the place where the WebID is published, everything I've ever used WebID to log into is now accessible as well, so that's not viable either.

Thus, the solution must be something which isn't either of these two things…

M.

-- 
Mo McRoberts - Data Analyst - Digital Public Space,
Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
Room 7066, BBC Television Centre, London W12 7RJ,
0141 422 6036 (Internal: 01-26036) - PGP key 0x663E2B4A




http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
					
Received on Friday, 8 April 2011 12:30:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:23 UTC