It Is A Mystery…

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?

So I’ve finally got a chance to return to working on TAAC, an access control mechanism for the web that integrates FOAF-based identification with access control rules. I’ve been doing some more thorough testing on the slow-down issues explained two posts back, and found that the slowdown, while significant, appears to be about 13 seconds or so, on average, on this server, a Linode virtual private server which I expect typifies an average web host (if not better than average).

Several attempts at profiling (aside from creating significantly increased processing times, up to 10x longer) led to the conclusion that, in fact, most of that time is spent in the second phase (post-authentication, during reasoning), which is where I’d EXPECT the slowdown to be. Granted, this now becomes a problem that can be solved in part by Moore’s Law, but even so, some speedups would be nice to allow it to be implemented today. I plan on running the same code on a relatively modern test server that’s dedicated to doing more or less supporting these tests, so it will likely run faster on there.

It’s worth considering that this is running on a variant of the cwm reasoner on top of a re-implemented Rete reasoner, and, seeing how it’s all in interpreted Python, rewriting it in compiled C code (or even Java) would probably see a significant speed-boost, but that’s not a terribly productive line of work (except where trying to actually push out a commercial product). It might also be worth exploring other reasoning approaches to improve the speed.

Even so, I’m going to try looking at the other authentication approaches to see what the benefits and costs of them are… I think the more RESTful approach without OpenID may have some arguments in favor of it, but I doubt they’re going to be based solely on speed.

I call it Big Project 1 because it was the first big project idea I had. For those of you in the know, Big Project 1 is the weather program (Big Project 2 is something entirely different, but still a program).

In any case, Big Project 1 has finally restarted after about 6 months of downtime. I finally perfected searching, so it actually only takes about 3-5 seconds to search for a city online, and set it as your default city. It now also has a Find City feature that automatically recenters on another city and updates the location data.

There are still a number of concerns however:

1. Searches are still not text-friendly. i.e. “Albuquerque” will return useful results. “Albuquerque, NM” not only will not, but will not even filter the “Albuquerque” results for New Mexico. This, thankfully, can be tweaked outside of the source code for the program.
2. More than two searches and certain weather data won’t be loaded. This may be a side-effect of the fact that I’m not yet using my cached weather data. Next step is to tune the format of the weather data I’m currently caching, so that I can not only send and receive more useful data besides current conditions, but also so that I can carry the burden and not have issues with FTP timeouts/numbers of sessions (which could be causing the current problem)
3. I’ve got to find sources of information for most of the useful bits (e.g. forecasts and history), especially for non-American sources, and then feed it into my custom format.
4. Some of my graphics are a bit concerning. I’ve got to not only design them, but… Well, if I detail THOSE OTHER issues here, it might be giving too much away… Suffice to say though, good 3D and imaging algorithms would be a big boon… *stares at Sarah*

But at least some distinct positive progress is being made on Big Project 1. Big Project 2 (started last month) is on hold while I refocus on Big Project 1, but rest assured that it’s standing pretty well as well. It’s already got most, if not all, of the kinks in the tagging done, but now it needs a bit of database work with SQLite, and then, lastly, the GUI design… But it’ll probably be done quicker than Big Project 1, were I focused on it.

Meanwhile, smaller projects like Ierukana’s redux are also on hold, but will likely be so for a lengthier period of time. (Nevermind that it’s serving as a test ground to learn Rails anyway).

That’s all for what I’m doing computer-wise for now… Other projects might come along that are more work-related and school-related, but we’ll just have to wait and see.