A news item involving RSA SecurID was featured on Wikipedia's Main Page in the In the news section on 8 June 2011. |
This article has not yet been rated on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
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.
Surely it's pseudorandom Rojomoke ( talk) 11:33, 15 September 2008 (UTC)
How is the seed file loaded into the token? JIP | Talk 16:50, 15 November 2006 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
The overview says 25M, the report about the weakness says 40M. Surely one is wrong. -- SGBailey ( talk) 13:10, 8 June 2011 (UTC)
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)
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
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).
Cheers. — cyberbot II Talk to my owner:Online 00:26, 18 October 2015 (UTC)
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)