Talk:RSA SecurID

SecurID is a two-factor authentication system developed by Security Dynamics (now RSA Security). It is generally used to secure either local or remote access to computer networks. Each SecurID user has a memorized PIN or password, and a hand-held token with a LCD display. The token displays a new pseudo-random value, called the tokencode, at a fixed time interval, usually one minute. The user combines the memorized factor with the tokencode, either by simple concatenation or entry on an optional keypad on the token, to create the passcode, which is then entered to gain access to the protected resource.

The SecurID token is a battery powered, hand-held device containing a dedicated microcontroller. The microcontroller stores, in RAM, the current time, and a 64-bit seed value that is unique to a particular token. At the specified interval, the seed value and the time are combined through a proprietary algorithm stored in the microcontroller's ROM, to create the tokencode value.

An authentication server verifies the passcodes. The server maintains a database which contains the seed value for each token and the PIN or password for each user. From this information, and the current time, the server generates a set of valid passcodes for the user and checks each one against the entered value. For more on SecurID, see http://www.rsasecurity.com/node.asp?id=1155.

The main article has the following statement:

"The SecurID authentication mechanism consists of a "token" -- a piece of hardware assigned to a user that generates an authentication code every sixty 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)."

Is the factory-encoded key really "random"? It seems to have both a pattern and some form of calcluation to generate the number. It may be very complicated but it isn't truely "random" since two separate programs both know the same number at the same time. It is pre-planned.

This is a long winded way of asking whether we should remove the word "random" from the statement above.

The key is random. But the key is provided both in the token and in the server, so the server can simply do the same function as the token, since it has the private key. The point is that by encrypting the time, with the key, you effectively prove that you have the key without revealing what the key is. vidar lo 20:26, 21 August 2006 (UTC)[reply]

Surely it's pseudorandom Rojomoke (talk) 11:33, 15 September 2008 (UTC)[reply]

How is the seed file loaded into the token? JIP | Talk 16:50, 15 November 2006 (UTC)[reply]

The seed file is factory loaded. You are shipped media with the seed files for loading into the server separately, which match up to a given serial number. Leebert 21:24, 26 June 2007 (UTC)[reply]

Criticism section

The article says:

If the second session is established shortly after the initial session, the one-time password will still be valid when the attacker presents it to the server, thus the authentication will succeed.

This, in my experience, isn't true. Tokens are only usable one time, after which the token code is marked as used in the ACE/Server's database.

Honestly, the whole criticism section could use sources, because I think much of it is incorrect or outdated. Leebert 21:27, 26 June 2007 (UTC)[reply]

The article says:

they fail to provide adequate protection against man in the middle type attacks

This presumes that SecurID attempts to provide protection against man-in-the-middle attacks. The tokens generate numbers, and the server validates them; that's it. There need to be other techniques for MITM prevention: SSL, IPSec, etc. I don't think it's fair to criticize SecurID for something it's not designed to do.

Duress PIN

There's documentation on support for a duress PIN at the following link:

http://www.process.com/tcpip/tcpware57docs/User_Guide/ch14.htm#E53E27