Blog post

Just What Happened to SecurID?

By Mark Diodati | March 18, 2011 | 6 Comments

As I write this, RSA has announced it experienced an attack on its RSA SecurID one-time password (OTP) products. You can see Art Coviello’s letter to RSA’s customers here. The letter is very light on the nature of the attacks and what was stolen. In the interest of full disclosure, I worked at RSA for six years until 2003.

RSA SecurID leverages a symmetric key algorithm to generate one-time passwords. The device stores the symmetric key (in SecurID speak – the “seed”) and passes it through the time-based algorithm. Voila: the passcode appears on the screen. The passcode is concatenated with the user’s static PIN (think ATM card PIN) to build the one-time password.

There are two items in the SecurID secret sauce: the algorithm and the seed. From a cryptography 101 perspective, algorithms should be public and keys should be private. Nevertheless, the SecurID algorithm is ostensibly “private”. We should not consider this algorithm secret and it is distributed more broadly than you would expect.

So the security of the SecurID system quite rightly rests with the seeds. When RSA ships OTP devices to its customers, it also ships a seed file, which contains all of the symmetric keys associated with the OTP devices in the order. The seed file is sent for both hardware- and software-based devices, and is loaded into the Authentication Manager. As an aside, many SecurID customers don’t protect these seeds adequately.

Let’s conjecture about the attack might look like. If the algorithm was stolen, RSA may not be happy about it, but I think the hoof prints are already visible outside the barn door. If any customer seed records were stolen (or the ability to create them based upon the device serial number), this is a significant attack that directly compromises customer SecurID deployments.

If the seeds have been stolen, one might argue that the user’s PIN will save the day; not so. First, the PIN is a weak password. Second, not all OTP devices have PINs. Devices that have not been distributed yet don’t have a PIN. Deployed tokens that will be redistributed to new users will have their PIN reset.

Now, we wait and learn more about the attack.

Recommended reading (subscription required):

Authentication Decision Point

Road Map: Replacing Passwords with OTP Authentication

Strong Authentication: Increased Options, but Interoperability and Mobility Challenges Remain

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • Jacob Gajek says:

    The algorithm RSA uses to generate the tokencodes is widely known: It is the AES-128 block cipher in EBC mode.

    This smells like the seed records database was breached. Especially since RSA executives have been telling customers to protect the serial numbers on their tokens.

  • Good points. And I do believe your post, plus all of the other dialogue that has occurred and will continue on the subject will eventually reveal:

    The whole concept of unilateral, 1-sided (client only) authentication is outdated and out-matched by internet attackers. Sure, publication of the algorithm and/or seed records will help hackers produce the proper token code. But this level of crypto-sophistication has never been necessary – all the SecurID attacker needs is to insert himself, as a man-in-the-middle, for a replay attack on the current token code.

    And for this matter – let’s not pick on the RSA SecureID tokens.

    All tokens, hard and soft are susceptible to this attack. As are , Username/Password solutions, as are the “match the picture” solutions, as are the GRID solutions and so are the biometric that rely solely on digitizing client input.

    Bottom Line: The internet calls for bilateral authentication for secure client/server validation.

    Hopefully Gartner’s spotlight, with others, will encourage this needed dialogue.

    Garret Grajek
    CTO and a Founder of SecureAuth

  • Mark Diodati says:

    Hi Jacob,

    Well done and thanks for replying to the blog! I forgot about the transition to the AES algorithm. My colleague at CA and RSA Merritt Maxim (Twitter: merrittmaxim) gently reminded me of this, too. So thanks to you both!

    The public nature of AES IMHO reinforces the blog’s assertion that the real risk is associated with the breach of the symmetric keys (AKA seeds). Your assertion about the breach is very possible, too. Hopefully we’ll get more details about the attack.

    Thanks Again!


  • Proposed Man in the middle attacks on SecurID have been around for decades

    I cannot recall all the specifics but I recall the ACE Server had some pretty interesting crypto tricks to guard against MITM as this was a common customer objection/question.

    What is interesting to me is to watch all the analysis on this hack, yet reports of millions of SSNs or credit card #s (which I argue have more immediate value) gets little press.


  • If the seed database was hacked, I would not only be astonished but would consider it outright negligent if RSA being a security company did not make use of HSM based technologies.

  • David White says:

    They use netHSMs. Private key is split up between the HSM and the server. Recapitulating is doable.