Slashdot Mirror


Researchers Can Generate RSA SecurID Random Numbers Flawlessly

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

8 of 98 comments (clear)

  1. Not exactly... by Anonymous Coward · · Score: 5, Informative

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

    1. Re:Not exactly... by Fwipp · · Score: 5, Insightful

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

    2. Re:Not exactly... by fuzzyfuzzyfungus · · Score: 5, Informative

      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.

    3. Re:Not exactly... by Cramer · · Score: 5, Interesting

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

    4. Re:Not exactly... by datajack · · Score: 5, Informative

      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.

  2. This is great news! by CubicleZombie · · Score: 5, Funny

    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!

    --
    :wq
    1. Re:This is great news! by Beardo+the+Bearded · · Score: 5, Funny

      That's what I do, I just have two Engineers in India do my work and FTP it to me once a week. They get paid 1/10th of what I do, so I do basically no work for 80% of my paycheque.

      Outsourcing works both ways.

      --

      ---
      ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
  3. What you have by g0es · · Score: 5, Insightful

    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.