Slashdot Mirror
Researchers Can Generate RSA SecurID Random Numbers Flawlessly
Fluffeh writes "A researcher has found and published a way to tune into an RSA SecurID Token. Once a few easy steps are followed, anyone can generate the exact numbers shown on the token. The method relies on finding the seed that is used to generate the numbers in a way that seems random. Once it is known, it can be used to generate the exact numbers displayed on the targeted Token. The technique, described on Thursday by a senior security analyst at a firm called SensePost, has important implications for the safekeeping of the tokens. An estimated 40 million people use these to access confidential data belonging to government agencies, military contractors, and corporations. Scrutiny of the widely used two-factor authentication system has grown since last year, when RSA revealed that intruders on its networks stole sensitive SecurID information that could be used to reduce its security. Defense contractor Lockheed Martin later confirmed that a separate attack on its systems was aided by the theft of the RSA data."
"When the above has been performed, you should have successfully cloned the victim's software token and if they run the SecurID software token program on your computer, it will generate the exact same random numbers that are displayed on the victim's token," Fouladi wrote.
Good job leaving the word software out of the summary there in the /. lead in.
Now I don't have to worry about forgetting to bring home the RSA token for my company's VPN. I can just leave it under the keyboard with all my password post-its!
:wq
This applies to software tokens only.
and they aren't doing it by reverse engineering RSA software, but rather exploiting windows API's.
This attack doesn't actually rely on any of that - it's akin to photocopying all the one-time pads you've given to the user. To say that this is bidirectional cryptography is misleading at best.
DNRTF
If it's about figuring out the algorythm used by their SecureID fobs, this is old news. At the last job during a PCI audit, the auditor was showing off the pen test tools he downloaded for free off the net. I think it was Cain and Able had a tool that did this; as long as you knew the serial numbers on the back (a brief amount of physical access or social engineering) it would report back the six digit number the fob was displaying. Obviously you still need the other parts of the credentials, but the algorithm used by the fob was already broken.
This has nothing to do with randomness. For example, you could use numbers that are random (or as good as random) by sampling background radiation and still run into the same issue. The problem lies in the fact that those samples need to be shared. You can't log in if the server isn't using the exact same number sequence as your token. The seed provides the means to get the number sequence; replacing the seed with the data from your radiation sampler might be good in that it's probably harder to hackers to access, but it doesn't change the fundamental nature of the issue.
Key point from TFA "was easy for people with control over the machines to deduce and copy"
If anything is running on a computer it is possible to probe it and figure out what it is doing and duplicate it if you have complete control over it. It does not much matter what it is how fancy an algorithm is being used or how it is configured.
If you want something to stay secret then it needs to self destruct when someone tries to fuck with it or anything it depends on to work.
Reminds me of the outraged cries of those 1337 few over the years who independantly discovered operating system x must be defective since you can bypass password authentication or access controls by mounting an unencrypted hard disk in a different computer. No shit.
I have never understood why software tokens have been allowed to be considered a "factor" in multi factor authentication. Particulary when it is stored on the same laptop/computer that the user is utilizing to connect to the secure resource. Doesn't it make more sense to have each factor seperated by an air gap or alternate communiation channel? That way if the system where the users is typing a password is compromised only the password is compromissed with possibly the ping from the token which would be a one time key. Even if the one time key and the password are comprimised the attacker basicly has to use it at the same time.
If this is what "security researchers" get paid to do, sit around and state the obvious, I am in the wrong career field.
sudo make me a sandwich
Yes
Solved with public/private key pairs (long ago), short version:
Server publishes public key and has internal copies of its private key and all authorized users' public keys.
User wants to authenticate, server challenges with a unique nonce (sampled from background radiation, or whatever) authenticated with server's private key if you're paranoid.
User responds with self-authenticated version of the nonce, possibly encoded with server's public key for good measure.
The only hole is key control, which is where the two+ factor stuff starts playing in.
I know this is Slashdot, but this thread is taking "TL;DR" to whole new places.
The news isn't that RSA's algorithm is out in the wild. Without the account-specific sequence generation seed value, the algo is worthless.
The news is that the researches have examined the Windows software version of the access code generator ("software token") and figured out how to extract the seed value out of a specific installation. With that seed value, you can take another copy of the software token and clone the key generation sequence of the first, allowing you to spoof the other token's identity.
This is why most RSA installations I know of also require the use of a PIN concatenated with the token-generated number. That way, coaxing the code out of the software token isn't enough to authenticate as the identity of the person the token is assigned to; you have to guess the PIN as well (maybe by looking under keyboards).
I guess the real story is "soft tokens don't protect their internal secrets as well as hardware tokens".
Welcome to the Panopticon. Used to be a prison, now it's your home.
I read TFA.. the algorithm is not broken and the seed isn't deducible from the output; all they've done is read the seed out of software auth running on a general purpose computing device.
This has always been possible in theory -- obviously, the computer software has to generate the output so it must have the seed in an accessible form; probably under several layers of obfuscation and encryption (which ultimately adds no security, as the software still has to be able to wade through it to get to the seed). It's very similar in concept to someone being able to obtain your PGP or SSH private keys if they have local access to your system.
There is no risk to people with a hardware auth device, unless the server is compromised (in which case this form of authentication is useless anyway).
Also, if you happen to notice a block of bricks overhead, jump up and hit it with your head.
This space available.
It could theoretically be a custom ASIC, in which case it's not really a processor running a program as much as a physical embodiment of the program.
Wow, this is one of the worst summaries I've seen in the last 2 days on /.
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.