Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Security IT

Researchers Can Generate RSA SecurID Random Numbers Flawlessly 98

Fluffeh writes "A researcher has found and published a way to tune into an RSA SecurID Token. Once a few easy steps are followed, anyone can generate the exact numbers shown on the token. The method relies on finding the seed that is used to generate the numbers in a way that seems random. Once it is known, it can be used to generate the exact numbers displayed on the targeted Token. The technique, described on Thursday by a senior security analyst at a firm called SensePost, has important implications for the safekeeping of the tokens. An estimated 40 million people use these to access confidential data belonging to government agencies, military contractors, and corporations. Scrutiny of the widely used two-factor authentication system has grown since last year, when RSA revealed that intruders on its networks stole sensitive SecurID information that could be used to reduce its security. Defense contractor Lockheed Martin later confirmed that a separate attack on its systems was aided by the theft of the RSA data."
This discussion has been archived. No new comments can be posted.

Researchers Can Generate RSA SecurID Random Numbers Flawlessly

Comments Filter:
  • Not exactly... (Score:5, Informative)

    by Anonymous Coward on Tuesday May 22, 2012 @02:16PM (#40078859)

    "When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token," Fouladi wrote.

    Good job leaving the word software out of the summary there in the /. lead in.

    • Re:Not exactly... (Score:5, Insightful)

      by Fwipp ( 1473271 ) on Tuesday May 22, 2012 @02:30PM (#40078981)

      Exactly. They're cloning the software token, not breaking the scheme that the hardware uses.

      • Re:Not exactly... (Score:5, Informative)

        by fuzzyfuzzyfungus ( 1223518 ) on Tuesday May 22, 2012 @02:58PM (#40079279) Journal
        My understanding is that the two schemes are the same. The software version is just the cheap-n-lazy implementation for people who don't want to deal with airgapped hardware tokens.

        Honestly, what makes me nervous about this is not the fact that, shocking!, software can be reverse engineered; but that RSA seems to mix a disconcerting amount of laziness and hubris in with their competent math.

        As best we currently know, it is Not Possible to deduce subsequent token outputs merely given access to previous token outputs. However, it is trivial to do so given access to the seed value. And yet, RSA's last big security fuckup was because they weren't purging seed values for tokens sold to customers. And now it turns out that their software 'tokens' retain their seed values in local storage forever.

        Way to let a desire for convenience drag defeat from the jaws of victory, guys.
        • Re:Not exactly... (Score:5, Interesting)

          by Cramer ( 69040 ) on Tuesday May 22, 2012 @03:27PM (#40079585) Homepage

          It's my understanding of the system (from dealing with one years ago)... the server can recover the seed used by a hardware token given it's serial number, and two sequential tokens. Perhaps the serial number is the "seed" and it's figuring out the tokens clock. However, it's perfectly clear the server can generate the same numbers as the token. The strength of the system is keyed to protecting that algorithm. Soft-tokens are a bad joke and only slightly better than a password, but are themselves based on a "password".

          • by lgw ( 121541 )

            If that's true the software tokens are badly broken: their serial number is just a hash of the hostname and the User SID, both of which are easy enough to get remorety.

            • If that's true the software tokens are badly broken: their serial number is just a hash of the hostname and the User SID, both of which are easy enough to get remorety.

              Nah, I'm sure it's a keyed hash. The server can do this because it has the key.

          • Re:Not exactly... (Score:5, Informative)

            by datajack ( 17285 ) on Tuesday May 22, 2012 @06:24PM (#40081383)

            The server cannot 'recover' the seed from the serial number.

            When you buy hardware tokens, you are supplied with a copy of the seeds, associated with the token serial numbers, to import into the server. The SecurID scheme is time based. What is recovered through supplying the serial number and two token-codes (combined with the existing knowledge of the seed) is the current state of the token's internal clock.

            The serial number printed on the back of the token is NOT the seed. It is not (to the best of my knowledge and trust in RSA) related to the seed in any way other than the mapping held in the database of the server.

            This story is purely sensationalist. The SecurID algorithm has been known for a long time, that token codes can be generated when the seed is somehow compromised is a non-issue. That a software token seed can be recovered given full access to the host is also obvious to anyone reasonably aware of the realities of cryptography.

            • That a software token seed can be recovered given full access to the host is also obvious to anyone reasonably aware of the realities of cryptography.

              Shhh!! Don't let Them know that. They'll take away my Linux DVD player!!!1!

            • Add to that, even if you know the seed, you need to know the state of the clock in that token as well... not that it's hard if you have seen unencrypted token data for the token you are cloning... but as a remote attacker who only has a seed, the username and a pin and the algorythm, you still need a resonable prediction of that physical tokens clock.

              This article summary should have said SOFTWARE tokens, as this is much less impressive.

          • by Bert64 ( 520050 )

            Protecting the algorithm is pointless, it could always be reverse engineered from the server implementation which has been available for years. A program called 'cain' has had an implementation of this algorithm for quite some time.

            The strength of the system is protecting the seed values, and this is dependent not only on the customer to not leak their seeds, but also on rsa to not leak everyone's seeds.

        • by Bert64 ( 520050 )

          The algorithm has long ago been reverse engineered, i believe a program called "cain" has been able to generate token values for quite some time when given the initial seed value.

          The big flaw in this system however, is that the seed values are provided by rsa and not generated locally by the customer, so if rsa gets hacked (as they did), or employs someone who can be bribed etc, the seeds leak and the whole system is compromised.
          You as a customer are dependent on rsa, but you have no control over them, this

        • As best we currently know, it is Not Possible to deduce subsequent token outputs merely given access to previous token outputs. However, it is trivial to do so given access to the seed value. And yet, RSA's last big security fuckup was because they weren't purging seed values for tokens sold to customers. And now it turns out that their software 'tokens' retain their seed values in local storage forever.

          With the hardware tokens, there is a class of attack that is only feasible if you have the hardware token for a long time and closely monitor the numbers it produces. Every once in a while (on average, around one third of keys will experience this once a year) it will repeat a number for two lots of 90 seconds - a vanishing differential. Knowing this vanishing differential, it then becomes computationally feasible to recover the keyfob's secret key.

          This class of attack doesn't really help to break a single

      • Re:Not exactly... (Score:5, Informative)

        by chrb ( 1083577 ) on Tuesday May 22, 2012 @03:02PM (#40079329)

        They're cloning the software token, not breaking the scheme that the hardware uses.

        The algorithm that the software and hardware implement is the same. What has been done here is to show that the software mechanisms in place to protect the token file under Windows can be broken, despite the claims of RSA:

        This file can be viewed by any SQLite database browser, but sensitive information such as the checksum and seed values are encrypted. RSA documentation states that this database file is both encrypted and copy protected: “RSA SecurID Software Token for Windows uses the following data protection mechanisms to tie the token database to a specific computer:
        * Binding the database to the computer's primary hard disk drive
        * Implementing the Windows Data Protection API (DPAPI)
        These mechanisms ensure that an intruder cannot move the token database to another computer and access the tokens. Even if you disable copy protection, the database is still protected by DPAPI.”

        So if the RSA software token is installed on a Windows PC, and you can access that PC (remotely or physically), then you can copy the token; the result is the same as having cloned a person's hardware token.

        • by Sir_Sri ( 199544 )

          Well not just remotely access, you need to remotely have administrator access, or have otherwise compromised the machine.

          Which makes this a half MS and half RSA problem. If your software absolutely must run on windows, no matter how unsuitable windows is for the task, then you rely on microsoft API's and general OS features/security etc. If they don't secure their secure device API properly then there is only so much you can do, equally if they don't document how to properly use/connect to a secure device

        • the result is the same as having cloned a person's hardware token.

          Sort of the same. But the difference is very important. The difference is that any RSA customer could decide (and some have probably already decided even before this) that a software system running on a networked PC is not secure enough and decide to only use the hardware tokens, which are not susceptible to cracks like this.

          • My RSA admin declined me a Blackberry software token on basis of security so I have to carry arround this key chain that says "he must work somewhere where security is important".

    • Re: (Score:3, Insightful)

      by erroneus ( 253617 )

      The "hardware token" *IS* running software. Did you think it was not running a processor and running a program???

      And in order for that to work, it operates the same way the SOFTWARE system which validates and verifies the numbers on the RSA ID.

      The compromise is the same whether it is a hardware or software device... in the end, they are all software devices.

      • It could theoretically be a custom ASIC, in which case it's not really a processor running a program as much as a physical embodiment of the program.

      • True. For the Windows software token, you compute the "serial number" (seed) with the Windows account Security ID (SID) and the hostname of the machine the software is installed it. For the hardware token.... you look at the serial number very thoughtfully stamped into the back of the token. But in the latter case, I don't think you can transfer the serial number into another hardware SecurID, so unless you can emulate a HW token using "stolen" serial numbers, you can't clone a HW token, whereas the SW toke

      • You are absolutely correct.

        The difference, of course, is that you would need physical access to the keyfob in my pocket. Even if you managed that feat without me noticing, you'd destroy it in the process of extracting the information you need thus alerting me that something was amiss.

        • No you wouldn't. That's why the breech of RSA happened. They just needed the seed information in order to clone the output of RSA devices out there.

          RSA devices are about authentication. The authentication system is software. It must operate identically to the "hardware" devices to be useful.

          Most people get that hardware which runs software is still software. But people aren't getting that "programmable hardware" is still software too.

          • Except the magic of soft ware is that two processes can be coded to behave differently... it could have been trivial for RSA to assume a different hash salt for tokens with different serial numbers or enrollment behaviours.

  • by CubicleZombie ( 2590497 ) on Tuesday May 22, 2012 @02:17PM (#40078877)
    Now I don't have to worry about forgetting to bring home the RSA token for my company's VPN. I can just leave it under the keyboard with all my password post-its!
  • by Anonymous Coward

    This should be no surprise. The software token in a smartphone or a computer MUST have the seed stored somewhere in the device that the device can read and access.

    Which means if an attacker can control the victim's computer, of course the software-based token has no security, only obscurity and hastle.

    • by Bert64 ( 520050 )

      Even worse considering that the primary purposes such tokens are used for, is to mitigate against the damage which can be caused if a password is leaked... And one of the most common ways for passwords to leak, is via keyloggers which require privileged access to a compromised host anyway.

      So if you have the capability to run a keylogger, you have the capability to copy the software token. You only gain any benefit from the system, if you run the soft token on a physically separate device and even then its e

  • by supersat ( 639745 ) on Tuesday May 22, 2012 @02:23PM (#40078931)
    This applies to software tokens only.
  • Misleading title (Score:2, Informative)

    by Anonymous Coward

    and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.

    • by gl4ss ( 559668 )

      eh? "exploiting the windows api's"(or using windows re-configuring as intented) was done after reverse engineering what to do.
      device_serial_number=Left(SHA1(host_name+user_SID+“RSA Copyright 2008”),10).

      I mean, coming up with a good local unique identifier on most systems is hard, but in rsa's case they shouldn't even have written the dll in the first place for their scheme.

  • Isn't this old news? (Score:4, Informative)

    by noc007 ( 633443 ) on Tuesday May 22, 2012 @02:29PM (#40078975)


    If it's about figuring out the algorythm used by their SecureID fobs, this is old news. At the last job during a PCI audit, the auditor was showing off the pen test tools he downloaded for free off the net. I think it was Cain and Able had a tool that did this; as long as you knew the serial numbers on the back (a brief amount of physical access or social engineering) it would report back the six digit number the fob was displaying. Obviously you still need the other parts of the credentials, but the algorithm used by the fob was already broken.

    • by LordLimecat ( 1103839 ) on Tuesday May 22, 2012 @02:41PM (#40079097)

      The token generation algorithm uses essentially two parameters: the key fob serial number and a token activation key; each of them are usually provided by the vendor in *.XML files.

      From here [].

      Basically, they also need the seed, which is the problem being tackled here.

      • by noc007 ( 633443 )

        Ahh. Didn't know one needed the seed as well. Thanks for the info.

        /I never thought the SecureID stuff was was an awesome solution anyways.

        • by phayes ( 202222 )

          The serial number is just used to be able to determine which key has which seed. Two factor auth may not be "awesome" but it is necessary in some situations.

    • This is such old news, that RSA changed the algorithm after the original proprietary algorithm had been broken. The demonstration you saw no longer works.
      • by chill ( 34294 )

        Uh, what? No.

        The fundamentals of RSA's algorithm (RSA) are not "broken".

        Please provide links if you think otherwise. No, the various attacks listed on Wikipedia don't count.

        • The algorithm everybody is talking about is the old algorithm used in SecureID tokens before the vendor producing them bought RSA. When Security Dynamics bought RSA, they took their name as the name of the whole company, because it was such a venerated brand. After the old algorithm for the token could no longer be used, because everybody and their brother could easily generate the "unpredictable" SecureID values, they switched to AES-based approach, which has not been broken so far. RSA algorithm is a pu
  • Score a major government security contract?

    Never understood why the hell companies like Lockheed score multi billion dollar deals that they are thoroughly unsuited for.
    • by Bert64 ( 520050 )

      Because only the large incumbents are able to jump through all the hoops required to do the government contracts...
      And all the large incumbents are equally incompetent, so its not as if they can use someone better.

  • Not so fast (Score:5, Insightful)

    by WaffleMonster ( 969671 ) on Tuesday May 22, 2012 @02:36PM (#40079039)

    Key point from TFA "was easy for people with control over the machines to deduce and copy"

    If anything is running on a computer it is possible to probe it and figure out what it is doing and duplicate it if you have complete control over it. It does not much matter what it is how fancy an algorithm is being used or how it is configured.

    If you want something to stay secret then it needs to self destruct when someone tries to fuck with it or anything it depends on to work.

    Reminds me of the outraged cries of those 1337 few over the years who independantly discovered operating system x must be defective since you can bypass password authentication or access controls by mounting an unencrypted hard disk in a different computer. No shit.

    • The fact that a computer can be coerced to give up all of its secrets if you have physical access is not the point here.

      The main problem is that the secrets needed to deduce the seed of a software token can be uncovered without access to the machine in question. Specifically, the SID of the user's Windows account (easy to find if you have access to the account's AD) and the hostname of the Windows machine (often written on labels, also used as host component of DNS or WINS names). And both quite easily susc

      • by Bert64 ( 520050 )

        If you can reach a host over the network, windows will happily disclose its hostname via several of its default protocols (netbios/nbname, rpc, rdp etc), no need to find physical labels.
        Also on older versions of windows, the SID could be dumped out remotely by default too.

    • by Thaelon ( 250687 )

      The old rule still applies: Physical access is access.

  • What you have (Score:5, Insightful)

    by g0es ( 614709 ) on Tuesday May 22, 2012 @02:36PM (#40079043)
    I have never understood why software tokens have been allowed to be considered a "factor" in multi factor authentication. Particulary when it is stored on the same laptop/computer that the user is utilizing to connect to the secure resource. Doesn't it make more sense to have each factor seperated by an air gap or alternate communiation channel? That way if the system where the users is typing a password is compromised only the password is compromissed with possibly the ping from the token which would be a one time key. Even if the one time key and the password are comprimised the attacker basicly has to use it at the same time.
    • by Anonymous Coward

      Yes, but it is more expensive.

      At least that is the answer I got with my software token...

    • Aren't most software tokens smartphone apps? That still gives a reasonable air gap if you are using a computer as the primary access method.

  • So RSA tokens can be broken if someone copies the RSA software token. It doesn't take a security researcher to figure this out. Any 7th grader knows that if you steal someone's key to their locker, you can open it.

    If this is what "security researchers" get paid to do, sit around and state the obvious, I am in the wrong career field.

  • This is, in fact, how one-time passwords work. Once upon a time, RSA strengthened the security of their tokens through algorithm obscurity. The only news is that the algorithm cannot be considered obscure any longer. And this news is old. The fact that some random "researcher" learned enough of a programming language to create a program that takes a number and uses it as a random seed is not something that anyone (aside from said "researcher", and probably his proud parents) should care about.

    • by idontgno ( 624372 ) on Tuesday May 22, 2012 @03:23PM (#40079545) Journal

      I know this is Slashdot, but this thread is taking "TL;DR" to whole new places.

      The news isn't that RSA's algorithm is out in the wild. Without the account-specific sequence generation seed value, the algo is worthless.

      The news is that the researches have examined the Windows software version of the access code generator ("software token") and figured out how to extract the seed value out of a specific installation. With that seed value, you can take another copy of the software token and clone the key generation sequence of the first, allowing you to spoof the other token's identity.

      This is why most RSA installations I know of also require the use of a PIN concatenated with the token-generated number. That way, coaxing the code out of the software token isn't enough to authenticate as the identity of the person the token is assigned to; you have to guess the PIN as well (maybe by looking under keyboards).

      I guess the real story is "soft tokens don't protect their internal secrets as well as hardware tokens".

  • SecurID not broken (Score:5, Insightful)

    by Old Wolf ( 56093 ) on Tuesday May 22, 2012 @03:25PM (#40079563)

    I read TFA.. the algorithm is not broken and the seed isn't deducible from the output; all they've done is read the seed out of software auth running on a general purpose computing device.

    This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption (which ultimately adds no security, as the software still has to be able to wade through it to get to the seed). It's very similar in concept to someone being able to obtain your PGP or SSH private keys if they have local access to your system.

    There is no risk to people with a hardware auth device, unless the server is compromised (in which case this form of authentication is useless anyway).

    • by igb ( 28052 )

      This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption

      There are some slightly better techniques: McCune's Flicker system [] leverages TPMs (which any corporate laptop will have) in a way which means you can perform cryptographic operations securely unless the attacker can compromise the hardware in a pretty fundamental way. It would be ideal for implemen

  • by mr_stinky_britches ( 926212 ) on Tuesday May 22, 2012 @07:48PM (#40082023) Homepage Journal

    Wow, this is one of the worst summaries I've seen in the last 2 days on /.

  • But, of course, you can predict SecurID if you know the seed. That's the whole point of how SecurID and all other token security systems work.

    It's like saying that a one-time pad is broken if you have the predetermined list of keys. Of course, that's the whole point.

Order and simplification are the first steps toward mastery of a subject -- the actual enemy is the unknown. -- Thomas Mann