Cringely has a strange article which continues the RSA SecureID attack mystery: InsecureID: No more secrets?. I can’t say I’ve ever read Cringely before, so maybe he’s just some tech commentator with no real insight here other than a wide following and sensational, wild speculations… (After writing this, scanning his recent articles pretty much shows me he’s just a tech blogger and that’s it. Yes, I mean it when I say that’s “it.” And yes, I’m being ornery today and particularly spiteful in my dislike of tech commentators dipping a crotchety toe into deeper discussions than they’re suited for.)

It seems likely that whoever hacked the RSA network got the algorithm for the current tokens and then managed to get a key-logger installed on one or more computers used to access the intranet at this company.

Wow, that’s quite the leap in logic there (on multiple fronts), especially since RSA hasn’t revealed what was pilfered from their network. Common discussion tends to speculate that the master list that maps the token seed list to organizations that are issued those tokens (probably keyed by serial number) is the most likely divulged piece.

How would a keylogger assist in this? Well, first, a keylogger alone could be enough to divulge login credentials, although any captured credentials are quite ephemeral when using a secureid token. Second, it could reveal any static PIN numbers used and usernames. I assume the PIN number is the “second password” mentioned in the article. *If* (and that’s a big if) the attacker was the same one who *may* have the seed list and algorithm, that attacker could theoretically match up that user and their fob based on keylogged information.

Does this mean “admin files have probably been compromised?” No; that’s an even bigger leap in logic. Possible, sure. But only with the correct access and/or expanded control inside the network. Hell, I’m not even sure Cringely knows what he means by “admin files.”

Of bigger concern is how a keylogger got installed on such a system long enough to caused this issue. Granted, something was detected (though I suspect it was *after* a theft or attempted VPN connection), but being able to spot such incidents on the endpoints or in the network itself should be a big priority.