Community Matters

This is a topic that I have been tossing around for a while. The fact that I gave a presentation about this at this week’s SambaXP conference in Göttingen has forced me to put some structure around my thoughts.

Single sign on is a commonly listed goal in the IT industry. You authenticate once and then have access to all kinds of applications or services via the net. This sounds good, but of course it comes at a price. The damage that can be done if your credentials are compromised increase dramatically if they can be used in many places.

A simple example. Let’s say you use your login credentials to also be able to access your email account. That’s wonderful – one less username and password to remember. But unfortunately a number of email clients (or email retrieval apps like getmail or offlineimap) have no convenient way to securely store your credentials – or are easily fooled into handing these credentials to a proxy server. Which suddenly exposes your “general pass key” to your account to an attacker.

Of course you can use SSL encryption on your email protocol (e.g., imaps) to make man in the middle attacks harder – but that only works if you have signed certificates and a correctly built and trusted CA in place with the CA certificates installed on all clients. Which gets a little harder with the proliferation of mobile clients. For example, when using your favorite email client on your Android phone (or Nokia N71, or…), who hasn’t clicked ‘accept’ when asked to verify the authenticity of an SSL certificate provided for the server that wasn’t signed with a key that’s installed in the client’s CA keychain. You may have looked at the certificate to make sure that it looked sane – but did you verify it?

That’s a huge risk when allowing authentication with typical username / password based single sign on credentials on internet-facing servers. Yet that’s a very common practice.

So what can you do? One school of thought is “just don’t do it”. Have separate credentials for all services, force distribution of CA certificates, enforce SSL or SSH as a minimum requirement to connect to any services and basically device and conquer the risk. But frankly, that makes mobile clients far less attractive, interaction with network facing applications and services more difficult and generally reduces productivity. And in the end, if users are forced to use too many distinct username / password combinations they tend to use simple algorithmic passwords (or simply write them down somewhere in clear text).

Another alternative is to look at ticket based systems like kerberos and the way they handle credentials. Kerberos (and it’s implementation in Microsoft’s Active Directory) encrypt all traffic and use a rather smart system to prevent man in the middle attacks. Assuming strong passwords (to prevent the well documented offline password guessing attacks) you can create a decent sign on system that can be used with mobile clients – assuming the client software stack includes the necessary code to authenticate against A/D – which unfortunately is not universally the case today.

Ideally for each account with a service provider you as the user would be able to pick how to authenticate – using a ticket authority of your choice – potentially with different identities between different services, potentially with the same. This way you could control which services share the same ID, ensure that all authentication is secure and at the same time make it easier to manage these identities securely in a mobile device.

Samba is a widely used open source implementation of the necessary pieces of A/D. It allows clients to authenticate against Active Directory servers or other kerberos based authentication servers and then only distribute tickets (that don’t include the actual credentials) to authenticate against services. One downside of using Samba’s model of implementing the different components of MSRPC as monolithic applications instead of APIs is that it makes it harder to use in this context (providing authentication services in the mobile world); also, Samba has gaps in its support for the full breadth of A/D (missing some of the SSPI providers).

Still, it’s a good start. An alternative could be Likewise Open as it matures. Kirshna and his team certainly are focused on a complete implementation of the necessary APIs – but the mobile client isn’t their focus area, either.

The discussion after my presentation showed some interest in the community to tackle the problem, but of course this will require the service providers and the device vendors to cooperate as well. But first more people need to understand the underlying problem that needs to be solved…