Two-factor authentication using a hardware token

We ran into a friend a while back who was logging into her employer’s Virtual Private Network on the weekend. She caught our attention by whipping out her keys and typing in some information from a key-fob. It turns out that her work uses an additional layer of protection for logging into the network. They have implemented a username, pin number, as well as a hardware token system called SecurID.

The hardware consists of a key-fob with an LCD screen on it. A code is displayed on the screen and changes frequently, usually every 60 seconds. The device is generating keys based on a 128-bit encryption seed. When this number is fed to a server that has a copy of that seed, it is used as an additional verification to the other login data.

This seems like a tech trickle-down of the code generating device from GoldenEye. It does get us thinking: with the problems free email services have been having with account theft, why aren’t they offering a fee-based service that includes a security fob? With the right pricing structure this could be a nice stream of income for the provider. We’re also wondering if this can be implemented with a microcontroller and used in our home network. As always, leave comments below and let us know if you’ve already built your own system using these principles.

Update: Thanks to Andre for his comment that tells us this type of security is available for Apache servers. The distribution includes a server side authentication system and a Java based token generator that can run on any handheld that supports Java.

These things have been around for forever. An alternative to building one in hardware would be to create an iPhone/Blackberry/Pre app that does the same thing. The app would be initialized securely from within the employer’s network, then function the same way as this keyfob does. I’d be willing to bet that something like this exists already. If not, there’s your million-dollar idea.

When logging into your online banking in the UK (and no doubt other countries) you need to insert your card into a portable card reader, enter your PIN and then type the resulting code shown on its LCD into a field on the login page.

>This seems like a tech trickle-down of the code generating device from GoldenEye.

Um, right…

SecurID has been around for about 20 years… about 5 years older than GoldenEye… I tried to get an exact date, but the patents were filed starting in ’85 and the RSA site says “20-year history of outstanding performance and innovation”.

While the type of code generation may have changed over time, I was using an lcd key fob to log into a remote machine back in 1999 (and even then I suspect it wasn’t a new technique). The biggest annoyance was that the code changed every 15 seconds, and as the remote machine was slow to respond it would usually take 3 to 5 attempts to get in during the small window.

I like your idea. Hell, if Google offered one for their auth that cost $20 then I’d buy it right now.

Ideally tho you’d need a way of using the same unit for multiple services, otherwise you’d have a pocket full of fobs :/

The issue with an IPhone/Blackberry app is that they aren’t secure. If it just runs on the phone the device would lose sync for the server and if it is connected it is an insecure connection that would not improve security. The only thing it does is require you to link the phone to the user, but given you can log into the bank page from the phone, that shouldn’t be too hard.

These really only work for places where you need the extra security and can respond with tech support(like replacing the fob) in a timely manner. Forcing SSL and stronger rotating passwords should be enough to secure an email account for the general public.

As mentioned before, blizzard ha been using these thingies for WoW accounts for a while. However they do actualy have an app for the iPhone that does the exact same thing, it doesn’t run all the time, and you can use it when your not connected to the Internet. It just works, and it’s frigging awesome.

The key part of this is that it is a separate hardware device. The viewed key is derived from the internal key, but figuring out the internal key from the viewed key is very, very, VERY difficult, and thus the ‘next’ displayed key is assumed to be safe and secret until it is needed for use. If this were implemented on a phone in software, it would be trivial to read out the internal key and render the system insecure. You’d have to add a proprietary hardware module to the phone in order for it to work.
Yes, it might be possible to read the internal key from the keyfob by prying it apart with sufficient care, but I’d assume there were safeguards against this (keeping everything ‘secret’ on one piece of silicon, requiring continuous power to keep the memory of the internal key alive, etc).

I don’t see why an iphone/blackberry app would make it any less secure. As the above poster said, it would need to be initialized (get the seed) while connected securely within the network. Afterwards, it doesn’t need to connect at all, just generate an ID based off that seed.

At worst, an attacker would still have a password and username to put in, nothing lost.

