SecurID

SecurID, now known as RSA SecurID, is a mechanism developed by Security Dynamics (later RSA Security and now RSA, The Security Division of EMC) for performing two-factor authentication for a user to a network resource.

Theoretical vulnerabilities

The most simple practical vulnerability with any password containers is just losing the special key device or the activated smart phone with the integrated key function. Such vulnerability cannot be healed with any single token container device within the pre-set time span of activation. All further consideration presumes performant loss prevention, e.g. by additional electronic leash or body sensor and alarm.

While RSA SecurID tokens offer a level of protection against password replay attacks, they might fail to provide adequate protection against man in the middle type attacks. In the attack model where an attacker is able to manipulate the authentication data flow between a user and the server, the attacker will be able to then forward this authentication information on to the server themselves, effectively masquerading as the given user. If the attacker manages to block the authorised user from authenticating to the server until the next token code will be valid, he will be able to log in to the server. RSA SecurID does not prevent Man in the Browser (MitB) based attacks.

SecurID authentication server tries to prevent password sniffing and simultaneous login by declining both authentication requests, if two valid credentials are presented within a given time frame. See an unverified John G. Brainard post for more information. If the attacker removes from the user the ability to authenticate however, the SecurID server will assume that it is the user who is actually authenticating and hence will allow the authentication through. Under this attack model, the system security can be improved using encryption/authentication mechanisms such as SSL.

March 2011 system compromise

On March 17, 2011, RSA announced that they had been victims of "an extremely sophisticated cyber attack". Concerns were raised specifically in reference to the SecurID system, saying that "this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation." However, their formal SEC 8K submission indicates that they don't believe the breach will have a "material impact on its financial results." The extent of the compromise and the associated risk to customers will not be known until further details have been released.

There are some hints that the breach involved the theft of RSA's database mapping token serial numbers to the secret token "seeds" that were injected to make each one unique. Reports of RSA executives telling customers to "ensure that they protect the serial numbers on their tokens" lend credibility to this hypothesis.

In a March 21 email to customers, RSA essentially admitted that the information stolen from their internal network would allow an attacker to compromise a SecurID-protected system without having physical possession of the token:

"7. Have my SecurID token records been taken?

For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information."

Overview

The RSA SecurID authentication mechanism consists of a "token"—a piece of hardware (e.g. a token or USB) or software (e.g. a "soft token" for a computer, PDA or cell phone)—assigned to a computer user that generates an authentication code at fixed intervals (usually 30 or 60 seconds) using a built-in clock and the card's factory-encoded random key (known as the "seed" and often provided as an ASCII file). The seed is different for each token, and is loaded into the corresponding RSA SecurID server (RSA Authentication Manager, formerly ACE/Server) as the tokens are purchased. The seed is typically 128 bits long. Some RSA SecurID deployments may use varied second rotations, such as 30-second increments.

The token hardware is designed to be tamper-resistant to deter reverse engineering. Despite this, public code has been developed by the security community allowing a user to emulate RSA SecurID in software, but only if they have access to a current RSA SecurID code, and the original RSA SecurID seed file introduced to the server. In the RSA SecurID authentication scheme, the seed record is the secret key used to generate one-time passwords. "Soft tokens" are merely commercial software implementations of the same algorithms implemented in the tamper-resistant hardware, only the soft tokens require the seed record to be distributed to clients so that the seed record may be used as input in the one-time password generation. Newer versions also feature a USB connector, which allows the token to be used as a smart card-like device for securely storing certificates.