Strange love for passwords

Or, How I learned to stop worrying and love the card

Frank Hayes is right, sort of. Passwords are a hassle.  They're an expensive authenticator prone to loss or disclosure, perhaps not the most effective way to ensure confidentiality of data or to limit access, and their effectiveness diminishes with age.  Some other options such as SecureID tokens are architecturally clumsy and even more expensive to maintain, and effective biometrics are still single-purpose affairs intended to open data center doors or access local laptop data. There's got to be a better way, and I think I know what direction the path leads.

Dongles? Wrong

I can see the appeal of USB security dongles.  As Frank puts it, they involve "no special readers, no biometric jiggery-pokery, no flashing numbers for users to copy from a pocket token," or other user-unfriendly aspects. Plug it in, an authentication conversation happens between the dongle and the system, and then you're good, right?

Not so fast. The first problem is that you have to plug something in.  A USB security dongle is most likely a modified version of the usual parasitic flash memory that many consumer operating systems treat as a trusted controller and storage device.  Even if the device is customized (but not so much it needs a special driver) to present a limited feature set so that it's not instantly infected with whatever variety of malware is resident on the host, it's still electrically connected and logically dependent on the host for proper operation.  

Then there are issues of host malfunctions, broken contacts and electrical shorts. USB is a convenient and common form factor, but it's no milspec connector.  The designers of any car ignition would have a chuckle at the notion of future communicators hurriedly jamming a USB dongle into a jack -- on a heavy ring with a dozen keys, keyfinder fob, bottle opener and the latest iteration of Beanie Baby -- tens of thousands of times on a descendent of the humble public payphone. ATM or credit card slots seem to be the only thing that can take the kind of abuse many consumers dish out (more on that later).

The other big gotcha -- an extension of the first concern -- is the notion of using an untrusted computer system to conduct one's business. Am I safer plugging a dongle into a terminal in the scrutinized environs of my city's airport than into the hotel internet terminal during DefCon? Probably, but if I did the either on a regular basis, the contents of my device would surely be copied and scrutinized sooner rather than later.

If my authentication certificate and private keys are stored on that dongle, then I'm not much better off than if I'd typed an important password into a waiting keylogger. If my dongle runs a protected authentication process that's dependent on but hidden from a host driver when it's plugged in, it's probably a security hazard to the host.

Identity is not assurance

Even further, a security dongle or token ought not take care of the whole process for me. I still have to have interaction in addition to just possession of a dongle or token, or I've muddled the idea of identification and authentication. A security device, physical token, biometric or even a password by itself is only an identifier.

A little light was shed on the issue some years ago, by a European airline looking for a solution that would allow their crews all over the world to access flight scheduling data.  Had they been looking for feedback or any sort of control process that directly affected health and safety (i.e. assigning people to crews or rerouting flights) I might have been more uptight about any use of untrusted systems, but at the time, they just wanted to push information out to authenticated users.  The major use case was a flight attendant walking up to an internet kiosk at any airport, and the catch was he could neither plug anything in nor leave any data on the system.

Passwords were a weak option, if only because of the need to change them after using an untrusted system. Biometrics were immediately ruled out because few if any of the terminals in question would have the necessary scanning hardware. One-time password generators, including those using a time-based algorithm such as SecureID and CryptoCard, had some appeal, but were hampered by expense and parallelism to existing authentication systems.

Then we took a step back and looked at those systems. What caught my eye was that the airline, like many EU businesses, had already begun to use smart cards in their corporate environment for such things as certificate-based VPN access.  The idea of using a third party service such as beTRUSTed (now part of Cybertrust) to store and manage certificates through a web interface was briefly entertained, but when the rubber hits the road, using a password to remotely access one's keys or certificate is no better than using a password alone. 

No, if a solution was going to be based on something stronger than a password, it would have to remain directly in each individual person's control. How does one bridge the gap between strong certificate-based authentication, and the limitation of a human's fingertips as the only interface with a system? 

Reading is fundamental

