It's probably easiest to get a sense of what the problem is by looking at deficiencies in the existing password-type systems on the Web. As you all know, what happens now is that you go to some site—which, if you're lucky, uses HTTPS— and it gives you a form (i.e., text fields on the page) to enter your username and password. This user interface is completely under control of the Web site, and to a first order just looks like any other Web form to the browser1 You type that stuff in, hit return or click on the submit button, and the browser sends the username and password to the server, which verifies them and either lets you log in or not. [Technical note: each page you fetch/link you click on a site is sort of an independent transaction. The site uses web cookies to string the transactions to gether so you don't have to type your username/password on each page.] There's plenty to hate here, but before we talk about that, it's worth talking about the stuff that's good.
Portability
From the user's perspective one of the most important properties is
portability. Say I buy a new machine or I want to use a kiosk somewhere:
as long as I remember my password (this is a lot easier if I use
the password monkey10
everywhere than if I generate
a random 16-character password for each site), then I just sit down,
type it in, and I'm good to go. Even if I have a really long password,
I can write it down on a piece of paper which will survive the
failure of any particular device.
This sounds simple, but it's actually
a feature that many of the proposed fixes for this problem don't
have. To give you just one example, pretty much all the systems
that involve you having a long-term client-side public key then
require some way to haul that key around. There have been a lot
of proposed answers to this (USB tokens, smartphones, etc.) but
none of them have come close to taking off.
Backward Compatibility
Say you've just invented a really good remote authentication technique. What
now? Well, if it involves modifying the client, then you've got a real
problem since Web browsers turn over comparatively slowly (10% of the
net is still running IE 6). So, even if you
manage to convince all the browser manufacturers to put your system
in, you're looking at years before you can count on everyone being
able to authenticate with it, and hence before you can use it exclusively.
Similar reasoning applies when you need to modify the server, since
any new mechanism on the client is useless without server support.
The only lowest common denominator mechanism is passwords through
Web forms, which is why so many new authentication systems have
been structured as enhancements to that basic mechanism, either
on the server side (e.g., if you don't recognize this image,
don't proceed) or on the client side (e.g., PwdHash) so that
they can be deployed unilaterally.
Site Control of Look and Feel
Passwords in web forms aren't the only authentication mechanism
that was intended when the Web was first designed. Indeed, HTTP
supports not one but two password-based authentication mechanisms,
"Basic" (i.e., passwords in the clear in the HTTP header) and
"Digest" (i.e., challenge response in the HTTP header). Neither of
these sees much usage, most likely due to the hideous user
interface they typically have, which involves the browser
bringing up a modal or semi-modal dialog as you first go to
the page (generally before you see anything on the page). It turns
out that this is not what site operators want, which is instead
to control the UI experience, including offering you first-time
registration without an annoying dialog box, password recovery,
branding, etc. In other words, they want to brand it, and aren't
really interested in authentication mechanisms which don't offer
that ability.
Next Up: What's bad about passwords?
While passwords have some useful features, if they were really
great then we wouldn't be having this discussion. Next, I'll
talk about some of the obvious drawbacks, but as you're reading
that you should remember that while annoying none of them have been severe
enough to push us over the edge into actually discarding passwords
for most applications.
1. The exception here is that there is a special indicator that tells the browser that the password field should display dots or stars or whatever instead of your real password.
If this is what's good, I can't wait for your "what's bad" article.
I agree with your portability comment, and would also point out that user experience with passwords is an important advantage for non-sophisticated users. It's also important not to disenfranchise users whose only internet access is at a library or café and depend on portability.
While a lot of stakeholders are concerned about higher levels of assurance for critical infrastructure and health care applications, we also need to be concerned about transaction friction that occurs if an inappropriately-high (and harder to use) authentication is used for low value transactions. If I'm buying a song online for 99 cents and that requires me to go to another room where I left my token, perhaps I'll decide instead that I don't need that song after all. Facilitating low-value transactions is important because of their volume, and fortunately the Strategy addresses that need in several places.