The cry of the squeamish ossifrage

I think I got rid of the old Scientific American issue years ago, but I still remember reading about the RSA public key cipher in Martin Gardiner's Mathematical Games in 1977 (August, to be precise).  Thirty-three years later, RSA is still in use, providing a secure means of encrypting and signing digital data (unless someone has figured out a way to crack it and is sitting very, very tightly on the secret).

In particular, it can be used to verify that only someone in possession of a particular secret key, generally a several-hundred digit number, could have produced a particular block of bytes.  If you visited a site whose URL started with "https://", for example your bank, your browser most likely used RSA in the process of satisfying itself that it really was talking to the right server.

So why is authentication such a mess?  Why does resetting a password require anything from coming up with the name of a cat to providing a working email address to providing several pieces of information and then getting a phone call?  Why do some sites want the three-digit code on the back of your card and some not, and how is adding three more digits that you end up handing out to all and sundry helping the situation?  Why hasn't OpenID or some other knight in shining armor been able to rescue us?  Why do we still use passwords for anything besides locally decrypting the key to a real authentication system?  How do you even know I wrote this?

I don't really know, but if I didn't have some guesses I probably wouldn't be writing this, now would I?

First, what would a really seamless authentication system look like?

• It would allow for multiple identities.  Maybe I just haven't caught on to the whole every-waking-moment-of-your-life-available-online thing, but I would rather keep my work identity separate from my blogging identity separate from my personal email separate from my bank accounts.  Not to mention my identity as an international man of mystery.
• It would allow the same identity to work multiple places.  This is not the same as giving N different sites the same username and password.  Your username doesn't belong to you, whereas a real identity does.  Anybody can choose your favorite username if they happen to get there first.  It's also not the same as letting your browser keep track of a bunch of username-password pairs and putting a master password on all of them.
• It would minimize the number of tokens needed for an identity, and each token would be there for a clear reason.  If the token is a password, fine, but it should be a password, not a password and two or three "security questions."
• It would use current best practices.  It's risky to use anything too new when it comes to security technology, and unless you're No Such Agency or the like it's madness to try to create your own, but there are plenty of well-established road-tested security techniques available.
• It should be portable, both physically (like the "pocket-thing") and across sites.  Ideally, registering with a new site means registering the token(s) for the appropriate identity.
• It should be as completely under the identified individual's control as possible.

What actually happens?  Something along these lines, I think:

Suppose I have some sort of digital certificate that I can use to identify myself.  Properly used, this could satisfy the requirements above, perhaps together with some sort of physical token, like a smartcard.  Any really secure authentication system, including a smartcard, is going to have some such certificate in it somewhere.

Since it costs money to have a major certificate authority (CA) vouch for a certificate (by signing it), certificates used by individuals in practice tend to be "self-signed", or signed by members of a "web of trust" instead.   That's fine for some purposes, but not for doing business with a bank.  If it's not good enough for the banks, it's probably not good enough for your utility company either.

In theory, you could establish your identity with a bank and then get them to sign a certificate to that effect, which your utility company might choose to trust, but that basically puts your bank into the CA business, not one they're necessarily keen to get into.  In practice, each company would rather control the process, typically asking for an account number off a paper statement to get the ball rolling.  Each entity has its own customer ID system for the account number, and usernames are potluck, so you end up with (at least) one semi-identity for each company you do business with.

In the wild-and-woolly world of pure web sites, where you don't already have a customer id when you sign up, there doesn't seem to be any strong push to move beyond the usual username-password system. Everyone's used to it.   Switching would mean re-doing the login screen, at the least, with new and less-familiar technology, then convincing your users to go along with it.  If it ain't broke don't fix it.

Since an authentication scheme is only as strong as its reset mechanism, there are basically two schemes in wide use:

• An identity is a working email address
• An identity is a couple of "security questions" and answers

If I had to choose, I'd take the former, but it's not much of a choice.