Making sense of the National Strategy for Trusted Identities in Cyberspace (Part III: What's bad about passwords?)

| Comments (0) | COMSEC
If everyone loved passwords, then we wouldn't be having an extended discussion about how to get rid of them (incidentally, I was at IIW this week, where the suckiness of passwords is a basic assumption.) So, what's there not to like?

Replayability
The biggest problem with passwords as currently deployed is that they are replayable: in order for Alice to authenticate to her bank, she must provide her bank with her password. The unfortunate consequence of that is that once Alice has authenticated to her bank, then the bank can impersonate her in the future. This doesn't sound so bad, since it's not that useful for the bank to impersonate me to itself, but it has two very bad implications:

  • Phishing: If some attacker can convince me that they are my bank, and I give them my password, then they can impersonate me indefinitely, including to my bank. This sort of fraud is a huge issue for banks.
  • Unsafe Password Reuse: I'm not (overly) worried about my bank impersonating me to itself, but if I use the same password with two banks, then evil bank A might impersonate me to good bank B. More generally, any time I use the same password at two different sites, then I have to worry about whether I trust both those sites. This is what motivates the advice people usually get to use a different password at each site.

It turns out that there are technical mechanisms for alleviating these issues. The basic principle is to arrange that the merchant never gets to see a replayable password. The technology is complicated and there are a bunch of different mechanisms, but the basic idea is that when Alice establishes her account she gives the site some numeric verifier (V). Then when she comes back, she types her password into her browser which can then prove to the server that she knows V without ever giving the server a copy of V. PwdHash is one example of such a system, as are PAKE-based systems.

Password Proliferation
As Constant observes, it's probably not necessary to worry about Slashdot stealing your password and using it to impersonate you to Kayak, but even people without a lot of commercial relationships tend to have fair number of accounts that they probably don't treat interchangeably. This is particularly difficult when those accounts span a spectrum of security. Consider the following accounts ranked somewhat in increasing order of sensitivity:

  • Slashdot
  • Twitter
  • Gmail
  • Amazon
  • Bank of America
  • Morgan Stanley

I think there is a pretty fair argument that each of these represents a distinct level of security. I don't much care whether people post as me on Slashdot, but I probably do as Twitter. Unlike Twitter, I have actual private information on Gmail but there's actual money involved at Amazon but less than one the table for my bank account, and perhaps less than what I have for my investment portfolio at Morgan Stanley (Note: these providers do not necessarily represent my actual accounts.) Since these exist at different levels of security, they should have different passwords. Moreover, at the highest levels, I most likely want the use different credentials for each site. The end result of this is that I need to have (and likely remember, see below) a whole pile of passwords. This is not something that people like.

Backward Compatibility
Although we know how to build password-based systems that don't reveal the user's password to the relying party, we don't really know how to deploy them securely. The basic problem is that users are already prepared to type their passwords into Web forms that give the password to the server. It's not at all clear how to construct a UI that the user can be sure is safe and thus can type their password into and that also can't be imitated by a malicious Web site. [Technical note: it's easy to build UI that can't be imitated precisely, but the test is whether users will be fooled by bad imitations.] (More about this issue be found here.)

Low Entropy Space
A well-known problem with passwords is that they generally have a very low entropy level, which is to say that your average user draws their password from a relatively small number of passwords. This means, that if I have some oracle which will tell me whether a given candidate password is valid (e.g., a list of encrypted passwords, a server which I can try to log into, etc.) it doesn't take as many attempts as one would like to try the most probable candidate passwords. This is generally called dictionary attack.

The low entropy of the passwords isn't actually quite as bad as it sounds: even though users generally choose terrible passwords, in order to check a candidate password you generally need to try to log into the site in question, which affords the site the ability to do velocity checks and/or limited-try capabilities, such as locking your account after some fixed number of login failures. However, even then you need to use a password with a certain minimum level of security; if I use "ekr" as my username, then this is going to be a lot of attacker's first guess, so I need to get far enough up the entropy curve to make this kind of attack infeasible. That said, low entropy passwords significantly weaken the guarantees of using password diversification technologies like PwdHash, since it's comparatively easy for an attacker who has a verifier to extract the original password.

Unmemorability
This brings us back to the memorability problem. Every new password is something else to remember, and (loosely) the higher the entropy of the passwords, the harder they are to remember.In the limit, if I have a randomly generated password for each site, I'm pretty much going to need some password manager to remember them (either that or a big pile of of post-it notes).1

One-to-Oneness
Aside from the drawbacks listed above, passwords are inherently a 1-1 mechanism. If I have relationships with five different banks, I need to have established a password—even if it's the same one—with each of them. This sort of entry barrier is a pain for users, but especially for new sites, which have trouble converting visitors to users because they first need to drive them through an annoying registration experience. So, passwords don't really permit any notion of delegating trust to someone else. This is also true in the inverse sense, where I can't easily give you permission to look at my bank balance without giving you permission to make funds transfers, at least not without the bank going to a lot of effort.

A related concern is that passwords don't really have any mechanism for establishing stuff about users outside the system. For instance, when I want to sign up for a credit card, the issuer really wants to know that it's me, but the best they can do is use the (not-really) secrecy of my social security number, address, etc. as a weak password. Once I've signed up with them, a password may be fine, but it's not a useful entry point into the relationship. Similar arguments apply for proving that I'm over 21 or that I live in a given state.

Next Up: What kind of architecture is NSTIC contemplating?
Hopefully the above gives you a sense of the sort of concerns that are motivating something like NSTIC. While formally NSTIC is written as a set of requirements, to my eyes it's more like one of those documents whose authors start with a given solution in mind and write the requirements around that. In the next post in this series I'll try to talk a little bit about that implicit architecture.

1. Some people use a sort of lame mental hash function to generate related but distinct passwords for each site, but this seems to involve a fair amount of mental overhead.

Leave a comment