Talk:RSA SecurID

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

meant for editing[edit]

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. vidarlo 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]
They could, for example, roll dice and then encode the result into the key and database. Just because there are two copies doesn't make it less random. Gah4 (talk) 04:18, 25 April 2023 (UTC)[reply]

Criticism section[edit]

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]

It is possible, though unlikely. The server side keeps track of the last tokencode used and communicates that to the other server instances. That last tokencode and any previous are no longer valid. In v7.1 and above, the servers use an Adjudicator to transmit that high-water mark to the other servers in near-realtime. If the adjudicator port is blocked, the high-water mark will still be sent to the other instances, but this process is slower (usually a few seconds). The attempt to re-use a tokencode is called a "replay" and is only possible on multi-instance systems (systems with a Primary and at least one Replica). If the replayed tokencode reaches an instance before the original instance communicates the new high-water mark, then it is possible to successfully authenticate using a previously-used tokencode. [1] Glenn.e.williams (talk) 15:27, 18 June 2014 (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.

Yes it's fair, it's designed to protect, and fails badly in the face of modern attacks. People reading this article need to know the security holes. 120.151.160.158 (talk) 11:21, 22 April 2013 (UTC)

References

  1. ^ http://www.emc.com/collateral/15-min-guide/h12284-am8-setup-config-guide.pdf
We could criticize Medeco as thieves could smash a window and climb in. But we know that a key can't stop that. We can criticize RSA for not mentioning it often enough, though. Gah4 (talk) 04:22, 25 April 2023 (UTC)[reply]

Duress PIN[edit]

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

http://www.process.com/tcpip/tcpware57docs/User_Guide/ch14.htm#E53E27 —Preceding unsigned comment added by 208.92.44.113 (talk) 20:54, 18 November 2009 (UTC)[reply]

While it is true that the documentation at that link describes Duress Pin functionality, it is an integration with a very old version of SecurID (v2.2). As stated in the article, currently supported (and even v5.2 which went EOPS in March 2010) do not support a Duress Pin. Glenn.e.williams (talk) 15:49, 18 June 2014 (UTC)[reply]

Contradiction[edit]

In overview - "25 million devices have been produced to date"
In "March 2011 system compromise" - "On June 6, RSA has admitted that all 40M tokens need to be replaced"

Is the first statement out of date, or is it based solely upon "base" devices (not 3-year replacement)? - Tenebris 21:35, 7 June 2011 (UTC)

Why did RSA have the token seeds?[edit]

Could someone add an explanation about why RSA had these token seeds at all? Was it key escrow? Wnt (talk) 01:08, 8 June 2011 (UTC)[reply]

RSA has the seeds so that they can compute the expected number from the user. It is an interesting question, whether a one-way encryption system could be used for protection against leaked seeds. Gah4 (talk) 04:26, 25 April 2023 (UTC)[reply]

First para of Overview[edit]

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 computer, 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 an ASCII 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.[citation needed]

"It consists of a token - a piece of hardware EG a token." What help is that?

"It consists of a token - a piece of hardware EG USB." Whatever a SecurID is, it isn't a universal serial bus (though it may use such as part of connecting it to a computer.)

"It consists of a token - software EG a soft token." What help is that?

"Some RSA SecurID deployments may use varied second rotations, such as 30-second increments." What is a varied second rotation. what is a 30-second increment - We've already said it does its thing every 30 or 60 seconds, so what does this mean.

That entire paragraph needs rewriting by someone who knows whata SecurID is./ -- SGBailey (talk) 13:04, 8 June 2011 (UTC)[reply]

Quantity of devices[edit]

The overview says 25M, the report about the weakness says 40M. Surely one is wrong. -- SGBailey (talk) 13:10, 8 June 2011 (UTC)[reply]

What is Risk-Based Analytics (RBA)[edit]

In the "Theoretical Vulnerabilities" section it says:

Risk-based analytics (RBA), a new feature in the latest version (8.0) provide significant protection against this type of attack

. I can find no reference to that technology anywhere on wikipedia or on the internet. — Preceding unsigned comment added by 38.105.216.129 (talk) 18:29, 11 June 2014 (UTC)[reply]

RBA does a silent evaluation of web-based authentication attempts. It evaluates user behavior and device identification to grade the authentication. If this score does not meet the assurance level, a step-up authentication would be required (Either Life Questions or an out-of-band on-demand tokencode). [1]

References

  1. ^ http://www.emc.com/collateral/15-min-guide/h12284-am8-setup-config-guide.pdf (page 68)

External links modified[edit]

Hello fellow Wikipedians,

I have just added archive links to one external link on RSA SecurID. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —cyberbot IITalk to my owner:Online 00:26, 18 October 2015 (UTC)[reply]

A Commons file used on this page has been nominated for speedy deletion[edit]

The following Wikimedia Commons file used on this page has been nominated for speedy deletion:

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 03:52, 13 January 2019 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:RSA_SecurID&oldid=1200989992"