It turns out that almost 10 years ago, a few vendors had already thought through similar use cases.  Spyrus and Vasco both had (and still have) portable smart-card readers that seem to suit the bill.  For example, Spyrus' Personal Access Reader 2 is a smart-card sleeve barely thicker than a couple of cards itself, with a keypad and display.  More importantly, it contains a second smart-card processor and memory.

Similarly, some of Vasco's Digipass portable smart-card readers offer active processes that run on the reader itself.  Building on the idea behind RSA's SecureID, it's easy to imagine an authentication conversation that combines a smart-card certificate with time- or sequence-based challenge-response program that runs not on a host system or the card, but on the portable reader. A person could walk up to a kiosk, navigate to a Web site that presents an authentication challenge, enter the challenge into the portable reader, and give the response back to the Web site as a certificate-based one-time password.

Sure, it feels the same as using any other token, but there are some important differences. Since this is certificate-based, it can use the same back-end directory as other network and system authentication models such as logging into a VPN or authenticating to a Windows domain. It also opens up a whole new set of technical possibilities.  That fingerprint scanner on my laptop could show up in the next version of the PAR2, obviating the need for a PIN number -- the last vestige of a password in this scenario.

All of this appeals to my overblown sense of technical elegance, but the history of IT is littered with the carcasses of clever ideas that didn't have enough force behind them. What's going to drive this?  It certainly isn't IT budgets or the collective will of thousands of stymied corporate information security officers. If you're in the EU, you only have to look in your wallet for the answer. 

Credit card compulsion

It's Visa. Together with MasterCard and EuroPay, Visa crammed certificate-bearing smart cards into the hands of the EU populace by mandating that acquiring banks eat authentication-based credit card losses unless they switched to smart cards by January of last year. The issue is laid out in the EMV smart-card specifications (PDF format ), and it won't be long before the U.S. market is pushed in the same direction.  That portable credit card machine they bring out to your Parisian bistro table anymore?  It's running pretty much the same thing as the Spyrus or Vasco card reader with a network connection and a receipt printer. Your card does the identifying, and your fingers do the authenticating.

(Think there's a problem using someone else's reader? Espenschied thinks Visa should consider the risk. -- Eds.)

If you had your own reader, you could safely execute the same financial transaction, or potentially any other kind of transaction, at a kiosk or over the phone.  They've already thought of that too.  Visa’s Dynamic Passcode Authentication (DPA) and MasterCard's Chip Authentication Protocol (CAP) (PDF format) allow smart cards to be used for identification and authentication in transactions where the card can’t be presented (analogous to not being able to plug in your security dongle).

When a smart card is inserted into a portable card reader running a DPA or CAP application, the application responds to a transaction challenge by generating a one-time time-sensitive response password for that transaction. This gives the cardholder control over the transaction, and the assurance of two-factor authentication to the vendor or acquiring bank.

There's no reason this can't be applied to all manner of non-financial authentication and access processes. It might be a while before I log into the corporate network by sliding my credit card into a CardBus or ExpressCard Smart-card reader, but the infrastructure and process is going to be pushed upon us in daily consumer life.  Several airlines currently use credit cards for simple identification, and the German government is already pondering (PDF format) CAP for "machine-readable travel documents."

Now, I'm not going to speculate too far into the future, to a time when Visa displaces the DMV or passport agency as issuer of authoritative international credentials for every kind of identification and authentication. However, there are no other entities that have Visa and MasterCard's topical ubiquity and influence.  They've picked their technology, and if it isn't in your hands now, it will be soon. It might not fit corporate authentication or private transaction use cases perfectly, but as noted in RFC 1925, "given enough thrust, pigs fly just fine."

Jon Espenschied has been at play in the security industry for enough years to become enthusiastic, blasé, cynical, jaded, content and enthusiastic again. He is currently a senior security consultant in Seattle, where his advice has been ignored by CEOs, auditors and sysadmins alike.

Copyright © 2007 IDG Communications, Inc.

  
Shop Tech Products at Amazon