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

Re: WebID security picture

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 8 Apr 2011 15:34:18 +0200
Cc: WebID XG <public-xg-webid@w3.org>
Message-Id: <B41C509B-8321-4E2D-9A97-B85A64625D76@bblfish.net>
To: Mo McRoberts <Mo.McRoberts@bbc.co.uk>

On 8 Apr 2011, at 14:30, Mo McRoberts wrote:

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

What use is it if some parts of the document are signed, but all the rest is something that could be changed by the "unreliable host"? That host after all could just not serve the profile at all. Or it could add lots of links to porno images, or just be constantly lying about you, or worse lie about you on a few occasions.

I think it is much simpler: if you don't trust the host, don't publish there. Don't give your WebID to people with a URL of a host you don't trust. It will be very bad for your reputation.

>> 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?

Your mobile phone is always on pretty much. 

If one looks ahead a bit, can one imagine a world of ipv-6 enabled, where your devices always have the same ip address? I am not sure how that works for mobile devices. Otherwise one could have dynamic dns. I Again the simple solution is to have a pretty stable host. Most people have a home, and that is a good place to put one. It is protected by very strong laws.

>> 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?

You don't mean usefulness, you mean quality of data, right? And you mean that data quality will be bad because people will put their information on unreliable hosting servers? But those hosting servers have an identity and a reputation to watch out for also. 

This sounds to me very much like the critique that people would have put up against Tim Berners Lee when he started the web in the early 1990s: "Would it not be better to have data that is controlled by high quality institutions, regulated by law, than a free flowing web of pages that anyone can put up on unreliable hosts? That data will surely be so bad as to damage the reputation of the web. Would it not be better to make the protocol more complex by making sure that pages only point to resources that exist, and that those resoures point back...."

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

Ok, though any such service will have to speak to the FB lawyers, and be very careful about what they do.

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

yes. It is easier to deal with WebIDs. They can be linked to in documents most of all.

> Somebody later gains access to my Facebook account,

you mean the EasyWebID 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.

Indeed. There is the same issue with Facebook connect, and that relies on a password currently, though they are introducing https now too. I only use https. 
> One could say “well, the EasyWebID Facebook application should take steps to prevent this from happening”, but there's every chance they won't;

Do you think Facebook will watch by things like this happening without taking any steps, when their whole strategy depends on exactly what you are proposing? Because of course if EasyWebID Facebook, is just 1 step away from being Facebook itself. So there is at least one very large provider that could adopt this, and of course many other little ones, say IBM, Oracle, Apple, and all the members of this consortium. And why would there be a problem with individuals getting a plug and play Freedom Box?


> 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…

one user by himself can't, but groups of thousands of users can. This is how our society functions. It is built on trust and reputation. 

You don't just get a WebID anonymously, you get it from meeting someone, or through friends, acquaintances, colleagues, etc... 

> 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,

It massively reduces it compared to some ideal of security you are thinking about. But turn things around, and look at how far it brings us from where we are now with centralised social networks, unencrypted e-mail, servers with only http (and open to man in the middle at every level),....

> and similarly increases chances of lost identity.

It increases it compared to some ideal of security you have and which you are comparing this against.

The real world is different. Recently my mother's GMail account was taken over. She had a bad password and could not understand the issue with security. Now she does. 

We found out about the problem because the pirate changed the password and locked my mother out, but also because he sent a mail out that everyone knew clearly could not have come from my mother. We got the account back through the social network made of e-mail history Google keeps.

To move to public key cryptography identity would already be such a big improvement that it will remove the biggest security holes that exist in the internet infrastructure now, while making life for people easier - no user name password to remember anymore. 

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

But of course you won't have only 1 webid. You could have many: your private freedombox one, your university, your company, your bank, the state (to fill in taxes). You can link them or not as you wish. Different instuations carry different weight, and they will have different security thresholds. They will guarantee different information too.

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

WebID is only the beginning of the solution. It's the smallest step to something much bigger, because one has to start somewhere.


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

Social Web Architect
Received on Friday, 8 April 2011 13:34:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:43 UTC