Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Once inside, they leapfrogged between the accounts of different Citi customers by inserting various account numbers into a string of text located in the browser's address bar. The hackers' code systems automatically repeated this exercise tens of thousands of times — allowing them to capture the confidential private data.
-- The
New York Times with an interesting definition of "ingenious"
The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said.
But some RSA customers say they still don't have enough information from RSA to determine whether they are actually at risk. RSA still hasn't come clean with all of the details on what the bad guys stole. If the seeds were compromised, for instance, then SecurID customers who replace their tokens might have to do so again at another time.
-- Dark
Reading
"Customers need to ask RSA why new tokens matter. Does getting a new token mean I'm more secure? That's the question that needs to be asked," says Marcus Carey, a security researcher with Rapid7. "Companies need to know that this isn't a 'token' gesture."
One thing should be noted; the attacks against Sony are not coordinated,
nor are they advanced. Sony has demonstrated they have not implemented what
any rational administrator or security professional would consider "the
absolute basics". Storing millions of customer's personal details and
passwords without using any form of encryption is reckless and
ridiculous. Even security books from the '80s were adamant about encrypting
passwords at the very least. Several of Sony's sites have been compromised
as a result of basic SQL injection attacks, nothing elaborate or complex.
-- "Security
Curmudgeon" in "A concise history of recent Sony hacks"
We've created a culture of self-perpetuating paranoia in
military-industrial data security by building systems that are deliberately
compromised then arguing that draconian measures are required to defend
these holes we've made ourselves. This helps the unquestioned three-letter
agencies maintain political power, doing little or nothing to increase
national security, while at the same time compromising
personal security
for all of us.
-- Robert
X. Cringely(Log in to post comments)
Security quotes of the week Posted Jun 16, 2011 8:18 UTC (Thu) by Thue (subscriber, #14277) [Link]
Calling the attack "especially ingenious, security experts said" is obviously security experts paid by Citibank.
It is shameful that the New York Times and other media is letting Citibank get away with that.
Security quotes of the week Posted Jun 17, 2011 17:27 UTC (Fri) by nicooo (guest, #69134) [Link]
It's more likely that they work for the NYT.
At least that's how CNN does things. Whenever something happens they come up with a panel of experts to cover the story.
Security quotes of the week Posted Jun 17, 2011 19:31 UTC (Fri) by raven667 (subscriber, #5198) [Link]
A friend of mine's non-technical spouse performed this same kind of hack a decade ago to win a free coffee maker in some online contest, it's not exactly rocket science.
Security quotes of the week Posted Jun 16, 2011 16:52 UTC (Thu) by fuhchee (subscriber, #40059) [Link]
Mr. Cringely's conclusion may be compelling, but appears to be thinly supported by his article.
Security quotes of the week Posted Jun 17, 2011 20:43 UTC (Fri) by kjp (subscriber, #39639) [Link]
RSA gets an epic fail for not using public key crypto with its tokens. There should be nothing to steal on the servers.
Security quotes of the week Posted Jun 17, 2011 20:52 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
you do realize that these tokens are really cheap devices, they don't have the processor power to do Public key encryption.
Security quotes of the week Posted Jun 17, 2011 23:02 UTC (Fri) by njs (guest, #40338) [Link]
Is there a known way to use public key crypto to generate and verify these 6 digit (~20 bit) signatures?
(Regardless, even given that they're using AES, I don't understand why RSA *had* any useful secrets. Shouldn't the only copies be on the company's internal authentication server? And what else would be worth stealing? The algorithm is well known...)
Security quotes of the week Posted Jun 18, 2011 1:03 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
these aren't really signatures.
the algorithm is something much more similar to
take a seed, combine it with the time, hash the result, then show the user the last 6 characters of the hash and have them type it in
when the time changes, repeat the process to generate a new hash
so if you are going to produce a server to be able to check the token, it needs to know that seed so it can see if the numbers shown by the token (and entered by the user) are correct or not.
they then have a database that maps the serial number of the token to the seed that was used to program that token (since having the seed printed on the token would defeat the security as the algorithm is known)
it's this database of serial number -> seed mappings that was stolen, andthis lets anyone duplicate a token if they can find the serial number of the token
no real encryption in use anywhere here, let alone something as computaionally expensive as PKI
there are other tokens on the market that don't have a pre-generated key in them, and the key is loaded in when the token in programmed for the user, but they are more expensive than the RSA secureID tokens (and have a much smaller market share)
Security quotes of the week Posted Jun 18, 2011 1:16 UTC (Sat) by njs (guest, #40338) [Link]
> these aren't really signatures.
Yes; the OP claimed that this was a bug, and my question was whether and how this bug could be fixed. AFAIU, most public key algorithms don't generate 20 bit signatures, and isn't obvious to me whether they could be fixed to do so, so I'm curious.
> it's this database of serial number -> seed mappings that was stolen, andthis lets anyone duplicate a token if they can find the serial number of the token
Is this actually known for sure? (The public technical information on the attack seems to be shamefully scarce.)
And if it is, my point was that there's no reason RSA should *have* this database. I'm pretty sure Lockheed-Martin's login servers do not go talk to some servers administered by RSA whenever they need to verify some token hash; I think Lockheed-Martin has their own internal database of those seeds that they use for day to day use, and if RSA was keeping a backup for them then that's a pretty shocking security error.
Security quotes of the week Posted Jun 18, 2011 8:00 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
it's not that RSA keeps a copy of the lockheed tokens, or that lockheed contacts RSA for every authentication, but when you configure the lockheed server to handle a token, somehow you have to give the lockheed server the seed for the token, and for that I believe that the lockheed server looks up the seed from the serial number in the RSA database
I do not know what this mechanism is, so I am not pretending to be right in the details here, but I'm pretty sure that the general shape of things in along the lines I am talking about
Security quotes of the week Posted Jun 27, 2011 11:02 UTC (Mon) by robbe (guest, #16131) [Link]
>> it's this database of serial number -> seed mappings that was stolen, andthis lets anyone duplicate a token if they can find the serial number of the token
> Is this actually known for sure?
It is assumed by most parties that know the system. What else is there to steal? The algorithm, although not exactly published, is known in principle, and could be reverse-engineered by looking at the server component (and probably has been).
> there's no reason RSA should *have* this database.
RSA wanted to be able to re-send a customer his seeds should they get lost (by the customer, or in transit). I better approach would have been:
* Keep seeds of tokens sold during the last X months in a medium-security DB, that can be accessed by support personell. Seeds are resent on customer request for free during this time.
* Keep seeds of tokens between X and Y months old in a high-security, offline location. Customers can still get these seeds, but have to pay for the higher effort RSA incurs to dig them out.
* Do not keep seeds of tokens older than Y months. Customers that would need these have to trade in their tokens against new ones, at considerable cost (maybe up to the full cost of new tokens).
X and Y are minimised while still trying to piss off the least amount of customers. I do not have data how often this seed resend operation is requested, but gut numbers would be X=2, Y=12.
Security quotes of the week Posted Jun 27, 2011 10:48 UTC (Mon) by robbe (guest, #16131) [Link]
> no real encryption in use anywhere here, let alone something as computaionally expensive as PKI
Well, they use AES as a hash function. Don't know if that counts as encryption. It is certainly symmetric.
> [other tokens] are more expensive than the RSA secureID tokens
Not really. Would not make munch sense either, as RSA is the market leader (as you mention), and since it's difficult to be "more secure" (until recently, that is), most other vendors chose to be more affordable. SecurID tokens start at € 60. SafeNet eToken 30x0 sell for € 32. These are list prices excluding VAT for small quantities. No particular endorsement, I just had these numbers handy.
In an early post you spoke about "cheap devices". They aren't. PKI is easily possible in HW with this price tag. See smart cards that sell for less. Have not thought about whether it would by any more security, though.
|
|||||||||||||