Two-Factor Authentication, Hashing, and Cell Phones Restrictions / J2ME

I’ve been interested in two-factorauthentication on the cheap as a technique to improve systemssecurity for some time. My interest is primarily in making thistechnology available for marginal cost, with limited scale-outfees. This is a task that should be easy given thewidespread availability of powerful mobile computation devices –namely cellphones with J2ME — and the ease of adding secondaryauthentication to most platforms (e.g. GINA authentication inpre-Vista, and Credential Providers in Vista and similar options onother environments. Adding two-factor authentication to a webapplication is a breeze).

Two-factor authentication, for those who haven’t come across itbefore, is the addition of a secondary identity “proof” aboveand beyond the normal one-factor password. The purpose being tolimit risk when user passwords are surreptitiously gained bynefarious agents, which could happen due to keyboardsniffers (a simple USB interceptor at the back of the target’s PCcould log weeks worth of keystrokes), trojans, use of public orcompromised computers, password reuse or selection weakness, and soon.

Passwords aloneare a really weak technique for system security.

The most well-known implementation of two-factorauthentication are RSA SecurIDhardware tokens — or similes —  usually built aslittle keychain units that display a frequently changing,time-based access number (unique per token, so the centralsystem needs to know which key went to which user). To log ontosecured systems, such as banks and corporate VPNs, theuser needs to enter not only their normal password, but also thecode displayed at that moment on their token. So usersally logs on with her password 5gromet4u and herauthenticator token is displaying the value 10492838, soshe enters that in the pertinent login box. On the server theauthentication service validates her password, and that the tokenthat she was assigned should be what was provided (on the serverside it’s usually generous, allowing the authenticator token for afew 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 needand make it a colossal pain to deploy and manage. Thisis irritating because the core technology behind such systemsis absurdly simple — hash the current date (truncated to a certainlevel of precision — say every minute) together with a privatevalue on the hardware token and convert to a BASE10 value to acertain number of digits (e.g. the first 8 digits of the BASE10encoded hash). On the server end it knows the private valueassociated with each hardware token, and can perform the sameprocess, so if the time is synchronized on both ends the hashvalues match.

e.g. here’s my 3 minute C# version of a minute-granularitytoken generating method.

private string GetTokenValue(string userSpecificPrivateKey, inttokenLength)
    System.Security.Cryptography.SHA1Managed hash =new System.Security.Cryptography.SHA1Managed();
    byte[] hashValue = hash.ComputeHash((newUTF8Encoding()).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”);

So if I’ve been assigned the secret, user-specific valueof AF8CAD55JK9 (a value that was securelycommunicated and configured, or burned directly, into the tokendevice and of course configured on the server, but then neverspoken aloud or communicated again), then at 1:00 pm UTC onDecember 28th, 2006, the method will return the token5864947577 for a token length of 10 digits.

Cell Phone

So here we’re all walking around with incredibly powerfulcellphones featuring massive amounts of memory and computationpower — I still marvel to think that my cell phone has doublethe memory of my pimped-out 4MB Atari ST circa 1998 (which itselfwas 8x the stock memory), and features many, many magnitudes morecomputational power. At the time that Atari ST seemed infinitelycapable — and most cell phones promise tremendous flexibilityand ease of expansion with the universal runtime of J2ME.

Surely to make such a token application for our cell phonesshould be enormously trivial. I’ve built GINA modulesbefore, so that element is relatively trivial as well, and isonly getting easier with Vista/Longhorn (Dear Microsoft – Where’smy 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 andthen the pertinent MotorolaSDK (all while deciphering a ridiculous array of oftenconflicting acronyms, and the version soup that is the Java world).All in all it was a remarkably simple and easy route todeveloping mobile applications, though I was a bit perplexed that Ieven needed a device specific SDK (I thought J2ME was sort ofuniversal, beyond the basics like screen size/color support),meaning that widespread deployment would probably be far moredifficult, with hundreds of possible builds being necessary.

Implementing the above into a J2ME application, displaying thecurrent token value (changing every minute), along with some simpleconfiguration options, was absurdly easy, despite Java not being askill of mine. The slick little emulator worked wonderfully anddisplayed what the application would actually look like if it wererunning on my class of phone.

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

Considering the enormous size of the market, it isn’tsurprizing.

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

The cell phone industry is a travesty. I went through this exactsame exercise years ago, again giving up in disgust at all of thebarriers that the cell phone industry in cahoots with the wirelessproviders put in one’s way — basically they do their damndest tolimit the flexibility of the devices they provide (even though Ibought this phone, and it is legally mine…not reallysure how a provider has any right to put any constraints or lockson it. Of course I have the same thing with the Motorola PVR that Ibought from my cable provider, again with various features andfunctions disabled by the cable company), trying to ensure thatyou’re forced to do everything through their cost bloated network,buying from their grossly overpriced online stores, and applicationdeployment has to happen through a system that ensures that theyget a tremendous take even if their participation is entirelyunnecessary.

To get this application on my phone I’d have to resort to astack of basically warez-like software (from shadysources, spoken of in hushed voices) to circumvent all of theridiculous constraints.

Once again I’m giving up at making the phone I carry around moreuseful. Maybe I’ll look at one of those Windows Mobile phones (comeon Microsoft! Where’s my Acer Ferrari 5000!), which presumablyoffer more user control and flexibility.