The Recent RSA Breach - Imagining the Worst Case, And Why it Isn't Time to Panic (Yet)

Published: 2011-03-25
Last Updated: 2011-03-25 02:17:32 UTC
by Rob VandenBrink (Version: 1)
8 comment(s)

The recent RSA Breach (, ) has got lots of people asking lots of questions, and as a security consultant, I seem to be getting lots of them directed my way. I thought it was time that someone said "How bad could it possibly be?" and outline just what the worst case might be, along with what the associated risks are (or are not, please read on).

First, let’s review how the RSA Authentication solution works. Your users have a keyfob (or a soft token on a phone or PC), with a token code that changes randomly. They also have a personal PIN code (4-8 alphanumeric digits), which only they know. These combine to make their password, which is normally used for secure access to a VPN, Web Server, Terminal Server or some other resource.

The more astute readers will have already seen the error in the paragraph above. The token code is *not* random (true randomness is a very tough nut to crack). The token code derived mathematically from a seed which is provided by RSA when the server is originally installed, the serial number of that particular token (printed on the back) and the system clock.

In short, RSA’s ACE server is a traditional multifactor authentication system. It combines something you have (the keyfob) with something you know (your PIN code) to authenticate you. Once authenticated, it is up to you to handle Authorization (ie – now that you are in, what do you have access to?).

So, back to the RSA event  - what is the worst case breach that might have occurred? Well, for all I know, the information that was stolen was RSA's Christmas Card list, they really aren't forthcoming yet on exactly what the extent of the breach might have been.

The absolute worst case I can think of (and I am NOT implying that this happened), would be if an attacker obtained a complete or partial customer list, complete with seeds and serial numbers. Again this is my own worst case - read on, even this is not as bad as you might think.

First of all, like all good cryptographic algorithms, RSA's token code algorithm is both math heavy and public. If you have the seed, plus the serial number of a token, an attacker can easily calculate the token code at any given time. CAIN for instance is a popular tool that has an interface for this.

This seems pretty bad, but don't forget the rest of it. When a user logs in, they need to supply their userid, their token code, and their pin code. There is no way that an attacker could have obtained the userids (specific to the organization) or pin codes (known only to the user) from RSA.

An attacker could easily obtain a list of users from several sources - your company website might have several senior staff listed, or even a corporate directory. Facebook, Myspace and especially LinkedIn are other likely sources for user names. Combining your first and last name in any of the common formats gets you a list of account names that will work for many environments. (note that some shops will have userids that are not related to your actual name)

This leaves the PIN code and the serial number. The assignment of serial numbers to usernames resides only on the customer’s ACE server - RSA does not have this information. The user’s PIN code is set by that user, and is 4-8 alphanumeric digits, though many organizations still only use 4 numeric digits. Unless people use trivial PINS, such as "1234", or the last 4 digits of their public phone number or extension for a PIN, the PIN is also probably "secret enough", since no-one knows it but the user.

All this being said, RSA's advice <sent in an email to RSA customers, and then re-posted here along with loads of other locations on the web  - > is spot on, and just plain common sense.   Some of the high points I've summarize here (in my own words and order), but RSA’s list of recommendations boil down to “defense in depth” against brute force login attempts (both in protecting against them, and minimizing the impact if successful).

  • Implement account lockout on your RSA server - if someone gets their login wrong 3,4 or 5 times, either they are attempting a brute force login, or they are legit, but need a refresher course and shouldn't be logged in tonight. Oddly enough, this one is NOT in RSA’s list, but it’s certainly first on my list !!
  • Review your logs regularly. Or even better, use common log monitoring tools like SWATCH, Kiwi Syslog (now owned by SolarWinds), or any other monitor to raise an alert when you see successive failed login attempts. SEIM tools do a bang-up job of this as well.  Have a procedure in place to take action when you see an alert.
  • Enforce strong password and PIN policies
  • Keep systems patched
  • Get your helpdesk on board, both the helpdesk and your users should know what a social engineering attack might sound like and what they should do if they see one.
  • Don’t let your workstation get owned. If your workstation is owned, a keystroke logger can snag your PIN, and all is lost. RSA's advice on this includes being careful on social media, don’t open suspicious emails, the usual suspects.
  • Use access rights and other authorization methods to implement least privilege access. If you don’t need access to critical information, then you shouldn’t have it.
  • Harden your servers


Long story short, no matter how bad RSA's breach might or might not have been, System Administrators have it in their power to implement truly effective mitigations.  In fact, after reviewing the list, all of us should be doing this stuff already – if not, there’s no time like the present to start !



Rob VandenBrink

Keywords: Breach RSA
8 comment(s)


How about this worst case speculation I read: Did RSA build in a backdoor for the government in order to gain approval to sell SecurID outside the USA and now the source code was taken?

If you want to scarf user names, try running FOCA against the target's website. It will download all documents it finds and parse out the metadata.

Think "C:\Documents and Settings\<username>\" type of information.

Also consider implementing client certificates on each remote device as an additional authentication mechanism. Just be sure to use your own internal CA and not a public one like Comodo. :-)
Forgot the link:
The major reason to deploy a two-factor authentication solution such as RSA SecurID is to provide a higher level of assurance in user identity using a risk-based approach. The bottom line is that if the second factor is rendered less or ineffective because the seeds are compromised, the residual risk may become untolerable. However, this risk is hard to quantify unless more information is disclosed.
"Implement account lockout on your RSA server - if someone gets their login wrong 3,4 or 5 times, either they are attempting a brute force login, or they are legit"

They are probably legit 3 or 4 failed login is usually someone making typos, or having problems due to the strong pw policy and miscapitalizing the wrong letters. I say nonsense to the "shouldn't be logged in tonight".

These sorts of things chew up helpdesk hours without adding much additional security; brute force attempts are best blocked through tarpitting and log review.

"However, this risk is hard to quantify unless more information is disclosed."

There is a way to quantify the risk -- by establishing an upper bound, assume the worst.
Assume the customer DB was compromised with all seed and serial numbers, and all SECID related source code.

SecurID no longer seems like a good option, unless they can be more forthcoming; hopefully the worst case is 2-factor authentication just became 1-factor authentication which is basically what all those "mitigations" suggest.

In our organization, we use 2FA on top of regular passwords. So the attacker would have to crack your password as well as guessing your token PIN.
@JJ: That seems unlikely to me. Why would the government want a backdoor to an *authentication* algorithm? It's easy to make a case for why they'd want a back door to a data encryption algorithm, since it'd help them read people's mail, so to speak. But it's not clear to me how a n authentication backdoor helps them. All you can do with it is impersonate a user, which would tend to give away the game pretty quickly.

if someone is bruteforcing AND users have been allowed to pick their PIN. I think it makes a big difference if someone is locked out at 3 or 6 tries.

This is because a smart cracker will try the most common PINS first 1234, 11111111, etc... so the first tries at a brute force (the easiest PINs) are the most critical, highest risk.

Of course best practice dictates NOT to let users pick their own PINS. Still, every company probably has some week ones (VIPs demanding a PIN of 1234, etc...)
How about this worst case, the bad guys got the source code for the RSA web plugin and determine they have a programming flaw and if you type (20) X's followed by an escape character, you automatically get authenticated or worse it causes a buffer overflow and you own the web server.

Diary Archives