Blizzard does this for World of Warcraft already. There has been no verified instances of a WoW account being hijacked when an authenticator (as Blizzard calls it) was present and active on the account.

SecurID, originally made by Security Dynamics before RSA bought it, was around several years before GoldenEye. They’re NOT new.

The problem with SecurID apps is that the seed file, in combination with the serial number, is all that’s needed to clone the system. The ACE/Server needs these two pieces of information, which are provided on removable media with the tokens as an file called nnnnnnnn.asc (where n* is the serial number stamped on the token) probably ascii-armored, uuencoded or base64 version of a raw binary seed.

If you can get the .asc file, you know the serial number (the filename) and you have the seed (the contents of said file), and you can then run it through any of a number of freely available tools, such as this beauty: http://seclists.org/bugtraq/2000/Dec/459 which will spit out the next few numbers that will show up on the screen.

If the seed file is stored in any kind of decode-able format and it can be harvested from your phone/pda/whatever, it is most certainly less secure than the hardware. You can’t get the seed off the hardware tokens. With hardware tokens, the seed exists only on the media that shipped with the fobs (hopefully locked away or destroyed) and on the authentication server. That is more secure.

Cannot beleive this is the first you’ve seen these, they’ve been around for ages. I know there are websites out there with free services offering these as an extra layer of security, E-Trade I beleive is one of them. And I do know I’ve seen smartphone apps to replace these types of keys.

I have one of these keyfobs for my office network VPN connection. It is a random number generating device that has the same algorithm as the VPN concentrator. What happens is that when using the RSA algorithm, you have some ciphertext (c), message (m), and a few other numbers, p, q, n, e, and d. p and q are both large primes and n is the product of these two primes (n = p*q). You then chose some e > 1 that is coprime to the totient of p and q, which can be expressed as phi(p,q) = (p-1)*(q-1). Then GCD[e,(p-1)*(q-1)] = 1. Next we compute d, the multiplicative inverse of e mod phi(p,q), which can be expressed as the congruence de = 1 (mod phi(p,q)). Now we have our public key, n & e, and our private key, n & d. We now compute c = m^e (mod n) and m = c^d (mod n). See wikipedia for a good example.

There is an issue with this however, in that if the same m is sent to e or more different people and those people share the same e value, then it’s easy to solve for n by using the Chinese Remainder theorem.

This is where the keyfob comes in, I suspect. RSA does not tell people exactly how these work, and for very good reason. It is probably a padding mechanism for the original m value. When entering your username/password you create a new key pair, and you have to enter the number on the keyfob to tell your end what pad to use, in addition to using it to verify in a third way that the user is authentic.

This might seem like a great idea for an iPhone app, but the iPhone app would need to be reseeded every time it started and that seed would need to be given to the endpoint somehow. Also the keyfobs are decently physically secure as well, but nothing is perfect in that respect – even the moon can be opened up and analyzed (as NASA has recently shown us).

Actually there is a way to securely implement this on the phone, as most phones ( GSM at least ) have already hardware security module installed – it’s called SIM card. Newest generation of SIM cards actually can allow for another application to co-exist, so it can be used as smartcard and or such one-time-password ( OTP ) generation.

As far as DIY goes… it’s all matter of crypto-hash algorithm ( available ), hard to get secret key ( so.. epoxy over the circuit board, disabled debugging, etc ) and the most-important one – to ensure that the clock on the damn thing is very reliable. The same goes for the clock on the server. AFAIK the drift of the build-in clocks in microcontrollers is not enough over the lifetime of such hardware token ( 3-5 years ) so special external module with better accuracy.

Singu: There are options on the authentication server to allow for clock drift. In fact, I believe that it’s capable of not only accepting the next- and previous-key in the sequence, but if you are consistently entering a key behind its normal window, it will adjust for a time offset on a per-token basis. Say I’m always entering the number that it thinks should be NEXT (not the one it thinks should be currently displayed), it will actually adjust my keyfob’s timetable in the system. The Auth server is always synchronized with NTP, so it’s rarely off global time by more than a few seconds.

