SecurID work-alikes in Open Source?

Slashdot posted to Banks Begin To Use RSA Keys
as Open source securid-like tokens:

Tracy Reed writes:

Around 5 years ago I was looking for a way to have a secure-id sort of solution without having to buy the proprietary software and hardware without any success.

The first "open" standard for authentication tokens was part of ANSI X9.9, and was broken (and subsequently retracted) back in 1999. The old X9.9 algorithm is still available as an optional authentication method in several hardware tokens offered by competitors of RSA/SecurID.

Have you looked at GNU SASL (Simple Authentication and Security Layer framework)?

I even looked into building my own (I know a little about microcontrollers for the hardware device portion) but was not able to come up with any suitable algorithm. It seems like the security of our Linux systems and other systems which require authentication could really benefit from something like this.

An open source implementation of the SecurID time-based authentication algorithm is not possible because RSA holds several patents covering their whole time-based authentication scheme.

The closest solution in the open-source world might be OPIE (formerly S/Key). OpenBSD and other operating systems include S/Key support in the base OS.

There are OPIE calculators for MD4/MD5 in Java and for most handhelds, but it is tough to find a SHA-1 or RMD-160 implemention, and I have yet to run across any dedicated hardware device that does nothing but handle OPIE authentication.

With the uncertainty about SHA-1, You might plan to implement only RMD-160 (160 bit Ripe Message Digest). Tokens would need a bit more CPU power to handle a few hundred rounds, but at least there is a good chance that RMD will still be a viable hash, long after SHA-1 falls.

Fille writes:

Seems to me that you can easily store a list of passwords and challenges on a small device with an lcd-screen. Since OPIE passwords do not depend on the time or date, you can just use a list, no? You just have to renew it after some time (e.g. 100 logins) but that's not a major problem.

I guess the idea has always been that the token device always just stores your seed value XOR'd with your PIN, so somebody who walks off with your token doesn't have access to any useful stored data. Storing pre-calculated respinses goes against this concept.

Another interesting alternative would be for the token to have a one-level look-ahead cache. After you use a tokencode, the device pre-calculates the next response code and stores it encrypted against your PIN, then goes to sleep.

This cuts down on the risk and exposure, requires less storage memory, and gives faster startup time than if the response is only calculated at the moment you need it.