Letters of introduction

As part of my never-ending quest to catch up on things I ought to know already (right up there on the list with reading all the great works that I've never gotten around to reading), I did a little brushing up on single sign-on schemes.

The basic idea of single sign-on is simple and good: I don't want to have to type a username/password all the time, and I don't want to have to keep track of which password I used for which account. The second item is particularly bad, since even though there are ways to let people have passwords without storing the passwords themselves, not everyone seems to know how to do it (the techniques are only a few decades old after all). So that means either keeping track of lots of passwords, or using a few and running the risk that one insecure site gets compromised.

(Logging in by sending a password to a server is kind of bogus anyway. Stronger schemes use passwords only to locally unlock the secrets of some sort of strong crypto which then handles the real authentication. There are also smart cards and similar which use strong crypto to generate a secret with a limited lifetime, tying a login, assuming the crypto works, to a physical object and a point in time.)

So, how does a single sign-on service work? Basically such a service depends on a way for some other system to vouch for you to the system that you're trying to log in to:

• You log in once with a particular server
• That server gives you (or your browser) a token (or cookie, or ticket, or whatever you like). That token effectively says "so-and-so was able to present me with such-and-such credentials -- generally a username and password but possibly something more substantial -- at such and such time"
• You (or your browser) show that token to the system you're trying to log in to.
• That token has enough crypto mojo in it to allow the system you're logging into to verify that it really came from some party it trusts, that it hasn't been tampered with, etc.
• Assuming that the identification in the token matches a known account, you can now be logged in.

There are variations. For example, in OpenID, you give the server you're trying to log in to a URL representing your identity. That server chases the link and finds out who's vouching for you. It then checks with that party. Typically that party will ask you to log in to it and make sure that you trust the server that asked it to do that. The two servers then securely agree, effectively, that yes you did log in.

The young Charles Darwin carried with him on the voyage of the Beagle letters of introduction, as was common practice in those days. By presenting the appropriate letter, he was able to obtain lodging, safe passage and other such benefits. The letters were signed by people the benefactors knew and trusted and let them know that Darwin was also someone to be trusted. The signature a was crucial part of ensuring that the message really came from whom it said it did; people paid more attention to signatures then than we typically do now.

Is there a connection between this fading and quaintly antiquated practice and modern digital technology? Well, they don't call it a digital signature for nothing ...