More details are coming in on the Comodo digital certificate hack by an Iranian hacker. The young man apparently exploited the use of plaintext usernames and passwords in a generally vulnerable certificate issuing system.
Coming on the heels of the recent RSA SecurID breach, it has been a bad last couple of weeks for security vendors in general, and for both the SSL certificate and two-factor authentication hardware token businesses in particular. But RSA's pain is likely to be more acute. The SSL certificate business is unlikely to suffer in the long term. Websites need certificates, even if they don't guarantee security. Folks might move away from Comodo in the short term, but even that seems unlikely given the small-time nature of a certificate purchase. SSL certificates are mostly viewed as a commodity, and price is the main differentiator.
But the hardware token business could be in for some rough times ahead. SecurID is at the end of the day a discretionary purchase based on a desire to have the gold-standard of security. It is the security equivalent of a luxury good. But you wouldn't buy a BMW if you thought it was just as prone to accidents as the Toyota down the street. If RSA SecurID doesn't provide a concrete measure of added, or at least perceived, security, CIOs will be reluctant to pay the premium that hardware solutions naturally command.
RSA's vague pronouncements about "Advanced Persistent Threats" might have done more harm than good. There may be some mitigating law enforcement issues we don't know about that are preventing RSA from really coming clean. But APT is all-too often used as a code word for stuff-we-can't-really-do-anything-about. Which is fair enough of course; RSA can genuinely make the case that they've sold security products for a long time, but everything is breakable and stuff happens.
The security of RSA's SecurID system was always a combination of the strength of their underlying algorithms combined with the strength of their underlying operations and environment. Ditto with the Comodo situation - the security of SSL certs is dependent on many factors and the difficulty of factoring the products of large prime numbers is way down the list. Comodo is a business, and in businesses significant numbers of people need access to significant amounts of sensitive data. Invariably there will be screw-ups in how those people handle those responsibilities. This time it seems like an Italian reseller was partially to blame.
But this raises the larger question of whether particularly sophisticated and expensive security products are justified when most organizations face threats that are far most basic. In other words, the recent Comodo and RSA hacks ironically underscore the point that SecurID tokens are somewhat of a Maginot line for many organizations where other much more immediate threats are present.
The way Comodo was hacked is particularly illustrative of this phenomena. The reseller credentials were apparently sitting around in plaintext (or at least that's what the Iranian hacker taking responsibility for the attack claims). Most businesses, and especially businesses that live primarily in the cloud, have web front-ends to critical data that do not involve two-factor authentication. This might be a Salesforce account, Google Docs, an administrative console to a CMS like Drupal, or whatever. And many web 2.0 businesses live in shared hosting or VPS environments where the root credentials to their accounts actually live in plaintext in the host's servers, often visible by anyone in support. Using two-factor authentication in this kind of environment strictly to increase the general level of security rarely makes economic sense.
It's hard to say if RSA or Comodo will suffer any lasting damage from these attacks. For the vast majority of businesses, the ease of implementation and integration of a two-factor authentication solution trumps abstract concerns about the system's hackability. And SecurID's large library of clients and authentication agents is in itself a security feature; a competing product with a smaller number of clients introduces new threats, since you have to either cobble together your own code (almost always a bad idea) or you end up with some of your systems not covered.
The Rise and Fall of Hardware Tokens?
One primary beneficiary of SecurID's troubles could be competing vendors who offer two-factor solutions that do not rely on actual hardware tokens. CA has quickly gotten on the bandwagon and is offering to switch out SecurID tokens with its own ArcotID system. On the one hand it's easy to see how an actual physical hardware token is "more secure" than a software token installed on a mobile phone; a software token could theoretically be subject to all kinds of OS-related attacks and other vulnerabilities in both the issuing and maintenance. On the other hand, the actual overall environment in which hardware tokens live - the issuing, recalling, and indeed the APT in a vendor environment itself - paint a much murkier picture.
SSL and two-factor are part of the longstanding conventional wisdom of the security industry. They have made their way into the requirement documents of countless RFPs and contracts. In fact, the use of SSL is often one of the only security requirements in specs for outsourced web applications. But the shortcomings of this checklist approach to security are clear when Comodo's certificates can be brought down by a sloppy reseller or RSA's own SecurID can be subverted.
"SecurID tokens are somewhat of a Maginot line for many organizations where other much more immediate threats are present." Brings to mind the idea (written about by Schneier, if not others as well) that security vulnerabilities are found most often at the "seams", areas where security systems meet. This appears to be simply the nature of security in general. Two-factor authentication is still a sound principle, as long as security teams are consistently diligent to look for vulnerabilities at those seams.
ReplyDelete