Reverse Engineering RSA’s “Statement”

Responsible Disclosure?  Ummm, not so much…Sharable Shortlink

On March 17th, 2011, Art Coviello, RSA Security‘s Executive Chairman, posted a disturbingly murky statement on their website disclosing their discovery of an “APT” (Advanced Persistent Threat). In other words, they discovered that bad guys had been rummaging around within their internal network for some time (persistent) and had managed to penetrate one of their most sensitive and secret databases.  Here is the most relevant piece of Art Coviello’s disclosure (you can find the whole piece here):

[…] Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations. […]

As you can see, it would have been difficult for any bureaucrat to be less clear about what they know. But science is science, and the simple realities of what must be going on doesn’t accommodate much bureaucratic wiggle-room:

RSA’s SecureID devices are known to be designed around a cipher keyed with a 64-bit secret. The 64-bit secret is used to encrypt a realtime counter which generates an effective 22-bit value. While this is not many bits of time, the clock is incremented slowly, only once every 30 or 60 seconds, so 22-bits (4,194,304 values) is sufficient to outlive the expected life of the device and the timer would never be expected to wrap around.

RSA SecureID Token

One of several forms of the RSA SecurID Token

Each SecureID has an external serial number (printed on the back) that is used to identify and register it with an authentication service.  Hopefully, there is no “algorithm” of any sort for determining the internal secret key from the device’s serial number, since the discovery of such an algorithm would instantly kill the security of the entire system.

In the absence of a mapping algorithm, at the time of manufacture individual SecurID devices would be assigned a secret internal random or pseudo-random 64-bit key and a database would be maintained to forever map the device’s externally visible serial number to its internal secret 64-bit key.

This public-serial-number-to-secret-key mapping database then becomes “the keys to the kingdom”. It is RSA’s biggest secret to keep, since a full or partial disclosure of the database would potentially allow attackers to determine a device’s current and future display values and would therefore, of course, break any authentication protection.

To carry out a successful attack, an attacker would need to obtain its target device’s public serial number as well as one or more current output samples, at a known time, to determine the current state of the device’s 22-bit realtime clock. From that point on, an attacker could reliably determine the device’s output at any time in the future.

What can be deduced from what (little) RSA has disclosed?

  • If “the keys to the kingdom”—the public serial number to secret key mapping database—had NOT been compromised, there would be zero danger to users of RSA’s SecurIDs.  But we know at least that the danger is not zero.  Therefore, the most reasonable conclusion to reach is that RSA believes that at least some of  “the keys to the kingdom” have been compromised. (Because that’s their system’s only real vulnerability.)

  • Users of SecurID, and other multifactor authentication systems, typically do not provide the device’s public serial number when they are using it for authentication … though neither is that number intended to be kept secret (since it is printed on the back of every device.)  This means that an attacker would need to either have brief physical access to a device to obtain its serial number (which would also presumably allow them to obtain a few output samples to determine the clock counter’s current realtime position), or also have compromised RSA’s authentication account registration database which presumably maps user accounts to their device’s SecurID serial number.  Unless RSA discloses more, we won’t know how much more than the secret key mapping database may have been compromised.  Thus, it’s not possible to assemble a comprehensive threat model.

  • RSA may not want to do the responsible thing because it would be very expensive for them but given the only deductions possible from what little RSA has said in light of the technology, any company using RSA SecurID tokens should consider them completely compromised and should insist upon their immediate replacement.

RSA is understandably embarrassed.  And mistakes do happen.  If employees of a security company are using today’s incredibly insecure desktop toy operating systems, bad guys are going to be able to find a way to penetrate even the most carefully guarded connected networks.

RSA therefore needs to step up to the plate and take responsibility for what has happened. That means recalling every single SecurID device and replacing them all.  No company can consider RSA’s existing deployed SecurID devices to be secure.

You may CLICK THIS LINK to view this blog posting by itself so you can see replies and add your own.

Steve's Sig

This entry was posted in Uncategorized. Bookmark the permalink.

