Sunday, March 28, 2010

A better mousetrap password

Thoughts on what a "good" password replacement should include:

Convenience: For a replacement to be as convenient as a password, I should be able to login to a service even if I forget my keys, wallet, badge, or  PC. If I'm using a friend's laptop while at a coffee shop, logging in should not depend on a cert stored on any media, or installation of any proprietary software.
Security: This is the classic weakness of passwords.  My password shouldn't be exposed even if someone shoulder-surfs me, intercepts my packets, steals my cookie, or has pwn'd the machine I'm using to login.
Ephemeral: The nature of a password is that I can replace it easily, but I might forget it. A great password replacement shouldn't be as fragile as a password I can forget, but should still allow me to perform a useful operation in case I believe my account has been compromised.

In the realm of authentication, it's common to discuss multi-factor authentication, wherein proof of identity involves more than one of the following:
  • Something I know
  • Something I have
  • Something I am
The classic example is the ATM card: withdrawing money from an ATM involves the card (something I have) and the PIN (something I know).

From a convenience point of view, "Something I have" seems to be disqualified.  If I have to have something, but I don't have it with me, then I can't login.  There's the edge case of an implant - but getting one doesn't necessarily qualify as convenient.  Furthermore, an implant arguably blurs the line between "something I have" into "something I am".

Classic passwords are "Something I know" - which leads to both the benefits and problems.  If it's something that can be guessed by someone else, it's not secure - it becomes something that other people know.  However, if the password requirements are stringent, it's likely that I'll forget it - in which case, it's not really something I know.

The third classic factor for authentication, "something I am", is generally viewed as synonymous with biometrics.  The current cost/benefit of biometrics is generally regarded as insufficient - either it's not good enough, or too expensive.  Furthermore, once the biometric information is read, it becomes a pattern of bits, which is effectively a static authentication token. (Malicious software on the PC I use can store my fingerprint / face / retina / etc and pretend to be me.)

My view right now is that the best currently-available solution is the common  physical token which provides a dynamic authentication each time.  Costs are coming down: Blizzard sells these for World of Warcraft for $6.

The second best solution would likely be a system which generated an auth token in response to a login-time challenge.  However, the method of generation is still questionable: if one of the inputs to the generator is a password (e.g. S/KEY or OPIE), then the security of this solution is still reduced to that of passwords.

However, both of these methods seems to require a physical device - which conflicts with the requirement for convenience.

Any suggestions from the field?

2 comments:

  1. Great post. Agreed on the premise that those are the 3 areas to consider. I feel a Venn Diagram in my future!

    But in terms of what we believe is "convenient," it is absolutely relative. We think an implant wouldn't be convenient, but what about an earring? A large percent of the population wouldn't think this was too cumbersome. The idea that we are burdened by keeping an object in our possession is completely disproved by cell phones. Nobody thinks it's a flaw that you have to hold the cell phone to use it, and it can ring at any moment so it must be 'on you' at all times. The cell phone companies have dictated to the user what the expectations are for use, and we accept. Needs to be the same with auth. I'd love to see Google offer a token. They have a value vs. convenience ratio that rivals cell phones, and I think they would be successful.

    ReplyDelete
  2. Jim:

    I don't think the security of a challenge-response system is reduced to that of a password. It's reduced to the security of the key or private seed used to create the challenge and security of the password. If both of these are on a compromised device, then you're in trouble.

    I think running a software token on a wireless device gives you a great deal of protection against keystroke-loggers on PCs. I also think that PC tokens combined with some form of NAC are a good solution.

    While I like your triad, I also tend to break down what you're trying to protect, so I look at session authentication, mutual host/ssl authentication and transaction authentication to protect against stolen creds, MiTM attacks and MiTB attacks respectively.

    ReplyDelete