agrajag9: The algorithm has been reverse engineered (see the link in my above post) and it’s easy to implement, even though RSA never told anyone how it works.

Also, if a phone/PDA application can access and otherwise decode the seed file, it doesn’t matter where or how it’s stored, it’s vulnerable.

I’ve had the Paypal dongle for about five years now.
Friend that worked as a Admin for Merril Lynch had one that looked like a credit card. He had this about 10 years ago.
Nothing new. Wonder why this technology is not available for the small business/home user yet..

I manage a SecurID server at my job. The value of “two-factor” authentication is that there are, well..um, two factors. Something you know (the pin) and something you have (the key fob). If there were an app, it’d be trivial for someone/trojan/malware to obtain the seed. Then you’re back to one factor authentication — like a password, something you know. If an attacker has the technical ability to obtain the seed out of the app, it’d be nothing for them to obtain the pin & username.

With the SecurID fob, you can trust that there is only ONE copy of the ‘seed’.

Sure they could make an app, but that defeats the two-factor security model.

My company is using these devices and I have one allowing me to connect through VPN. I think it’s a great additional security as the network I can connect to is international and contains several companies. I ave 60 seconds to log in and today this is far enough for the speed of the servers.

everyone in my office/company has one of these for vpn access and for loggin into secure sites within the intranet. (largest telecom company in canada). userid is text over 6 chars, personal code of 4 digits + 6 digit code from the fob. the number changes avery 60 seconds, and is very random. not sure of the cost, but the admin geek that used to be here a few years ago mentioned itwas upwards of 100$ t the company per fob – i’m guessing he was throwing me a line of crap though. they do die if you open them though, and batteries only last about 5 years.

Hmm, RSA is proprietary & hacked, you can do the same using the OATH algorithm which is more secure and is public (RFC4226), also see http://www.openauthentication.org. Works fine, easy to implement, dozens of vendors offering OATH-compliant tokens… RSA is pretty much a thing of the past, just lives on because of the large install base…

This type of solutions have been around for ages, my father used more advanced challenge/response devices than this RSA token in the 80’s to authenticate to his corporate network!

A recent article on online banking points out that this is merely one more layer that can be compromised as easily as the other layers, as long as the user or bank is running Win-don’ts. Since you’re hauling around a fob anyway, why not make it a USB stick with a livecd Linux distro? That way, your bank account, email, and various private files are incapable of running any .exe files and you’re therefore virus- and malware-free.

I used to use one of these a fair amount. The reason you don’t see them more is because they are a PITA from a usability perspective. The pointy-haired-one will be calling _you_ when he looses it. I have heard stories of people playing ‘RSA Key Poker’ with the values, though…

I’m surprised no-one has made an open version of this. Imagine being able to have a keyfob that you can use for almost any site.

All that is needed is a device like this with a microcontroller and a public/private key setup. The code is generated using the private key you set up and verified with the public key that any website can get (either from you or from a central server). The code change every minute with the time used as the cleartext.

I always thought the RSA fobs or software tokens should be called 3 factor authentication as a 4 digit pin is required in the code as well. The pin can be similar between all users or in my case i always issued dissimilar pin’s for more security.

We’ve been using a RSA secure card with similar generated numbers at work for years to place orders with our manufacturer. (copier / printer supplier) Adding a additional layer of security like this is the only thing I can think of that brings credit/debit card security up to an acceptable level.

Also – weather the seed is stored in software or in hardware it is stored in the device somewhere and thus will be targeted for extraction.

I’ve been using a OTP device called a Yubikey. This is a hardware device the size of a small USB drive and it emulates a keyboard. So instead of reading a number off an LCD screen, you touch a button and it types the OTP in for you. The company that makes it is hoping to make money off of selling the hardware device itself and is open sourcing the back-end software infrastructure needed for the hardware device. I was able to 2-factor authentication enable my website by adding just a few lines of code to the website’s existing authentication programming. You can read more about the Yubikey at the Yubico homepage: http://www.yubico.com