RSA SecurID is trusted two-factor Authentication protocol often used to authenticate VPN clients enabling users to login to secure servers. Every physical RSA Secure ID device (Figure 1 below) has a unique serial number written on the back of the device.
During manufacturing individual SecurID devices are assigned a random 128-bit secret key with the manufacture maintaining a database that map the device’s externally visible serial number to its internal 128-bit secret key.
Figure 1: RSA SecurID Device
For every 60 seconds, the processor in the SecurID device takes in a 64-bit current time and 128-bit seed record that generates a very large number (via algorithm) that is finally hashed down to produce 6 or 8-digit output.
The algorithm typically used during this step is based on the AES-128 Symmetric cryptography standard. Though confusing, it is important to note that this has no resemblance to RSA public key cryptography that is based on Asymmetric keys or Public-Private key pair. Nonetheless, from the 8-bit output, it is impossible to reverse engineer to generate the 128-bit seed record.
As shown in Figure 2, below , token code generated is supplied to the website or VPN Client that pass the token to the authentication server run by RSA. Once the user enters the username, RSA takes in the user-name and searches their database to find what seed record is associated with the token and runs the same hashing algorithm thereby taking in current time and seed record to generate the 8 digit output that must match the 8 digit output entered by the user along with the username. Once matched, user is allowed access to the remote server.
Figure 2: Secure ecosystem and dataflow around RSA SeureID ( To view larger image, click here)
If numbers don’t match, server will take the current time and add a minute and generate another 8 digit number. Server will also remove a minute from the current time and come up with another 8 digit number.
If either of these numbers match, server will treat it as right token assuming clock to have slightly drifted. Clock can often drift due to different environment conditions between the user and the server side. If token is running one minute fast, server will store the settings for the user and when user log-ins at some point in the future, it takes the current time and adds a minute to calculate the 8 digit token output.
In case the token does not match three different passcodes (current time , +1 minute, -1minute), the server then tries the same but with a bigger timing window (current time, +10 minutes, – 10 minutes) . If one of the passcode matches, the server will send a challenge to the user asking the user for the next 8 digit number(next Token code) that appear on the SecurID device
If it is correct, the server will allow the user to login else the process will be repeated all over again. This ensures if attacker happens to guess the passcode once, unless he/she knows the very next number right in the minute, server won’t authenticate the connection. 8-digit passcode would mean 108 combinations that would be impossible to guess in a minute.
Vulnerabilities with RSA SecurID
While RSA SecurID tokens offer a level of protection against password replay attacks by having one time password for each session, they are not designed to offer protection against man in the middle type attacks.
If the attacker manages to block the authorized user from authenticating to the server until the next token code will be valid, he/she 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.
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 attacker's authentication through.
Another related vulnerability includes social engineering attacks via Phishing. Phishing is an example of social engineering techniques used to deceive users, and exploits the poor usability of current web security technologies that is typically carried out by e-mail spoofing or instant messaging, and it often directs users to enter details at a fake website whose look and feel are almost identical to the legitimate one.
In case the attacker manages to get the credentials entered by user in plaintext, it can be quickly used by attacker as the legitimate user before the token expires (within a minute typically).
Alternatively if system uses a hash chain, that cannot be simply used, phisher must then use the information gained (past token codes and the time) to predict token codes that will be used in future incase weak random number or pseudo-random number is used.
Although soft tokens may be more convenient, critics indicate that the tamper-resistant property of hard tokens is unmatched in soft token implementations, which could potentially allow seed record secret keys to be duplicated and user impersonation to occur.
Hard tokens on the other hand can be physically stolen (or acquired via social engineering) from end users. The small form factor makes hard token theft much more viable than laptop/desktop scanning.
Under this attack model, the system security can be improved using encryption/ authentication mechanisms such as Secure Sockets Layer (SSL) that is based on public private key pairing.
Note that for a typical corporate network that deploys SecurID for its employees, RSA only maintains seed-to-serial number mapping. Seed-to-user mapping is typically maintained locally by the client server rather than RSA. So even if hacker manages to get hold of the RSA database that stores all the token, they would not know list of users using the specific token.
What the hacker would need to do is every minute pre-calculate all values of all seed/serials, then intercept some authentication traffic several 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 go through company firewall or do a brute force attack. For a reasonable size organization, this would not be simple attack. On the server side, smart policies should be implemented to be able to restrict the number of tries before token gets locked even though authentication traffic may be through encrypted via SSL.
The other mitigating factor is that in virtually all SecurID deployments, the token is combined with a pin and password. So just knowing the current token code is not enough to break into an account. But, since the attacker will likely need to be monitoring the users they could also monitor the user entering their pin/password (which unlike the token, is a static value).
Even though RSA SecurID is fundamentally secure and reliable, lack of sufficient protection against man-in-the-middle type attacks add some vulnerability, resulting in the connection being compromised.
Under such situation, RSA may recall and re-issue token to all the compromised users but that does not seem to be a good and viable solution. In the future, likely security enhancements (for example using SecureID in conjunction with Public Key Cryptography ) can be expected in future to fix some of these vulnerabilities.