RSAis a multi-factor authentication (MFA) technology that is used to protect network services. The RSA authentication mechanism consists of an assigned hardware or software "token" that generates a dynamic authentication number code at fixed intervals. Users provide the unique number code when logging into a protected service from any network outside the State network.
Please answer the five security questions (answers are not case sensitive). Select "Submit Your Request." Security questions allow you to unlock your account without assistance and provide future verification of user authentication.
First-time software token users are required to install the Microsoft Outlook App on mobile devices and add your email account (refer to Steps 1 and 2). Users who have already installed the Microsoft Outlook App should proceed to Step 3.
Note: Once the app is installed and your email account has been added, you will occasionally be prompted to re-enter your credentials and RSA token code to access email via the app. Refer to steps 3 and 4.
Note: Once the app is installed and your email account has been added, you will occasionally be prompted to re-enter your credentials and RSA token code to access email via the app. Refer to steps 3 and 4.
If you forget or need to change your PIN, log into the Self-Service Console using your email address and password, then click "Troubleshoot," select "I forgot my PIN." At the next screen, enter your new PIN and confirm.
For a software token (e.g., the RSA app), your token code is the eight-digit number generated after entering your PIN on the RSA app. On your software token, the token refreshes every sixty seconds. If you have difficulty logging in after providing the token, ensure the correct PIN was entered.
Your hardware token generates a random, six-digit number every sixty seconds. Your token code in this case is your PIN followed the generated number (the six random digits) from the hardware token, with no spaces between them.
Instead, users can have the token from their old phone redistributed to their new phone. Call the NYS Helpdesk at
844-891-1786, and after proper verification, the NYS Helpdesk or appropriate Zone Tech can redistribute the token to the user's new phone.
Go to , and do not log in. Click on "Troubleshoot RSA Token." Enter your email address and answer the identifying questions. Upon submission of correct answers, your RSA account will no longer be locked.
After entering too many incorrect passcodes, you may be required to enter a next token code. If using a software token, wait and then enter the next available token code shown. If using a hardware token, wait and then enter the next available token code shown (random 6 digits). Do not enter your PIN + the token code.
My workplace uses these SecurID tokens which provide you with a temporary password, the code will expire after a short time. I have always been fascinated by the things, because it seems as though all the logic to calculate the next number must be physically located inside the device.
Given physical access to the token, is it possible to predict the numbers? How?Without physical access, is it theoretically possible to predict future numbers from previous numbers, with or without knowledge of the seed?
On March 2011, some systems have been compromised in RSA, and it seems probable that the attackers manage to steal one or a few master seeds (it is plausible that the devices are built in "families" so there are several master seeds). RSA has stated that 40 millions SecurID tokens must be replaced. If you know the serial number of a token (it may be printed on the outside of the token), you can use the Cain & Abel tool that @dls points to; presumably, that tool implements the leaked algorithm and master seed(s), and can thus produce the future token outputs (I have not tried it). This would work only with servers which still accept the tokens from the 40-million batch which is to be replaced. I do not know how far RSA and its customers have gone in this process, so it may be that this attack will not work anymore. It really depends on the reactivity of the people who manage server you attack.
(If these system administrators have not replaced the compromised devices after nine months, then chances are that they are quite lax on security issues, and the server may have quite a few other remotely exploitable security holes.)
If you have its secret information, you can generate the numbers just as it would. If you do not, it's theoretically possible to make predictions based on what you've seen because the numbers are mathematically related. However, their relationship is complex enough that it is believed to be computationally infeasible to do so. That is to say, the amount of computation needed to make that prediction would take substantially more time than the lifespan of the token. If, for example, an average token were replaced every 10 years, an algorithm which computes its secret information or its series of values which takes a billion years to run when run in parallel by all known computers would be unhelpful in practice.
This computational infeasibility is the fundamental basis for all useful mathematical cryptographic systems. But in all cases, all we have are cryptographic tools where reversing them or solving for their secret information is believed to be computationally infeasible. New discoveries may reveal that some schemes are easier to break than were believed.
If you know the seed, you have a chance to work out the passcode (the temporary code displayed). But all the devices are given a random seed when they are manufactured, and the seed value is not stored anywhere.
Even if you own an Authentication Manager, you cannot guess the passcode since only the Admin can upload the token list. The information on this list is necessary to generate the passcode for a certain SecurID or Soft Token. If On-Demand Authentication is enabled, the user can request a passcode via SMS or email, but the code is still based on the token that is assigned to the user.
The token hardware is designed to be tamper-resistant to deter reverse engineering. When software implementations of the same algorithm ("software tokens") appeared on the market, public code had been developed by the security community allowing a user to emulate RSA SecurID in software, but only if they have access to a current RSA SecurID code, and the original 64-bit RSA SecurID seed file introduced to the server.[3] Later, the 128-bit RSA SecurID algorithm was published as part of an open source library.[4] In the RSA SecurID authentication scheme, the seed record is the secret key used to generate one-time passwords. Newer versions also feature a USB connector, which allows the token to be used as a smart card-like device for securely storing certificates.[5]
While the RSA SecurID system adds a layer of security to a network, difficulty can occur if the authentication server's clock becomes out of sync with the clock built into the authentication tokens. Normal token clock drift is accounted for automatically by the server by adjusting a stored "drift" value over time. If the out of sync condition is not a result of normal hardware token clock drift, correcting the synchronization of the Authentication Manager server clock with the out of sync token (or tokens) can be accomplished in several different ways. If the server clock had drifted and the administrator made a change to the system clock, the tokens can either be resynchronized one-by-one, or the stored drift values adjusted manually. The drift can be done on individual tokens or in bulk using a command line utility.
RSA Security has pushed forth an initiative called "Ubiquitous Authentication", partnering with device manufacturers such as IronKey, SanDisk, Motorola, Freescale Semiconductor, Redcannon, Broadcom, and BlackBerry to embed the SecurID software into everyday devices such as USB flash drives and cell phones, to reduce cost and the number of objects that the user must carry.[7]
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 attacks, they are not designed to offer protection against 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, he 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 (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.[8] 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 SSL.
Although soft tokens may be more convenient, critics indicate that the tamper-resistant property of hard tokens is unmatched in soft token implementations,[9] which could allow seed record secret keys to be duplicated and user impersonation to occur.
3a8082e126