Editing RSA SecurID (section)

== Theoretical vulnerabilities ==

Token codes are easily stolen, because no mutual-authentication exists (anything that can steal a password can also steal a token code).  This is significant, since it is the principal threat most users believe they are solving with this technology.

The simplest practical vulnerability with any password container is 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 preset time span of activation. All further consideration presumes 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 attack]]s, they are not designed to offer protection against [[Man-in-the-middle attack|man in the middle]] type attacks when used alone.  If the attacker manages to block the authorized user from authenticating to the server until the next token code will be valid, they will be able to log into the server. Risk-based analytics (RBA), a new feature in the latest version (8.0) provides significant protection against this type of attack if the user is enabled and authenticating on an agent enabled for RBA. RSA SecurID does not prevent [[Man in the Browser|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. This has been documented in an unverified post by John G. Brainard.<ref>{{Cite web |title=Untitled |url=http://malpaso.ru/securid/brainard.htm |archive-url=https://web.archive.org/web/20070928205205/http://malpaso.ru/securid/brainard.htm |archive-date=28 September 2007 |website=malpaso.ru}}</ref> 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. Under this attack model, the system security can be improved using encryption/authentication mechanisms such as [[Secure Sockets Layer|SSL]].

Although soft tokens may be more convenient, critics indicate that the [[tamper resistance|tamper-resistant]] property of hard tokens is unmatched in soft token implementations,<ref>{{Cite web|url=http://securology.blogspot.com/2007/11/soft-tokens-arent-tokens-at-all.html|title=Securology: Soft tokens aren't tokens at all|date=20 November 2007}}</ref> which could 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 (security)|social engineering]]) from end users. The small form factor makes hard token theft much more viable than laptop/desktop scanning. A user will typically wait more than one day before reporting the device as missing, giving the attacker plenty of time to breach the unprotected system. This could only occur, however, if the user's UserID and PIN are also known. Risk-based analytics can provide additional protection against the use of lost or stolen tokens, even if the user's UserID and PIN are known by the attackers.

Batteries go flat periodically, requiring complicated replacement and re-enrollment procedures.