Irreal

Irreal regulars know that I periodically go off an a rant about the proper hashing of passwords and the dire consequences of failing to do it correctly. Not even I, however, could have imagined that Cisco would get it wrong. And not just a little wrong but massively and totally wrong.

In fairness, I should say up front that Cisco has acknowledged the problem and issued a bulletin on how to detect if a given piece of equipment is affected and how to deal with the problem if so. Also, Cisco is saying that the problem is an implementation, not a design issue.

With the Cisco IOS 15 codebase, a new type of password—Password Type 4—was introduced. Apparently, the design called for this to be a SHA256-based PBKDF2 hash with an 80-bit salt and 1000 iterations. The idea was to replace the weaker Password Type 5, which is an MD5-based hash that was salted and repeated 1000 times. That makes sense but unfortunately the implementation merely hashed the unsalted password with SHA256 one time. The result is a password that is easily broken as demonstrated by Philipp Schmidt and Jens Steube.

It’s hard to understand how this sort of thing could get by QA. Any time you change a cryptographic primitive it is, or should be, a big deal that requires careful scrutiny and testing. If, indeed, the design called for PBKDF2 hashing, it’s hard to see why the developer would use a single pass of SHA256 instead and how that error could get by any serious code review. If the design didn’t call for PBKDF2, it’s equally hard to understand why any developer with even a modicum of security awareness would not raise an alarm. This is not new stuff. The ideas have been around for a long time. Even the original Unix DES-based password hash from the 70s used multiple iterations and a salt.

The lesson is clear. Unless you, too, want to be the object of near universal derision (and probably fired) use one of the accepted methods for safely storing passwords. Don’t just encrypt them, don’t just run them through a single pass of some hash, and for goodness sake don’t store them in plain text.

Over at Ars Technica Dan Goodin has a nice article analyzing the Gauss malware. Gauss appears to be related to Stuxnet and internal code signatures suggest that its provenance is the same¹. Although Gauss was discovered last year, very little is known about its purpose or capabilities.

That’s because its payload—or more accurately, its warhead—is encrypted. Gauss appears to be looking for computers used for a specific application. It concatenates PATH and program directory names, adds a salt and hashes the results. If the resulting (key stretched) hash matches a compiled-in constant, Gauss has found the program it’s looking for. Then it hashes the same PATH and program name with a new salt and uses the result as a key to unencrypt the payload. Despite significant and sustained effort, researchers have not been able to find the key and thus have no idea what the payload is intended to do.

Goodin’s article is interesting and informative. If you have an interest in security, or just want to see how someone might go about protecting a piece of software from prying eyes, you’ll enjoy it.

Over at A Few Thoughts on Cryptographic Engineering, Matthew Green has a useful review of some secure communications apps. He looks at

• Cryptocat
• Silent Circle
• RedPhone
• Wickr

from the standpoint of code quality, encryption protocols, and ease of use.

Interestingly, Green examines the apps from the point of view of “should I use this application to fight an oppressive regime?” It’s not a frivolous question. Citizens fighting and journalists covering those oppressive regimes need to communicate and if their communications are not secure, their lives and the lives of others could be at risk. It also explains his emphasis on ease of use. Most revolutionists and journalists are not technically sophisticated and are especially prone to using crypto applications in a non-secure way.

If you’re looking for a way to keep your communications private—even if you’re not trying to overthrow a government—you should take a look at Green’s post. In addition to providing a review of some of the leading applications in the field, it shows you what sort of things to look for and what sort of questions to ask.

If you like his post, you might also enjoy this video of Green delivering a talk on the current state of cryptography. If you depend on cryptography in your day-to-day activities you will doubtless find it enlightening (and disturbing).