I've been interested in two-factor authentication on the cheap as a technique to improve systems security for some time. My interest is primarily in making this technology available for marginal cost, with limited scale-out fees. This is a task that should be easy given the widespread availability of powerful mobile computation devices -- namely cellphones with J2ME -- and the ease of adding secondary authentication to most platforms (e.g. GINA authentication in pre-Vista, and Credential Providers in Vista and similar options on other environments. Adding two-factor authentication to a web application is a breeze).

Two-factor authentication, for those who haven't come across it before, is the addition of a secondary identity "proof" above and beyond the normal one-factor password. The purpose being to limit risk when user passwords are surreptitiously gained by nefarious agents, which could happen due to keyboard sniffers (a simple USB interceptor at the back of the target's PC could log weeks worth of keystrokes), trojans, use of public or compromised computers, password reuse or selection weakness, and so on.

Passwords alone are a really weak technique for system security.

The most well-known implementation of two-factor authentication are RSA SecurID hardware tokens -- or similes --  usually built as little keychain units that display a frequently changing, time-based access number (unique per token, so the central system needs to know which key went to which user). To log onto secured systems, such as banks and corporate VPNs, the user needs to enter not only their normal password, but also the code displayed at that moment on their token. So user sally logs on with her password 5gromet4u and her authenticator token is displaying the value 10492838. On the server the authentication service validates her password, and that the token that she was assigned should be what was provided (on the server side it's usually generous, allowing the authenticator token for a few minutes in the past and future to accommodate minor time skews, or Sally being slow entering the values).

The cost of these simple devices is usually absurdly high, however. Worse, the service software is usually pompous, overbearing, overpriced systems that take an absurdly simple need and make it a colossal pain to deploy and manage. This is irritating because the core technology behind such systems is absurdly simple -- hash the current date (truncated to a certain level of precision -- say every minute) together with a private value on the hardware token and convert to a BASE10 value to a certain number of digits (e.g. the first 8 digits of the BASE10 encoded hash). On the server end it knows the private value associated with each hardware token, and can perform the same process, so if the time is synchronized on both ends the hash values match.

e.g. here's my 3 minute C# version of a minute-granularity token generating method.

private string GetTokenValue(string userSpecificPrivateKey, int tokenLength)
{
    System.Security.Cryptography.SHA1Managed hash = new System.Security.Cryptography.SHA1Managed();
    byte[] hashValue = hash.ComputeHash((new UTF8Encoding()).GetBytes(System.DateTime.UtcNow.ToString("yyyyMMddHHmm") + userSpecificPrivateKey));
    string hashString = String.Empty;
    for (int counter = 0; counter < (tokenLength>>1) && counter < hashValue.Length; counter++)
    {
        hashString += ((hashValue[counter] / 256.0) * 100.0).ToString("00");
    }
    return hashString.Substring(0,tokenLength);
}

So if I've been assigned the secret, user-specific value of AF8CAD55JK9 (a value that was securely communicated and configured, or burned directly, into the token device and of course configured on the server, but then never spoken aloud or communicated again), then at 1:00 pm UTC on December 28th, 2006, the method will return the token 5864947577 for a token length of 10 digits.

So here we're all walking around with incredibly powerful cellphones featuring massive amounts of memory and computation power -- I still marvel to think that my cell phone has double the memory of my pimped-out 4MB Atari ST circa 1998 (which itself was 8x the stock memory), and features many, many magnitudes more computational power. At the time that Atari ST seemed infinitely capable -- and most cell phones promise tremendous flexibility and ease of expansion with the universal runtime of J2ME.

Surely to make such a token application for our cell phones should be enormously trivial. I've built GINA modules before, so that element is relatively trivial as well, and is only getting easier with Vista/Longhorn (Dear Microsoft - Where's my free Ferrari 5000 laptop for this Vista mention?)

So over the holidays I wanted a bit of a change from the norm, so I grabbed the NetBeans IDE and the mobility pack and then the pertinent Motorola SDK (all while deciphering a ridiculous array of often conflicting acronyms, and the version soup that is the Java world). All in all it was a remarkably simple and easy route to developing mobile applications, though I was a bit perplexed that I even needed a device specific SDK (I thought J2ME was sort of universal, beyond the basics like screen size/color support), meaning that widespread deployment would probably be far more difficult, with hundreds of possible builds being necessary.

Implementing the above into a J2ME application, displaying the current token value (changing every minute), along with some simple configuration options, was absurdly easy, despite Java not being a skill of mine. The slick little emulator worked wonderfully and displayed what the application would actually look like if it were running on my class of phone.

All in all the free J2ME development ecosystem has improved significantly since my last (abandoned) effort in this space, with some very slick tools and technologies.

Considering the enormous size of the market, it isn't surprizing.

Then I tried to deploy it to my cell phone. What a nightmare: Despite bluetooth and USB connectivity -- theoretically -- it was a complete no go.

The cell phone industry is a travesty. I went through this exact same exercise years ago, again giving up in disgust at all of the barriers that the cell phone industry in cahoots with the wireless providers put in one's way -- basically they do their damndest to limit the flexibility of the devices they provide (even though I bought this phone, and it is legally mine...not really sure how a provider has any right to put any constraints or locks on it. Of course I have the same thing with the Motorola PVR that I bought from my cable provider, again with various features and functions disabled by the cable company), trying to ensure that you're forced to do everything through their cost bloated network, buying from their grossly overpriced online stores, and application deployment has to happen through a system that ensures that they get a tremendous take even if their participation is entirely unnecessary.

To get this application on my phone I'd have to resort to a stack of basically warez-like software (from shady sources, spoken of in hushed voices) to circumvent all of the ridiculous constraints.

Once again I'm giving up at making the phone I carry around more useful. Maybe I'll look at one of those Windows Mobile phones (come on Microsoft! Where's my Acer Ferrari 5000!), which presumably offer more user control and flexibility.