As I’ve been working on TAAC, I’ve started to become concerned about potential weaknesses with any FOAF-based identity authentication system (be it RDFAuth, OpenID, or FOAF+SSL) and that’s that ALL systems, with the possible exception of RDFAuth (due to its reliance on PKI), have their weakest link as the integrity of the server hosting the FOAF file. All three systems rely on data in the FOAF file to ‘authenticate’ against, but this poses problems. Take, for example, the following scenario:
Alice runs a website that accepts an OpenID+FOAF system (it works easily well with FOAF+SSL). Bob is a client of Alice, and regularly uses the authentication scheme Alice has implemented. When authenticating, he traditionally authenticates against his FOAF URI, http://www.example.com/bob.rdf#bob. The file bob.rdf has information that links to Bob’s OpenID, http://www.example.com/bob, permitting him to authenticate with his (self-run) OpenID provider.
Eve wants to see the information that Bob gets to see on Alice’s website, and thanks to some shoddy system administration, finds a security hole that allows her to get access to the filesystem. Ignoring the other private information acquired in this way, Alice silently replaces bob.rdf with her own FOAF file that has one simple change: the OpenID associated with http://www.example.com/bob.rdf#bob is now http://www.example.com/eve, which is Eve’s OpenID provider. Eve authenticates agains her own OpenID provider and gets access as Bob to Alice’s website, does her dirty work, and then quietly returns the original FOAF file so that Bob is none the wiser. There’s precious little evidence that Eve intruded, and only an alert sysadmin might note the erroneous login. Meanwhile, Alice is barely aware of any difference other than that the OpenID changed for one particular login.
In summary, as Henry Story admitted (Point 5 in the FOAF+SSL description), these methods only assert that the person accessing any protected resource has ‘write access’ to their FOAF file… But that doesn’t assert that they’re the same person.
With the common weakness of many self-hosted domains having poor security protocols, a FOAF-based Authentication System could be disastrous. The only plausible ’stopgap measure’ might be requiring the system as a whole to cache the authentication credentials (e.g. OpenID, public key URL, or X.509 hash) and refuse access to people who present credentials that have changed. This adds a layer of complication to the mix as well, as it would require out-of-band communication to ensure that the ‘cached’ credentials are removed or replaced with new credentials manually… And even so, there is still the risk of incorrect authentication credentials being presented absent any evidence they are incorrect (e.g. Eve logs in before Bob ever does, or does so in the period where Bob’s cached credentials have been deleted, establishing her credentials in place of his own). There are ways around this, but they seem a bit kludgy to me (e.g. using the old OpenID/X.509 cert, which may not exist due to security risks, to authenticate the new one; checking against a public key server to see if there’s any indication that a public key has been revoked/replaced).
Are we sure that a FOAF-based Authentication System is secure enough? At the very least, it seems like we need proactive sysadmins maintaining the system to ensure it remains secure… And can we afford that?
Well of course if you leave the keys to your house under the door mat, anyone can come in and answer your telephone calls. Clearly this is not a problem with the key, this is a problem with how people make use of the key. Similarly if you have an army to protect your country, but they don’t guard the frontier, then people can invade easily. That’s not a problem with the army, but with how they are trained. Similarly in this case. If people don’t protect their passwords giving access to their web server, then that does not say anything about the protocol, just that people are ignorant of security. This problem can’t be solved by changing the protocol therefore, but has to be changed in other ways, either by education, or by making it very difficult for people to loose their information.
You can improve the security of a web server dramatically by only allowing access via SSL, and having SSL get its key from a USB key containing an impossible to remove private key that would encrypt the communication. This costs hardly anything nowadays. If someone looses their key, they would notice it and be able to call the alarm. You can make things more secure still quite easily. It is just a matter for these services to be rolled out. Furthermore that could be the same key your browser uses to encrypt the foaf+ssl connection in that protocol.
In the case of OpenId, which is more complicated, there are more places of failure, and so more ways for things to go wrong. That is a problem for it. But you also have to see how things stand at present, with people giving out their passwords to gmail to facebook in order to export easily their social network. And as far as that goes, openid is already a big improovement.
You’re absolutely right that this is a social problem, but many individuals may be leaving the keys in the hands of some ‘trustworthy company,’ not unlike how we trust the credit card companies, merchant services, vendors, and banks to all keep the keys locked up tight so that the other four don’t end up losing money due to fraud. The problem isn’t necessarily that users aren’t secure as opposed to not necessarily having the option to BE secure for various reasons (say, LiveJournal users using their FOAF export). Furthermore, unlike the key examples, this isn’t a threat to just the client, but also to the server relying on the correct individual at the other end. If Bob has been granted wide-access on a service by a company, and his web host of choice gets hacked with a zero-day exploit, it may actually put the company at risk as much as Bob, even though Bob took proper precautions.
Granted, a private key can assist this, but the fact remains that FOAF+SSL requires the FOAF file to have the correct signature. Just because Bob uses a USB key doesn’t mean that someone can’t hack the FOAF file to point to their OWN key’s signature, so as to gain access to Bob’s account.
Find me a protocol that is not open to user stupidity? Have you ever tried to doing internet transactions? They ask you for the number on a credit card. Something the credit vendor could then just reuse and make a sale elsewhere… So my point is that in so far as your problem is real, it applies to all protocols.