Gartner Blog Network

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

Additional Resources

View Free, Relevant Gartner Research

Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.

Read Free Gartner Research


Mark Diodati
Research VP
12 years at Gartner
27 years IT industry

Mark Diodati is a Research Vice President with Gartner's IT Professionals research and advisory service. His focus topics include IoT, IaaS, authentication, hybrid and cloud identity, and API identity service (e.g., OAuth, OpenID Connect and SCIM).Read Full Bio

Thoughts on Just What Happened to SecurID?

  1. 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.

  2. 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

  3. 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!


  4. 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.


  5. 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.

  6. David White says:

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

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.