Steve’s Blog

Just another compsci weblog


Recently, a SecurID came under my acquisition. For those unfamiliar, SecurID is a small device that fits on any key chain and displays a six digit number that changes once per minute. The six digit number it displays is based on a seed number that is created when the device is deployed and known only by the device (hopefully) and the party deploying the technology. The deploying party then keeps a big database of each person’s user name, SecurID serial number, SecurID seed number, and SecurID pin, which can be modified via an 800 number. When you want to authenticate to certain services, you provide your pin number, followed by the currently displayed six digit number on the SecurID. The authenticating party then uses the seed to calculate the number that should be on the SecurID at that time and compares it to the PIN and SecurID number you submit.

By doing this you are (theoretically) proving to the authenticating party that you are who you claim to be with two factors of authentication: something you know (your PIN) and something you have (your SecurID). This makes it more secure than only a single factor of authentication, such as a password. Since the SecurID is physical, a hacker would need to steal or tamper with the device to beat the additional authentication method.

In this case, however, the line between something you have and something you know is, in my opinion, a bit blurry. Because the device holds some information that makes it unique – it’s random seed – one could extract this information from the device where it can be emulated in software. Fortunately for SecurID, it’s never connected to a computer, ensuring that an attacker must have physical access to bypass this security measure. (There is however, the issue of the seed being stored in the authenticating server, which is a potential target of attack)

But once an attacker does get physical access, there is little stopping him, in my opinion, from fraudulently authenticating himself. Let’s say, for example, that an attacker acquires another user’s SecurID and username. If the deploying party requires a four digit PIN then there are 10,000 possible codes that can be entered. Lets assume that the deploying party has only allowed one incorrect login per generation cycle. This means that to brute force the PIN number, the maximum amount of time it would take is 10,000 minutes. 10,000 minutes * 1 hour / 60 minutes = 166.7 hours. 166.7 hours * 1 day / 24 hours = 6.94 days. Which means that at most you would need to wait for a week to successfully brute force a SecurID login, assuming you have the device and username with a one minute code generation interval on the device.

But what if I have to enter a six digit PIN? That’s 1,000,000 possible combinations. 1,000,000 minutes * 1 hour / 60 minutes = 16,666.7 hours. 16,666.7 * 1 day / 24 hours = 694.4 days. Hmm, that’s much better. However, the longer you make the required PIN, the harder time the average user is going to have trying to remember it. It’s also been shown that people remember words better than remember a string of numbers, which is why I think SecurID should use passwords rather than a PIN. However, the more characters that need to be entered during authentication, the more time an average user needs to input this information, so there’s a balance that needs to be achieved. Four digit PINs are good because it’s the same size as a bank PIN, and similar brute force deterrent mechanisms can be used, such as disabling login after n failed attempts.

It’s not that I think SecurID is a bad technology; quite the opposite. Instead, I think that ‘something you have’ is almost invariably ‘something you know’ (whether you know it, or the device does, it’s somewhere). This also goes for the third factor of authentication, which is ‘something you are’. What is a thumb print but information? (And something you are is immutable – if someone makes a copy of your thumb print and masquerades as you, what are you going to do? Get a new thumb print?)

That said, I think SecurID is a great technology with a slim chance of being exploited. RSA did a good job of making it unable to be connected to a computer, which eliminates the possibility of being able to remotely discover the device’s seed number.


3 Comments so far

  1. Amal Graafstra August 21st, 2008 10:39 am

    Very interesting post. I totally agree with the “something you know” really being the only real factor. Perhaps it should be changed to “Something Known”. Even the tumblers of a lock “know” the ridges of its key.

  2. Matthew Tom-Wolverton October 3rd, 2008 9:08 am

    Interesting post! When you calculated that it would take about 7 days to try all the possible 4-digit PINs, though you’re forgetting two important things…

    1. In a typical setup, the auth. servers probably have something in place to protect against brute force attacks like the one you mentioned.
    2. If someone were to lose their secureID, it’s typically reported soon after (before the 7 days) and a new one is deployed, making the old one invalid. Though I guess this could be circumvented by obtaining the seed and ‘copying’ the secureID via software emulation…

  3. Anonymous October 26th, 2009 10:17 am

    by default RSA servers are configured to disable token after 10 bad authentication…

Leave a reply