From Wikipedia, the free encyclopedia

RSA SecurID is a mechanism developed by RSA Security for performing two-factor authentication for a user to a network resource.

RSA SecurID tokens (older style, model SD600)

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 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 a *.asc 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 of the token. 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.

A user authenticating to a network resource—say, a dial-in server or a firewall—needs to enter both a personal identification number and the number being displayed at that moment on their RSA SecurID token. Some systems using RSA SecurID disregard PIN implementation altogether, and rely on password/RSA SecurID code combinations. The server, which also has a real-time clock and a database of valid cards with the associated seed records, computes what number the token is supposed to be showing at that moment in time, checks it against what the user entered, and makes the decision to allow or deny access.

On systems implementing PINs, a "duress PIN" may be used—an alternate code which creates a security event log showing that a user was forced to enter their PIN, while still providing transparent authentication.

While the RSA SecurID system adds a strong layer of security to a network, difficulty can occur if the authentication server's clock becomes out of sync with the clock built in to the authentication tokens. However, typically the RSA Authentication Manager automatically corrects for this without affecting the user. It is also possible to manually resync a token in the RSA Authentication Manager. Also, providing authentication tokens to everyone who might need to access a network resource can potentially be expensive, particularly as the tokens are programmed to "expire" at a fixed time, usually three years, requiring purchase of a new token.

RSA SecurID currently commands over 70% of the two-factor authentication market (source: IDC) and 25 million devices have been produced to date. But this has not stopped a number of competitors making similar security tokens such as Verisign.

RSA Security has pushed forth an initiative they call "Ubiquitous Authentication", partnering with device manufacturers such as SanDisk, Motorola, Freescale Semiconductor, Redcannon, Broadcom and BlackBerry to embed the SecurID software into everyday devices such as memory sticks and cell phones, in order to reduce both cost and the number of objects the user has to carry around.

Other network authentication systems, such as OPIE and S/Key (sometimes more generally known as OTP, as S/Key is a trademark of Bellcore) attempt to provide the "something you have" level of authentication without requiring a hardware token.

This section does not cite any references or sources. Please improve this section by adding citations to reliable sources. Unverifiable material may be challenged and removed. (June 2007)

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 legal user from authenticating to the server until the next token code will be valid, he will be able to log in to the server.

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.

• Sample SecurID Token Emulator with token Secret Import I.C.Wiener, Bugtraq post.
• Apparent Weaknesses in the Security Dynamics Client/Server Protocol Adam Shostack, 1996.
• Usenet thread discussing new SecurID details Vin McLellan, et al., comp.security.misc.
• Unofficial SecurID information and some reverse-engineering attempts Yahoo Groups securid-users.
• Some articles about RSA Securid Security Blogs

• Cryptanalysis of the Alleged SecurID Hash Function (PDF) Alex Biryukov, Joseph Lano, and Bart Preneel.
• Improved Cryptanalysis of SecurID (PDF) Scott Contini and Yiqun Lisa Yin.
• Fast Software-Based Attacks on SecurID (PDF) Scott Contini and Yiqun Lisa Yin.