126 Responses to Reverse Engineering RSA’s “Statement”

  1. Dick says:

    You commented:
    “Users of SecurID, and other multifactor authentication systems, typically do not provide the device’s public serial number when they are using it for authentication …”

    Isn’t this the number that I give to, for example, PayPal so that they know which of my devices I’m using to generate the code that I’m about to enter? Wouldn’t that make the whole thing vulnerable to a man in the middle attack?


    • Steve Gibson says:

      Yes, that’s a good point Dick. There certainly are scenarios, like the one you describe, which are potentially even worse, where an observer would be able to see the device’s serial number.


  2. gerrald stangret says:

    I thank the heavens that there are people like Steve.

  3. Anthony says:

    Wow. I had such a good impression of RSA I never expected to hear of this kind of news from them.

    • Steve Gibson says:

      I’m disappointed that more was not disclosed. You can see what a tough position they are in, though. They can’t suspend authentication services or no one could use their tokens for login. But neither can the authentication service really be trusted any longer. The did the right and responsible thing by acknowledging what had happened — that certainly wasn’t easy either. But they haven’t said that all tokens would be replaced. (Though I wouldn’t be surprised to learn that this was going on in the background.)


  4. Deb says:

    I use RSA token for logging remotely, and I can tell you that having just the secure ID token serial number is not enough. There is a lot more to it to gain access if your company uses this secure token and other password combinations, etc., to keep your network access secure. Although this is a disturbing breach, for some of us, it isn’t enough to have me worried as a user of the product.

    • Steve Gibson says:

      That’s good to know, Deb. Thanks!


      • Ken says:


        I manage an RSA implementation in the enterprise so I want to clear a few things up. A typical installation of RSA has a server that is hosted within your environment. The seed files for tokens in your environment are generated at the time you do your purchase. Now I have no idea what was taken from RSA but an attacker would need to know which customers have which serial numbers. They would then also need to know what the user names associated with the serial number and the PIN that the user chose if that feature is enforced by your implementation. Also now if you have all that and you have a method of generating the code you still need to know which devices within the organization use authentication via the RSA token and that user is authorized to access the device.

    • Todd says:

      This is a problem if both something you have (SecureID) AND something you know (your password) is compromised. Many folks put a lot of stock in assuming the “something you have” is well maintained and secure… usually without question. It doesn’t take long for a nefarious person to learn your password, which is typically the weakest part of this equation. Also worth noting is most folks I see that have a SecureID dongle attach them to their keys. Keys are set down, left unattended so often. This news is an attackers paradise, especially at the local barista house.

    • Nithin K says:

      Completely agree here… this is where security measures apart from RSA prove their value.

  5. Pingback: World Spinner

  6. Alex Vdolek says:

    Steve, commerical users of the RSA tokens probably have the SecurID token serial numbers in a corporate database. If that database gets compromised by the bad guys, then an attack might be viable. Perhaps that’s why they’re publicly telling their clients to improve their security. Thanks for the email. Another happy Spinrite owner (with no tales of woe, yet).

    • Steve Gibson says:


      That does make perfect sense. And, as you say, it helps to explain why RSA’s advice to their users/clients seems to be “make your security better.”


  7. TomG says:

    Steve, I use the iPhone SecureID app for my PayPal login. Should I remove the SecureID token from PayPal, delete the app, and reinstall the app so I will (hopefully) get a new serial number?

    • Steve Gibson says:

      Tom… I think that makes a lot of sense. I was thinking the same thing. You might do it now, and then again in another week, just to be sure that RSA has removed all of the gremlins from their world.


      • Agent Heggle says:

        But they don’t know who the gremlins are, do they? Maybe the gremlins are masquerading as leprechauns, lying in wait, only to be unleashed next St. Paddy’s Day?

        To me, RSA’s 450+ Fortune 500 customers are now compromised to an unknown degree.

    • Are you sure you use RSA’s SecurID. I use a PayPal and the iPhone app is called “VIP Access” distributed by Versign. Although this is a system that works in a similar way to RSA’s SecurID, it is a different system with a different set of serial numbers and seeds.


  8. Sam Johnston says:


    How can you be sure it’s not enough to simply observe one or more authentications and then deduce the corresponding seed without needing access to the serial number?

    Neither the serial number (which often appears in trouble tickets, printed correspondence, databases, etc.) nor the generated OTPs are typically considered secure, and that’s not even taking into account things like adjacency (e.g. whether different members of the same org have similar serial numbers, meaning you may not even have to compromise your target rather just one of their coworkers, and vulnerabilities in the sales cycle, such as predictability of serials depending on country/partner/etc).


    • Steve Gibson says:


      Given that there’s some, presumably strong, 64-bit keyed cipher or hash (probably a hash) that’s driving the display, observing successive display outputs wouldn’t help you to predict future outputs. That’s the whole point and strength of the RSA OTP approach (as long as that 64-bit key doesn’t get loose! :).


  9. Yasir says:

    I’m considering a new deployment of RSA SecurID. Since the tokens will be new, I think they won’t be affected by the seed database disclosure.

    I might even argue that RSA is the best choice now for OTP, because after getting compromised once they are less likely to be complacent. Moreover, the lessons learned from the incident will give them an exclusive insight into this kind of threat, therefore they will have better security than others who haven’t been compromised.

    It’s a typical case of “what doesn’t kill me, makes me stronger”.


    • Steve Gibson says:

      Yessir Yasir, I think you’re right.

      What happened to RSA is absolutely unfortunate. And their lack of clarity is something that has annoyed a LOT of people … understandable and necessary as even that may have been. But I really don’t hold this against RSA in the long term. As I wrote, anyone CAN make a mistake and protecting a large enterprise network that has any of today’s desktop operating systems inside is just about impossible.


      • Mike Scalora says:

        Are you assuming they knew how to be secure enough to prevent this and botched it? Or are you assuming they did the best job they know how and came up short? Frankly, I’m not sure which one was worse.

        This kind of organization should have independent teams reviewing the security and/or outside security audits that should have uncovered the security hole(s).

        If they have been compromised, how can you be so sure they have cleaned up every system in the company? Isn’t it agreed that it is impossible to clean a compromised system? How do you clean a whole organization? Create a new secure environment and not let a single system (server, employee computer, router, storage system, etc) into it until it has been wiped, reformatted and rebuilt from the boot sector and all data migrated in has been cleaned and verified?

        Steve, I’m shocked you are ready to trust these guys again so easily. Since they won’t say what happened I think everyone should assume every programable device is rootkitted and malware is on every storage device.

        What ever happened to the idea that regaining lost trust is more difficult than gaining it the first time.


        • Agent Heggle says:

          I agree. I just stumbled on this site today. (Very good WordPress site, by the way.)

          From what I have read so far, once they’re in, they don’t need no keys no more. And a re-boot does not do anything to resolve the problem.

          They lie in wait for extended periods, then transmit a beacon to liven up and connect outside the “secure system” whenever they want.

          Then they have some <em?fun!

          • Ryan Guy says:

            The nature of persistant threats is they are persistant. They remain. Once you find them one way, they are there again very quickly using a different tactic. Once a foothold is gained, they can surreptitiously gather and exfiltrate data without causing so much as a blip on the total network traffic maps.

            I would like clarify one point, though. They hardly every “lie in wait.” In my experience, they take advantage of every single opportunity to gather intel or data. They are either gathering user credentials to exploit, or are using previously harvested creds to gather data, and then the cycle repeats until they get caught. Once they get caught, they tweak JUST ENOUGH to not get caught again, and the cycle repeats again.

      • Yasir says:


        Thank you for the most informative commentary and insight in the industry. I’m a long time listener to security now podcast and whenever I have any questions about security I always wonder (what would Steve say about this).
        In brief, you are my security superstar.

  10. Steve says:

    Asking to have your tokens replaced may not be the wisest decision. If the attackers have not been removed, they could just copy the private key when a new one is created. If RSA did not keep these keys in escrow, only the ones created during the time of the breech would have been disclosed. So, your key may not have been compromised, and might be if you ask for a new one.

  11. Greg says:

    We run a SecurID server in our company that uses these tokens for tens of thousands employees. business partners, and customers, and had to give this some thought. We figured that the worst that could occur is the exposure of that seed-to-serial mapping. When we get new tokens we load these seed mappings into our server so it can map the right pass value to the right token which in turn is mapped to the right user. So, the bad guys may know the seeds to all our tokens – but they don’t know who has them – that’s not stored by RSA, that’s stored on our company SecurID server.
    What the bad guys would need to do is every minute pre-calculate all values of all seed/serials, then intercept some authentication traffic (possibly a few times) to match that pre-calculation to a particular user to then have both parts of the authentication requirements – user and token. To do this they would have to also somewhat infiltrate our company to set up such interception. Or they could just try to brute force it. Now we have tens of thousands of tokens (maybe sixty to eighty thousand); our server is configured to lock out tokens on three bad attempts; all our authentication traffic is encrypted (SSL web pages, SSL built into our applications, etc.) so that it can’t be intercepted and we don’t ever drop out to an unencrypted session after authentication. So we’re not yet in a state of panic. We’re still watching developments with interest, but our most immediate concern is explaining it all to jumpy upper management.
    I imagine that when RSA is saying that they are contacting customers in regards to strengthening their implementation it would be to check that processes similar to these are in place.

  12. Adam Stasiniewicz says:

    As bad as this news is, there are a few mitigating factors. First, the RSA factory (where presumably these devices are programed and customers are securely notified of the serial number to seed mapping) has no way of knowing which individual in a company will receive a fob. Rather, the factory knows that a box full of SecurIDs were shipped (and the box could contain hundreds if not thousands of fobs). To circumvent this, an attacker could monitor a user entering in their OTP. Either getting a look at the back of the device, or recording the value of the OTP and the current time. Then check against the thousands of possible seeds and verify which of them would have displayed that value at that particular time.

    The other mitigation is that in virtually all SecurID deployments, the OTP is combined with a pin/password. So just knowing the current OTP is not enough to break into an account. But, since the attacker will likely need to be monitoring the users (to circumvent the previously mentioned limitation) they could also monitor the user entering their pin/password (which unlike the OTP, is a static value).

    The other thing that worries me is how many people carry their SecuID fobs. Personally, I keep all my fobs on my key chain which is in a pocket or other opaque place. But I often employees attaching their SecurIDs to their ID card lanyards. Though it makes it more convenient and harder to loose, the employees are now exposing their current OTP value and serial number to an attacker. It should be pointed out that an attacker would not need to be in the physical office building, as many employees will keep their IDs on them when they leave for lunch or leave at the end of the day.

  13. Kelly Price says:

    This is going to be a PITA if RSA is forced to recall all the SecureID’s. Some governments (Maryland included) use them as VPN tokens, and there’s already a shortage of tokens in their transit administration (MTA).

    • Steve Gibson says:


      I’m certain that RSA will be working to minimize their need to replace tokens. What every concerned user of “old” tokens should do is make RSA explain to them why they are NOT at risk now, after bad guys have been rummaging around inside their network.


  14. Hypatia of Alexandria says:

    I Really don’t thing Paypal users need to worry much. Whenever you see phrases like “persistent threat” they’re not talking about attackers who are motivated by either money or notoriety.

    • Steve Gibson says:

      Right. In this case, the damage to RSA’s reputation ~ even to the degree that it’s probably somewhat unwarranted ~ may be the most expensive thing that comes from this. Though… having potentially compromised tokens just can’t ever be a good thing. 😦


  15. Pingback: Reading Into RSA’s “Responsible Disclosure” « Steve Shead Dot Net

  16. Pingback: Non-Disclosing Disclosures in Modern Life: SecureID and Nuclear Hazards | Orcmid's Live HideOut

  17. Grant Bugher says:

    It’s a testament to RSA’s marketing and brand recognition that people think that all two-factor auth tokens are RSA SecurID. The PayPal tokens and the Blizzard Authenticators (World of Warcraft’s login token) are not RSA SecurID at all — they’re Vasco Digipass, which works basically identically but has no connection to RSA and is unaffected by the breach.

  18. Pingback: RSA Hack Demonstrates Superiority of Cell Phone as 2nd Factor | EconoLan

  19. Pingback: RSA token security issues - important for those who have them.

  20. Pingback: Top Posts —

  21. jgajek says:

    A technical correction: Since early 2003, RSA SecurID tokens use a 128-bit token-specific random seed, which is pseudo-hashed using the AES-128 block cipher in EBC mode, along with the current time and token serial number to generate a 6- or 8-digit token code every 30 or 60 seconds.

    The 64-bit secret seed and Brainard hash function (which the Wikipedia article on SecurID still seems to refer to) have been phased out and are no longer in use.

    I do agree that all known facts so far point to a compromise of the token seed database: Reflections on Security

    • Steve Gibson says:

      Ah, thanks for the technical update. I was working from a circa 2000 reverse engineering of the earlier SecurID technology. I wonder whether it’s known how many bits of “time” are sent into the pseudo-hash along with the device’s secret serial number?


      • jgajek says:

        I believe it’s 64 bits of time (based on the time() function of the standard C library). I am working on some proof-of-concept code for AES token emulation. There is a closed-source implementation (Cain & Abel) that can be checked against.

    • Chris ulrich says:

      A quick question:

      If I have the key database for these RSA fobs and I have a way to monitor authentication transactions, how many authentication transactions do I need to observe from a single fob before I can guess their seed key and pretend to be that user?

      Granted this means calculating every key’s number for a given time, but that’s what EC2 is for, right?

      Thank goodness we can trust SSL CAs to never issue valid certificates to invalid parties.

  22. Pingback: Business warned to be on guard after RSA confirms breach of SecurID system | Big Entertainment

  23. barneymeyer says:

    Hi Steve
    Nice article. Here’s the (unacceptable) response from my Westpac branch manager after first denying that there was a problem:
    “Hi xxxxx,
    I have received confirmation from our Business Online division that Westpac’s Token’s haven’t been compromised in anyway and that it is safe to use.
    The article does not state anything specific to Westpac and only named Westpac as a user of Token’s.
    Kind Regards, name removed| Local Business Banker | Retail and Business Banking | Westpac Banking Corporation”
    Regards, Barney

  24. Alternative: Yubico or it’s yubikey. Host it yourself (in the cloud?) and integrate with anything.

  25. Pingback: RSA, The Penetration

  26. hypatia says:

    Off topic:
    Steve, why back on dark red? That’s not very readable. I have to copy page into a text editor to read it.

    • Steve Gibson says:


      I’ve seen a few complaints about the blog’s coloration. But I’m mystified. There’s dark red way to the left and right outside of the page. But the page itself is black on white. (At least for me on several different browsers and, I assume for most everyone else.)


      • Karlin High says:

        I also have the black text on dark red background. Try using only content and scripts from URLs; that’s what my whitelist web filter (SafeSquid) does. My Firebug add-on shows CSS and Javascript assets trying to come from or, which get blocked because I’m only allowing It messes up the pages, but I make out.

  27. Essential Guidance We’re Providing to Financial Institutions:

    Cautious Actions and Contingency Plans

    1. Be in contact with RSA, your RSA Business Partner, and follow RSA customer advisories.
    2. Immediately Assess High Risk Environments. Determine dependencies and vulnerabilities, determine value at risk. Some scenarios may dictate that firms eliminate the use of SecurID tokens until a more complete assessment is complete. High risk environments should include:
    – Banking Wire and Money Transfer Operations
    – Corporate Wire Transfers
    – High Net Worth Customers
    – Facilities Access
    – Enterprise Access
    – Vendor Access
    – Retail Banking/Brokerage

    3. Action Plans
    – Communication to and for executives and key business and IT leaders globally
    – Communications to customers and partners.
    – Alternate authentication techniques for high risk transactions, environments, and facilities, including call backs, use of test codes on wires, access confirmations via SMS, and others
    – Exploit analysis and security event filtering, incorporating transaction monitoring and red flag reporting. Increased monitoring of any corporate mentions and employee usage of social media. Real-time monitoring of access logs and SIM/SEM systems. Review of all privileged access management logs and activity. Consider moving to least privilege access model for all activities associated with SecurID.
    – Preparations for “copy cat” breaches on similar technology, potentially impacting larger consumer focused applications that in the U.S. are not dominated by tokens.
    – Removing high risk tokens from membership and establishing re-issue plan
    – Determining transition plans in the event of large scale recall of all tokens in membership for your institution.

  28. My bank uses Verisign Tokens, which for the moment are still on the safe side 😉

    My question/problem is: till a year or so ago, in addition to the 6 digit OTP from the token I had to enter a prefix in the OTP field composed of a pass phrase I choose and set in my account (so in the OTP field I have to enter: “mypassphrase123456”). Unfortunately, a year ago my bank changed this and removed the prefix pass phrase, now I need only to enter the 6 digit OTP.

    In my opinion the old method is safer, because even if for some reason somebody was able to crack the OTP generation, they still can’t use it to access my account because of the pass phrase. Steve, am I right about this?

    • Steve Gibson says:

      “tech engineer” … I’d say that you’re clearly right. The more unknown (or less easily knowable) data required for authentication the harder the bad guy’s task. We’re talking multi-factor authentication. So added “factors” is always useful.


      • Shay says:

        Actually, I don’t think you need consider the Secure ID as unknown (or rather, hard-to-know), but as unobtainable (or rather, hard-to-obtain)

        Your password verifies that you know something only you should.
        Your token verifies that you have something only you should.

        So in effect, tech’s bank used to verify that he both knew something, and had something. Now they only verify that he has something.

  29. Pingback: RSA, The Penetration | Portable Digital Video Recorder

  30. I would like to know whether the yubikey (as covered on Security Now) is vulnerable in a similar way if their servers were compromised. I asked yubico, but have had no response so far.

    • Steve Gibson says:


      Funny you should ask! <grin> I met with Stina (Yubico’s founder) a few weeks ago for coffee during which she showed me some new technology (and provided me with a complete technical disclosure PDF) that I am not yet able to talk about because they are not quite yet ready for public release. But they should be within another week or two. It is something they developed preemptively to address exactly this problem.

      What I can say now is, knowing what I know, the same thing CANNOT happen to Yubico. In another week or two I’mm be able to explain exactly why.


  31. Bob Ward says:

    Our company uses RSA tokens. We would switch to soft tokens if given the chance (which I know have their own security issues). One way RSA could save some money and rectify at least part of the problem would be to give out licenses to users of their key fobs.

  32. diocyde says:

    This is par for the course in these attacks. Better effort would be spent getting educated on WHO did it and then why. I will point you in the direction –> Get educated before the last pieces of the IA puzzle unwind and fall to our feet. At this point its the question of who ISNT hacked, not who is hacked. F#$$’in sad.

    RSA owes FULL disclosure and a serious and public investigation of the attackers, their names, phone numbers, addresses, employers, and then should petition the US Government for full restitution in the form of economic and political penalties.


  33. Eric says:

    So, assuming that serial to secret mappings have been exposed, what does this mean for soft token seeds? Do they still have the same serial to secret mapping, but don’t have the risk of public exposure of the serial on the back of a keyfob?

    • Steve Gibson says:


      With RSA saying so little, we really have no way of knowing. Soft tokens, of course, have the additional vulnerability of being inherently reverse engineerable. (Hardware tokens would be too, of course, but that task would be far more difficult.) So software tokens could never be secure if the secret were not being randomly assigned at initialization time.

      Still, without MUCH more disclosure from RSA, the limits of the exposure is impossible to gauge.

      And note, too, that it’s VERY LIKELY that RSA may themselves not know how much was potentially lost. They might be remaining vague to limit their liability in the event of underestimating the threat … if they are unable to estimate it accurately for themselves. 😦


  34. Pingback: AMD Appoints Mike Wolfe as New CIO-Daily Forex and Stock | Daily Forex and Stock

  35. Pingback: The Geek Blog » Blog Archive » RSA’s Recent Compromise

  36. Pingback: RSA Security – No-One Can See The Forest for The Trees | Metaforia

  37. kageneko says:

    One thing to consider, Steve, is that RSA may not be legally able to give much more information than what they did, because they are involved in an active legal investigation with federal authorities. Having sat in on a few calls with RSA explaining their situation, they have mentioned that they limited to what they can share because of the legal investigations, which is a plausible explanation. I’m not sure how much of that explanation is legitimate and how much is spin, but it does make sense.

    As for how the breach occurred, based on some of the security measures RSA has advised, one possible guess is that an RSA corporate user may have been hit using social engineering or through a social media site of some sort (based on how much information people put out on social media sites, targeting someone based on good intelligence gathering would be simple). From there, the attackers probably slowly worked their way into escalating their internal privileges and then attacked the databases when they had their access. This makes one consider just how much information one voluntarily puts out on places like facebook, twitter, linked-in, etc., and the vulnerabilities that it introduces to the workplace and personal life.

    Finally, if a company is relying SOLELY on RSA tokens and 2FA as their first and only line of defense, I would argue that the defensive strategy is a bad one. 2FA should be just one line in a series of defensive measures to keep the bad guys out. Additional measures, such asVPN device management, separate VPN credentials from enterprise credentials, VPN login monitoring and auditing, Service account auditing, etc., would make it difficult for an attacker to take advantage of a weakness in one portion of the defensive line. A good defense in depth strategy should not result in doom and gloom, should one factor in that defensive strategy (in this case, RSA 2FA tokens) be compromised.

  38. Pingback: Tenable Network Security Podcast – Episode 75 | Portable Digital Video Recorder

  39. Benny L says:


    Thanks for your work with the Security Now podcast! I listen to it every week and it’s great fun and enlightenment at the same time.

    Regarding the RSA stuff… I haven’t really seen much commentary/speculation yet around the *who* and *why* questions (although one or two other commenters did touch on it).

    It seems to me a far too targeted and sofisticated attack to just be a random “drive-by” hack. I wouldn’t be surprised if the REAL target lies somewhere else entirely. Like some organization that uses SecureID tokens, an organization that someone or some other organization (or country for that matter, Stuxnet fresh in mind) want to penetrate. (Ah, I see stuff for a future Hollywood spy movie here…)

    We don’t know how long they have been compromised, so the perpetrators may very well have achieved even their real goal, if there were one, and be long gone by now. So if I were a security analyst I’d be on the lookout for other reports of security breaches in the future, one might pop up that matches with this one.

    Just some late night speculation. 🙂

    Thanks again for your great work!

  40. Pingback: Who is Hahleq? : Reverse Engineering RSA’s “Statement” | Steve Gibson

  41. Pingback: The RSA (SecureID) Compromise - Security Corner

  42. Pingback: Delicious Bookmarks for March 30th from 01:12 to 10:29 « Lâmôlabs

  43. Capy says:

    It’s “SecurID”, not “SecureID”.

    It’s a 128-bit token, not a 64-bit token (simple 1 second google would have clarified that).

    So you may want to remove your references to a “64-bit secret” and the “22-bit rtc” pseudo-math, because all you are doing is confusing some poor people.

  44. Cliff Kemp says:

    Hi Steve. Long time listener and Spinrite owner. I enjoy listening to the podcasts you have done on Certificates, Hashing, ect.. I have been doing some research lately for a Computer Science Master’s program on the security that is being tested for Vehicular ad- hoc networks(VANET) IEEE 802.11(P). Having a secure communication between Vehicle to vehicle and vehicle to roadside unit is critical and in some cases can be life saving. The concern is for authenticated messages between vehicles and modifying certificates to minimize computation. A balancing act between speed and reliability. To complicate the process even more, privacy is thrown into the equation. People do not want their location to be tracked. (Big Brother & Malicious attacker) Do you have any thought s about this or maybe a future show about this topic since it will be at some point a part of our everyday life in vehicles.
    Again enjoy your show and products,
    Cliff Kemp

  45. Dick Victor says:

    I read some comments recently (thought I had set a bookmark, but apparently didn’t) which implied that the RSA token serial numbers and the secret keys were related by an algorithm and that it is that algorithm which was believed to have been stolen. I think most of the comments here suggested that the relationship was random, but retained in a database. Is it likely that they really used an algorithm to generate the keys from the serial numbers? While I’m a long way from an expert, I do have nearly 300 Security Nows under my belt and generating those keys in that way would seem to be a bad idea.
    Am I missing something or was the material I read likely to have been incorrect?
    If the average 3 credit college course meets 3 times each week for 16 weeks, when I get to 300 Security Nows I’ll have completed my first semester and then some. Can I get an M.S. this way if I stick around long enough? 🙂

  46. 08YMelvia says:

    free amateur boy your amateur video

  47. Julie says:

    Have you looked at other data protection services like DiskAgent

    Providing data protection is a complex issue and there are several layers to consider such as computer backup and or remote backup as well as mobile security and remote wipe solutions as well as encryption. What do you know about these providers and who do you consider most relevant?

  48. Pingback: This Month in the Threat Webscape – March 2011 : CU*Secure

  49. Pingback: SecurityNow! « TimeWellScheduled – Blog

  50. Tom Burgess says:

    Mr Gibson, I have a different question on this post as I did not see a separate way to contact you regarding my question. We received a note from Dell as my employer is an enterprise client regarding a industry wide change to disk drive management. The International Disk Drive Equipment and Materials Association (IDEMA) has established a new sector format from 512 to 4K and wanted to know if this change will impact your SpinRite disk utility product in working on this new drive format change? Since your products works at the base bit level of the drive, I was not sure if this impacted your product or not. Please advise. Thanks for creating SpinRite, an awesome tool I keep in my tech tool box!!

    Best Regards,

  51. Pingback: RSA Remediation? | IT Security Column

  52. Pingback: RSA pwnage | The IT Manager (

  53. I know you are going to talk about random numbers in the up coming security now podcasts. Good! I am not a computer programmer at all. But I did try to write a few programs back in the day using basic. My brother (who is a programmer) had interested me in this back in the early eighties. So anyway, I wanted to write a program that would generate an event and that meant I needed random numbers. At that time I had no formal training with basic and didn’t know about the random number generator available. So I started to try to crack this one myself. I didn’t have much luck, but the only thing I came up with was the fact that I know that the number pie seems to go forward in a random fashion and as long as you were way out there in the unknown regions you could use that to generate random numbers. Well, that was my thought from back then anyway. I thought take pie times todays date and time, and multiply it against a string of the same and wammo! random numbers. I never tried it, just thought about it. Can’t wait to hear how to actually do it. Thanks for years of listening fun!! And for SpinRite which I have a multiple license for. 🙂

  54. FishOil857 says:

    Laws that do not embody public opinion can never be enforced.

  55. notanonymous says:

    Hey Steve, I just wanna let you know that you BBC News did a segment about ” Internet Security” and it mentioned “Security Now” podcast. I am posting the youtube link to the news segment.

  56. Greg Mendizabal says:

    Hi Steve,
    Looks like it happened. News report saying Lockheed-Martin security breach appears tied to SecurID compromise (duplicated keys from info stolen in RSA breach?).

    Apparently not just script kiddies…

  57. Simon says:

    I’d just love to know why Lockheed-Martin was still using these tokens after the RSA attack. It’s just stupid. They’re just a DEFENSE contractor.

    Maybe they should just open source the blueprints for the Joint Strike fighter and have done with it. That might make their security headaches go away.

  58. Pingback: The Seedless Garden | The Networking Nerd

  59. Doug says:

    You were right Steve – RSA just admitted the theft.

    Hiding it did far more damage to their reputation than the actual theft.

  60. Steve interesting development — RSA to replace SecureID tokens for “virtually every customer we have.” WSJ:

  61. David Wayne Johnson says:

    Idiots they knew they were compromised and the situation only got worse for their customers!

    Security vendor RSA on June 6 offered to replace its SecurID multifactor authentication tokens for customers who typically protect intellectual property and corporate networks (see RSA Moves to Replace Customers’ Multifactor Authentication Tokens). The offer comes a week after the revelation that the loss of information from an attack on RSA’s IT system last March led to a breach of the computers of defense contractor Northrop Grumman, a SecurID customer (see RSA SecurID Breach Could be at Root of Network Disruption).

  62. Robert L. Huber - MicroAcres says:

    Steve, Just saw this and thought of you. Token Security.
    Bob Huber, aka Honest Bob & MicroAcres
    SF Bay Area

  63. Dick says:

    We’ll have to wait to see whether RSA can survive this disaster. I’m reminded of the amazing PR recovery made by the folks that make Tylenol, but in that case they weren’t in any way responsible for the problem. RSA can’t make that claim. Even if they can afford to give everyone a new token, why would anyone trust them with the “keys to the kingdom”?
    And then there are the potential breach of contract and tort lawsuits for damages sustained by their customers as a result of their failure to provide the security they promised to provide and for their negligence. This could take years to resolve and RSA may not have the money or the staying power.

  64. TheRal says:

    • Mariam says:

      16a13b35f7You can certainly see your exitrepse in the work you write. The world hopes for even more passionate writers like you who aren’t afraid to say how they believe. At all times go after your heart. 187

  65. TheRalf says:

    in reference to eavesdropping on a message from alice to bob when alice is using a quantum signature (which is passed out of band…), it is possible to ‘copy’ the message using ‘moon shadows’…

    while observing an observable (quantum state) causes that observable to collapse into one of the possible states; and, that ‘cloning’ of that state is not allowed, thus making the signature unique…

    it is agreed that local errors in quantum states are local entities… and, that this de-coherence can be corrected (re-coherence) without observing (ie measuring) the original state…

    a first approximation would be like looking at the rain shadow of a car in the driveway after the car has left… from the shadow you can guess the size of the car…

    a second approximation would be like an X-Ray of a box of random things… 3-d projected onto 2-d…

    so, if alice is using a light guide to send the info to bob, eve could take a big spool of fiber and splice it into the path. cleaning the sheath at the beginning and ending of the spool, eve would shoot energy perpendicular to the fiber near to the energies of the message (frequencies, that is) so that the interference would be a measure of the local errors… thus a rain shadow… but, by having a large spool, the message would take time to travel its length to the end nearest bob… eve would, at that end, un-rain the message (re-coherence), removing the slight changes.

    since this is via ‘light’ energies, instead of calling it a rain shadow, it’s called a ‘moon shadow’…


  66. Steve,
    I wrote about this as well in my blog. I am behind in my security now episodes, but just heard your discussion with Leo wherein you comment along the lines of “I hope it is nothing as silly as a PDF exploit.”. Well, according to the RSA blog posts, it was an excel file called something like Recruitment 2011.xls.
    This brings up a very important point about large businesses and enterprise security. You and I could easily say “This is pathetic that a security company can’t keep it together enough to maintain all the updates on all the machines.” Yet it is logistically very difficult to do this.
    Removed from having a MODERN mentality within upper management – seeing the advantage and approach of pure virtualization in the enterprise, CIO’s and CSO’s need to keep track and regularly update all corporate machines. This requires an internal policy change to have the downtime to get a refresh, and maintaining staff, dedicated to testing new virtual images on a regular basis. Yet this just not feasible in most corporate environments.
    As an IT Consulting firm owner (long time listener to SN and registered spinrite owner) I have to put together a SHORTENED list of what should be required for an IT staff member to perform within the Microsoft Active Directory, twice a month:
    – Ensure desktop OS is completely up to date (and those updates do not conflict with division specific applications like web apps)
    – Audit the end user’s surfing behavior
    – Flush spooler problems
    – Ensure all USER accounts on the machine have flushed temporary internet files, caches and unnecessary programs which have not been installed like toolbars
    – Keep Firefox as the default browser, updates current, and addon updates all installed on each user account (like Adblock Plus)
    – Audit the local user mail file store sizes and SPAM folders
    – Update Flash players for the system and the designated PDF reader. (Ensure that each machine user account has proper adobe reader profile preferences – Javascript, etc.)
    – Audit the antivirus threat and quarantine logs are noted, and then make sure the machine is completely scanned with a CURRENT well respected antivirus solution

    Then there is server side updating….

    Knowing enough basic arithmetic and figuring hours available to any IT department, this is an unobtainable goal and use of staff time. Imagine the background processes for new hires, and fires. Consider the temp workers and the other infected machines, hardware failures and over due deadlines for previous IT projects. Vendors that have slacked off which stopping projects to complete. Warranty expiration reviews and server and firewall access log file reviews. Employee discipline and daily news issues in security and in the enterprise.
    Nothing on my list is really optional from a security point of view. Every CIO who is forecasting for his own budget needs can’t possibly get the staffing he needs to ensure this kind of desktop maintenance. It is a fundamental problem that is quietly and quickly reaching a crescendo that will alter the future of IT in the enterprise.
    I believe these were pin-pointed email spear phishing attempts. It was not mentioned, but I would almost bet that this was not the first network breach.

    Regardless of the outcome of this RSA mess, I can say first hand that all enterprises have a very tough time justifying their costs, in monthly desktop maintenance logistics, alone. There are also issues based around mobile devices and laptops. At this point, there is simply NO WAY I can fault RSA ‘s efforts understanding these difficult staffing and security challenges. We need to look forward to dealing with IT departmental issues and help the future of the enterprise prepare for the next round of attacks – and possibly back off of RSA’s unfortunate break in.
    Keep up the great work and thanks for all the amazing work you and Leo do.
    Ari Goldstein – Menlo Technical

  67. Frank Lee says:

    Why do I not hear more about Wikid? Or PhoneFactor?

  68. John says:

    Hi Steve,

    I have reading your stuff about NAT security on I was just thinking about using my 6 routers and daisy chain them together. Would this really benefit security? How would it be different to using only 2 routers?

  69. Li Peiji says:

    Seamoon provide OTP solutions.

  70. JM says:

    Nothing negative will happen to RSA because of this one-time event. RSA, their tokens, their serial numbers and the many hoops they make you go through will continue to protect their customers.
    Steve, you hardly know a damned thing about RSA’s operations and if your readers would just stand back, take an overview of your last few years of posts, blogs, etc, they will clearly see that all you’ve done and continue to do is spread FUD.
    How about quit pretending you’re an expert on security and get back to your real job, programming in assembly. (No wait, that would obsolete you…)

  71. Pingback: Comprehending Reverse Engineering Faro |

  72. Pingback: Tranet

  73. LeoNotenboom says:

    Haha What about CryptoLink its been over 3 years now and you havent even mentioned it since 2010. I was listening to some old episodes of Security Now last night and you must have promised so many things to your listeners, and they were begging you to finish it already. Now I notice you have must have given up, maybe you learned your lesson about talking about things that you havent done yet Steve. Listen, I love you man, I just feel bad that you promised people something that you were never able to deliver yet.
    Good Luck !

  74. Steev says:

    Steve, thanks for this awesome service. Glad to know I’m so well “stealthed”. Keep it up!

  75. Pingback: The Broken Philosophies of Third Party Digital Certificates and How They Put you at Risk | Emmanuel Technology Consulting

  76. Paul says:

    Hi Steve, Just visiting after seeing the “UPnP scan shows 50 million network devices open to packet attack” and remembering your work on MS UPnP, Who Knew.. Same age as you, Just listening to your Vitamin D synopsis… very interesting.

  77. GayMan69 says:

    Steve I am very proud of you for coming out as gay. As a gay man in the 2000s. Good luck to you and the man or men you are currently “dating”.

  78. I constantly emailed this website post page to all
    my associates, since if like to read it next my contacts will too.

  79. Pingback: This Month in the Threat Webscape – March 2011 | Polar Bear in #security, #endurance and #life.

  80. According to the American Diabetes Association, the goal in
    dieting dinner ideas is to keep energy on an even level. It is easy to make, and unfortunately for dieters, it is critical to avoid diets that promise results that are nothing short
    of unbelievable.

  81. Pingback: Reading Into RSA’s “Responsible Disclosure”

  82. Un bon merci à l’auteur du site

  83. Hello to every , because I am truly eager of reading this webpage’s post to be updated regularly. It contains nice material.

  84. As a leading Company, The Original PC Doctor provides best IT support solutions.

    The first thing that you want to do is disconnect the CPU box from the power outlet.

    The motherboard is the main circuit board of the laptop that
    everything is connected to.

  85. hey says:

    Hi there, You have done a fantastic job. I’ll definitely digg it and personally recommend to my friends. I’m sure they will be benefited from this web site.|

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.