Links

Ben Laurie blathering

29 Oct 2008

Yahoo, Caja, OpenSocial

Filed under: Caja,Capabilities,Open Source,Programming,Security — Ben @ 13:01

I’m very excited that Yahoo! have launched their gadget platforms, including an OpenSocial platform. Why am I excited? Because Yahoo! require all gadgets to use Caja so that they can be sure the gadgets behave themselves without review. Caja allows the container (i.e. Yahoo!’s platform, in this case) to completely confine the untrusted Javascript (i.e. the gadget, in this case), only allowing it to perform “safe” operations. All other platforms either have to manually review gadgets or take the risk that the gadgets will do something evil to their users.

27 Oct 2008

J-PAKE Again

Filed under: Open Source,Security — Ben @ 15:15

When I wrote last week that I had implemented a J-PAKE demo someone rather churlishly commented, “not a demo till it runs on two machines, with a toy browser and toy server”.

So, this weekend I implemented J-PAKE as a proper OpenSSL module. Plus support in s_server and s_client. You can test it like this:

openssl s_server -jpake secret
openssl s_client -jpake secret

If you want to use two different machines, as required by Mr. Churlish, then you’ll need to use the -connect option to s_client.

If you want to use it yourself, you can find example code in apps/apps.c. Look for the functions jpake_client_auth() and jpake_server_auth().

24 Oct 2008

WTF Does Open Source Have To Do With Business Models?

Filed under: Open Source,Rants — Ben @ 14:52

Unless you are Red Hat, the answer is: about as much as eating lunch has to do with business models.

Whatever business you are in, you need your lunch, or you’re going to die. Likewise, but perhaps not quite so urgently, you need software. Open source is about getting the software you want for the minimum investment. It is cheaper and more efficient for those who need particular functionality to group together and provide it for themselves than it is to pay five different companies to not quite provide it in five different ways.

That’s all there is. End of.

So, when you read something like this: “Report: Pure Open Source No Longer a Viable Business Model”, what you are supposed to do is hit the keyboard violently and scream, “It never was, you morons! Get with the program!”

Selling support for software is a business model. Whether it is open source or not. That’s the business Red Hat is in. Not the “open source business”. There isn’t one.

19 Oct 2008

J-PAKE in C

Filed under: Crypto,Open Source,Programming,Security — Ben @ 19:12

Just for fun, I wrote a demo implementation of J-PAKE in C, using OpenSSL for the crypto, of course. I’ve pushed it into the OpenSSL CVS tree; you can find it in demos/jpake. For your convenience, there’s also a copy here.

I’ve tried to write the code so the data structures reflect the way a real implementation would work, so there’s a structure representing what each end of the connection knows (JPakeUser), one for the zero-knowledge proofs (JPakeZKP) and one for each step of the protocol (JPakeStep1 and JPakeStep2). Normally there should be a third step, where each end proves knowledge of the shared key (for example, by Alice sending Bob H(H(K)) and Bob sending Alice H(K)), since differing secrets do not break any of the earlier steps, but because both ends are in the same code I just compare the resulting keys.

The code also implements the protocol steps in a modular way, except that communications happen by magic. This will get cleaned up when I implement J-PAKE as a proper OpenSSL library component.

The cryptographic implementation differs from the Java demo (which I used for inspiration) in a few ways. I think only one of them really matters: the calculation of the hash for the Schnorr signature used in the zero-knowledge proofs – the Java implementation simply concatenates a byte representation of the various parameters. This is a security flaw, as it can be subjected to a “moving goalposts” attack. That is, the attacker could use parameters that gave the same byte representation, but with different boundaries between the parameters. I avoid this attack by including a length before each parameter. Note that I do not claim this attack is feasible, but why gamble? It worked on PGP, after all.

The code and data structures are completely different, though. Also, because of the cryptographic difference, the two implementations would not interoperate.

15 Oct 2008

Federated Login Usability Studies

Filed under: Identity Management — Ben @ 15:14

Over the last few weeks, both Google and Yahoo! have released federated login usability studies.

Google’s proposes a flow very similar to login on Amazon, only changing “I’m a new customer” to “Help me log in” and “Do you have a foo.com account?” to “Do you have a foo.com password?”. Amazingly, this is enough for users to get themselves logged in without any training.

An interesting data point, though: users found their second login more confusing than the first. This is because they are used to having a password after the first login, whereas with a federated login, the experience is the same every time. Fortunately, although they’re not quite sure what’s going on, what they do ends up with them logged in anyway. My feeling is that if we start doing federated login widely this confusion will soon evaporate.

Yahoo!, on the other hand, focused on OpenID. This seems to have been a much less happy experience for users, which certainly comes as no surprise to me – it’s always been clear that the average user is not going to understand the idea of logging in with a URL. Plus, they’re damned unwieldy (i.e. big and hard to remember). So, their conclusion was one that doesn’t scale well: use per-IdP buttons.

This backs up my view that OpenID will never really work until it uses email addresses as user IDs.

Where Did Ben Go?

Filed under: Where I'm At — Ben @ 13:31

I don’t normally post about my circumstances, but since I’ve been pretty silent for quite a while now, I’ll make an exception. I broke my wrist 5 weeks ago, which has significantly constrained my computer use. Things should gradually return to normal…

Powered by WordPress