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
these aren't the secureIDs you're looking for
This should be no surprise. The software token in a smartphone or a computer MUST have the seed stored somewhere in the device that the device can read and access.
Which means if an attacker can control the victim's computer, of course the software-based token has no security, only obscurity and hastle.
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.
Score a major government security contract?
Never understood why the hell companies like Lockheed score multi billion dollar deals that they are thoroughly unsuited for.
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.
My death will not stop it, unless my plan succeeds...
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.
This is, in fact, how one-time passwords work. Once upon a time, RSA strengthened the security of their tokens through algorithm obscurity. The only news is that the algorithm cannot be considered obscure any longer. And this news is old. The fact that some random "researcher" learned enough of a programming language to create a program that takes a number and uses it as a random seed is not something that anyone (aside from said "researcher", and probably his proud parents) should care about.
I'm glad I use event-based One Time Password tokens, and not time-based tokens like this (from a different vendor than RSA, by the way).
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.
You don't understand how this particular mechanism works. It is not intended to talk to the server directly or to be connected to a computer (the software version does that simply by virtue of where it's run, but the keyfob doesn't).
It is simply a one-time-use password generator.
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.
OTP/HOTP is the same in software and hardware; to provide (backward) compatibility. Hacking a hardware key is a lot hacker, because it requires more sophisticated materials to read but still, hardware is nothing more but a chip running software. Once the software OTP is hacked, it would drag along the hardware variants of it.
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
But, of course, you can predict SecurID if you know the seed. That's the whole point of how SecurID and all other token security systems work.
It's like saying that a one-time pad is broken if you have the predetermined list of keys. Of course, that's the whole point.
Kriston