Understanding the security framework behind RSA SecurID
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.
Mohit Arora is a senior systems engineer at Freescale Semiconductor. He can be contacted at mohit.arora@freescale.com.
This article provided courtesy of Embedded.com and Embedded Systems Design Magazine. Sign up for subscriptions and newsletters. Copyright © 2011 UBM--All rights reserved.
Loading comments... Write a comment