You have to consider the silence and lack of detail is because of something. A strong password is ok as one factor but the whole point of a OTP is to increase the complexity for the attacker by more than doubling it.
It's been a week since RSA dropped a vaguely worded bombshell on 30,000 customers that the soundness of the SecurID system they used to secure their corporate and governmental networks was compromised after hackers stole confidential information concerning the two-factor authentication product. For seven days, reporters, …
Everywhere I've worked that uses RSA secureid tokens for external access has the following process...
1. Get token for user
2. "salt" number created from a subset of the digits displayed on the device at a point in time and told to IT - presumably so the end user doesn't choose something stupid.
3. User logs in with username, password, salt + current displayed digits.
Even if you can predict the digits and you've got the user's username and password you still need that salt number too and any commercial/corporate network will lock-out long before you could brute-force it. Do others use the tokens in a less secure manner?
Obviously this weakens things a lot but you still need to link a user to a token then predict the token value as well as obtain their credentials - seems like you'd find an easier way in using cold hard currency.
Step 2 is wrong. You don't tell the IT person the next number: the IT person tells you to use the first or last 4 digits from the next number to be displayed by the token. That way the IT person never gets to see it.
The salt embedded in the token is unaffected by this and it is that - or the mapping of that to the token serial number - which may have been compromised but RSA are not saying.
I've had Securid key tokens from different companies. One gave me the salt (I think of it as a PIN) on a piece of paper, the second gave me the URL of an identity management panel where I was directed to enter a PIN of my choosing. Neither required a password in addition to the PIN+current displayed digits.
What I'm putting forward is that perhaps one of the factors isn't compromised. If you used this salt+current number method along with network username and password then I don't believe the RSA token is compromised due to 2 parts being necessary for this one factor. Perhaps the current number part may be but then you don't know the salt or the username and password. Either way I think you're better off trying raw currency that hitting up a system with access logging and account lockout.
I've already had several salescritters ring me up and e-mail me to say "SecureID is totally broken, come and talk to us about this new security product you've never heard of before - oh, and we just happen to be exclusive UK disties".
If I'm being targeted this way, you can bet that they've got elevator pitches ready for people further up the food chain - and my employer doesn't even use SecureID.
You can even bet that some CxO's in some organisations are asking their IT people "who owns this RSA mob, and do we have any more of their stuff ?" - the loaded question that really means "Can we move away from these guys if we have to ?"
(Yes, yes, I know that means their SAN hardware, VMware, Legato, Documentum and whatever else they've assimilated since I last blinked - but even so, it's going to be asked in some places)
Flames, because somebody at EMC must be feeling the heat right now...
SecurID tokens effectively have only 5-digit serial numbers (the first 4 digits are the expiry year), and tokens are apparently issued to end customers in consecutive blocks. Since SOP at most of the companies I've worked with is to assign the last 4 digits of the serial number as the PIN, the safest thing is to assume that the SecurID system no longer provides ANY protection against the unknown parties that hacked into RSA's insecure network.
Looking at the three securid tokens i have currently, the serial number is 9 digits long.
The expiry date is 02/28/14.
The serial number begins 2106.
There is no correlation between the expiry date and the serial number.
So "SecurID tokens effectively have only 5-digit serial numbers (the first 4 digits are the expiry year)" is bollocks. I also don't know anyone who issues pin numbers based on the serial number of the token. Anyone who does is an idiot. There is no need for anyone except the end user to know the pin, not the RSA admins, not the IT director, nobody else. There is literally no need for anyone else to know it. There are mechanisms to generate a PIN without the admins knowing it, but for the end user to know it.
You cannot blame a technology for a failure to implement a technology properly on the part of the people implementing it. You might as well say UNIX passwords are intrinsically broken because someone set the root password as "password"
All that said, I entirely agree with the general tone and thrust of the article, RSA have been done and their token security is seriously compromised.
The only thing we've done so far is to e-mail all of our SecureID users and re-iterate good practice in big letters, i.e.: don't write down or tell anyone your PIN or serial number...
I don't think abandoning RSA is an option, budget-wise. But we're very keen to hear what's going on...
But not one shred of decency. Honesty has to be the watchword of a company in that industry, surely? If fatally compromised, pack up the system and call it a day. No other approach. Big money sue, but bigger if they stay silent and other companies fall one by one.
"Cryptogeddon" - it's well and tru.y ON.
If hackers really did get to the crown jewels, thus compromising SecurID's security, RSA shouldn't hestitate for even a moment to reveal this information publicly. They cannot be taken seriously as a security vendor if the security of their customers is not their highest priority.
I would have thought the best option would be for them to assume the worst - yes, by all means refresh customers' memory regarding best security practices, but how about also telling them something along the lines of 'While we investigate, assume SecurID is broken and take necessary measures to mitigate its loss', as opposed to keeping quiet and hoping for the best.
I also work at RBS and our intranet page on the issue is very clear. RSA have been in touch and there is no stolen data that could compromise our SecureID tokens. It goes on to say that our IT security (and RSA) _really_ want to know if anyone approches us in any way (in public, on facebook, etc, etc) presumably because this would create a trail back to the people who hacked RSA.
I wonder if lots of the contact from RSA to companies has been very hush hush? After all, if they're discussing ways to try to find out who the hackers were, they maybe don't want to broadcast what they're doing?
LOL, just LOL.
After all the standard advice of not writing down PINs, these companies make it easier by using PINs that are already written down. And on the token itself!
I used to laugh because my great gran had the password to her money box etched into the top surface, but now it's SOP? LOL.
Not only using the didits in the serial number, but only using a 4 digit PIN in the first place. RSA terminology has a lot to answer for here - tell people to think of a PIN and they immediately think 4-digit number, when in fact it can be alpha numeric and longer than 4 digits - they used the wrong words, they should have called it 'password' which is what it is.
" RSA terminology has a lot to answer for here - tell people to think of a PIN and they immediately think 4-digit number, when in fact it can be alpha numeric and longer than 4 digits - they used the wrong words, they should have called it 'password' which is what it is. "
It's not just that -- long-term SecurID users will remember the limit credit-card sized SecurID tokens with an onboard keypad for PIN entry, and the PINs were therefore restricted to 4-digit numerical PINs.
Even when overhauling technology, there's an attempt to paint it as the same thing -- RSA presumably didn't want to scare people off by changing the process too much and making it seem like something new....
The correct way to do it is to issue the token in new pin mode, ie, without a pin. First time it's used you'll be prompted to choose a pin, which is then set. That's assuming you can securely get the token to the end user. If not the RSA admins can set the PIN to be the last 4 digits of the next tokencode to show up (or last 6, whatever). The end user waits for it to change, remembers that PIN, the RSA admin never knows it, and there's no way to output the upcoming tokencodes.
Unless you happen to have nicked the seed files, and the source code that is ....
Every company that I've worked for has given me a token with a PIN delivered separately, the token has to be activated from *inside* the corporate network and the first thing you have to do is change the supplied PIN.
The lack of security by design in companies you have worked at, doesn't reflect on RSA.
If RSA has had a breach of both the seed and mapping - it should be absolutely possible for them to discard the compromised seed and the mapping key. Then they can create a new seed, a new mapping key and start issuing new tokens to ensure their customers remain secure.
Paris also has some trouble securing her intellectual property...
We'd all like to hear "Existing tokens can now be compromised by revealing the serial number; Don't do that. Increase your second factor security for the time being. We're generating new seeds and buying new tokens in as we speak. Japan silicon fab'ing being down has made this slow, but not impossible. Be patient, and contact your supplier for availability of patches and tokens. There will be no charge for replacement of tokens."
What we have instead is week-long silence on an important issue, specifically affecting one of the most paranoid groups of people in the world (IT security folk and network admins). It couldn't be a more idiotic move on their part.
Just because Iran is on many countries bad list why pick on them? All of a sudden they have unbefore heard of expertise whereas China, Russia and a few others have the knowledge and have used it before.
Let's have the proof so we can judge the accuracy of the accusations.
You missed out
3) They disclose full details of the compromise, spend a boat-load of their own money reinventing their infrastructure, and issue "new everything" to all existing customers free of charge.
That *might* be sufficient to restore faith.
I imagine Comodo will be watching closely.
It's all perfectly true, you know, but you just don't want to believe it, or are not smart enough to realise it :-) Does that mean that they think we are stupid and easily fooled? Are they wrong or dead right? And who exactly are they when they are at home? ...... http://www.theonion.com/video/cias-facebook-program-dramatically-cut-agencys-cos,19753/
IT's only Sp00fing of course, isn't it, and all part and parcel of the New Reality for CHAOS, that Conflicts with the surreal shaming and blaming of dumb traditional spooks lurking in the shadows, with Novel News and Fab Views of what can be done whenever hiding in plain sight and hanging out with nerds and geeks and the free-willed and free-wheeling chicks ...... the Post Modern Future Fundamental and Elementalist Meek into Cryptic XSSXXXXistentialism for Mass CritICQuality?
Crikey .... Friday again, already. Where does Time fly away to?
So you effectively hold the keys to the world corps networks via the SecureID mechanism and you place this info somewhere where someone managed to obtain it illegally?
No matter what happens it'll be a slap on the wrist and business as usual, just like the loss of USB keys with details of the vulnerable and just like the leaking of credit card details, the losses get bigger and bigger, the interest in dealing with them goes down.
Does anyone with any clout care any more enough to haul these cretins through the justice systems? This is our data being exposed and it's just another "naughty cock-up", tee-hee! Sooner or later when someone asks me what I do for a living I won't tell anyone I work in IT, I'll lie and say something like I pick up dogs**t on the local streets for the council, at least I might get some respect rather than be thought of an IT bozo who can't stop losing personal info on computer systems.
And so speculation (which is *all* pretty much all the comments are) fills the space instead.
This *both* a technical *and* marketing fail.
Technical because they appear to have assumed that this information would *never* get out. If you're going to behave in that way you'd better be *very* paranoid about where you keep it, who has access to it (does you CFO *really* have that MBA from Harvard?), what it's connected to (nothing preferably) and what information can be downloaded from it and to what output media. Not to mention having an *equally* secure backup system elsewhere in case of earthquake/flood/terrorist assult/whatever.
Given that these are the *core* components of what makes RSA valuable to *customers* even the *impression* that they have fallen into the wrong hands does severe damage to the reputation of the brand.
It's a Marketing fail because when the s**t happened (so much for the assumption) they appear (and that's *all* we can say about their response) to have *no* plan in place to handle this. Which suggests
a) They are making it as they go along in full headless chicken mode. Might be serious. Might not be *less* serious but they can't *quite* find the right words, or get approval to say them.
b) It's *really* bad and they they *can* fix it but their customers are going to take a *lot* of pain.
c) It's *really* bad and they can't fix it as who needs a backup up plan for something which will *never* happen? IOW They be f**ked (and so are their customers).
Anyone remember when Evian got contaminated with Phenol some years ago? Company came clean (no pun intended) within 24 hours. Explained what had happened and what they were doing about it and what customers could do about it.
Result. People continue (rightly or wrongly) to trust Evian as their preferred water supplier.
For a company with turnover in the 100s of $m (billion+?) this is a *very* poor response.