Security Adviser | Roger A. Grimes » December 2007

December 21, 2007 | Comments: (0)

A side of hash

TAGS: Hash

The cryptographic algorithms known as 'hash' can make a huge difference to your data security

A hash is cryptographic algorithm that attempts to uniquely describe inputted content by outputting a value that is unique for a given piece of inputted content. A good hash algorithm has several characteristics, including:

* It will output the same hash result for the same exact input, every time.
* It will output a different hash result for a different input.
* Given only the hash output result, it should be non-trivial to impossible to recreate the input that generated the output.

If two different inputs create the same output, it's called a hash collision. In 2004 and 2005, Chinese Professor Xiaoyun Wang and other colleagues demonstrated that the hash algorithms MD5 and SHA-1 had weaknesses that allowed previously unexpected collisions at iteration rounds deemed cryptographically weak. It sent a minor shockwave through the cryptographic community and nearly everyone else paying attention.

MD5 and SHA-1, although not alone in a crowded hash field, are easily the most used cryptographic algorithms used to compare two pieces of stand-alone content in the PC world. Name a popular operating system (e.g. Windows, Macintosh, Linux, Unix, Solaris, BSD, etc.) and you'll find it full of MD5 and SHA-1 cryptographic comparisons. For example SHA-1 is used in Apple's OS for password hashing.

It sent a shockwave, but it didn't freak out the cryptographic community. First, a community full of double mathematical doctorates is a staid crowd to begin with. Second, being cryptographers, they're predicting this sort of stuff all the time. The discovery of the MD5 and SHA1 collisions was just a confirmation of something cryptographers repeat in every statement, about "...no algorithm can be proved to be secure," and other pronouncements like that. Plus, there had been other previous MD5 and SHA-1 findings that pointed to potential collision weaknesses.

Cryptographers respond
The cryptographic community and NIST responded by telling vendors and users to use better and stronger hash algorithms, including bigger variants of SHA-1 called SHA-256 and SHA-512. The increase in bit size theoretically makes the collisions more difficult to generate (although, interestingly, the July 2007 draft recommendation still includes the smaller 160-bit SHA-1 algorithm).

Many vendors (i.e. any with common sense) have started to abandon MD-5 and SHA-1. For example, Microsoft made a formal announcement during the Windows Vista beta program to begin removing all instances of MD-5 and SHA-1 from Windows. Although MD-5 and SHA-1 remnants remain in use, many cryptographic functions have been upgraded, and what remains is on the chopping block for future Windows versions. Most other popular vendors are doing, or have plans to do, the same.

One of the biggest fear scenarios from a hash collision is that two programs, one legitimate and one malicious, could end up with the same hash output value (i.e. the bogus program could be substituted for the legitimate one with no one the wiser). But in the real world, it would be non-trivial for an attacker to find a legitimate target program and then set about making a malicious clone that would produce precisely the same hash value. Making a second program with the same hash is hard enough, but making a second malicious program that mimics the legitimate program well enough that people run it while it performs malicious instructions the attacker wants instead is orders of magnitude harder to pull off. Even I, a crypto-hobbyist, not a crypto expert, felt like the theoretical collisions of MD5 and SHA-1 were more of a mathematical issue and not a real problem.

Maybe there's more to this...
Then come along a few demonstrations that make me realize that I'm just a crypto hobbyist and I should really just stay out of making cryptographic pronouncements. One site that reminded me of this is http://www.win.tue.nl/hashclash/Nostradamus. I've seen the demonstration before, but this site is the most recent one I've come across and it explains the involved issues pretty well, and does so with humor.

Essentially, the site contains 12 different PDF documents, each with different information, but with each having the same MD5 hash. This demo makes the topic of hash collisions more relevant by "predicting" which Democratic or Republican candidate will win the Presidency of the United States in 2008. To do so, they created 12 different documents, each one with a different candidate's name. Each of the 12 documents has the same hash result, along with the same file size and checksum, of course. You can check their results with any MD5 hash checker, although one of my favorite Windows programs is DigestIT 2004 because it makes generating hashes a right-click action on any file.

The hash collisions can be created because of a combination of MD5 hash weakness and the way certain document types construct and hide content. Part of the weakness is in the hash algorithm, which doesn't consider all content bits when constructing a particular output.

Of course, in this demonstration the content is just different names. No harm, no foul. But it is a ready example of how hash collisions can be performed with forethought and end up creating content that is different than the original. There have been many other demonstrations, including ones done with asymmetric keys and executables.

The next time you hear someone say that theoretical hash collisions aren't a big deal, send them to a Web site that shows the practical realities -- and then ask them who's going to win the next election.

Posted by Roger Grimes on December 21, 2007 05:05 PM

December 14, 2007 | Comments: (0)

Ask better password questions

TAGS: Passwords

By asking better password reset questions, you'll keep passwords more secure

I just love how many Web sites take my complex, hard-to-guess password and make it as easy to crack as guessing my favorite color or the city of my birth. It seems nearly every Web site comes with user-accessible, self-service, password reset questions, and nearly all of those same sites make resetting or obtaining my password magnitudes easier than actually knowing my correct password. Thanks.

I can understand why Web sites want a user-based, self-service, password reset feature. Users who forget or mistype their passwords comprise one of the most frequent support requests. I've read many studies that place the cost of each help desk password reset assistance call at $60 to $90. I don't mind the self-service part; it's the incredible weakening of security that bothers me.

Most Web sites put forth a handful or two of weak questions that you must use. The Web site administrators think that the questions are personal enough that only the person who answered them would know the correct answers. The problem is that the questions are often information that is known by lots of people, or they contain information that can be found by searching on the Internet.

For example, one common question is, "Your birthplace city?" I mean, how many people know that besides the account holder? Well, how about that person's close friends, family members, spouse, old boyfriend or girlfriend, and anyone who has ever viewed any credit card application you've ever filled out? And let's not mention all the databases you can search online to find out the birthplace of any person.

How about being asked to fill in your mother's maiden name? Again, you can point to the same suspects as in the previous question, but now add genealogy databases to the mix. Another favorite weak question is, "Your favorite pet's name?" First off, dogs are the most popular pets, and you'd be surprised about how common most dogs' names are. Mark Burnett's book on passwords, Perfect Passwords, has a list of the most common dog names. I was surprised to see my own dog's name, Abby, on the list. Mark's book also lists the most common colors, cities (that is, birthplace cities), and hobbies.

If a Web site under your control has one of these password reset features that use self-service, weak security questions, make sure the questions are truly capable of being known by only one person. Assume that the person's closest loved one ends up being their worst enemy and is motivated to break into their account.

If you want to be assured of the strength of your question, or at least give the user a fighting chance of staying secure, let them choose and input the security questions. The self-service password feature page should educate the user in how to create truly secure security questions. Suggest some good examples.

If your Web site's password reset self-service feature doesn't allow custom questions, or can't be recoded and can use only precanned, weak questions, try to require multiple successful answers to multiple questions. The Web sites I see using this type of query often ask the user to select 5 to 10 questions to which they can input the answers. And when using the feature, the user must successfully answer 2 to 4 of the questions. This makes it a little harder for an unauthorized person to break into the account.

Of course, any password resets or changes should be sent to the e-mail address on record asking for confirmation before being committed. If an attacker has access to your e-mail account and knows the answers to multiple or custom security questions, your issues go well beyond the things a columnist can help you with.

Posted by Roger Grimes on December 14, 2007 03:27 PM

December 07, 2007 | Comments: (0)

Keep security advice current

TAGS: Future Security

Cliches about safe computing behavior aren't enough, because e-mail, surfing, and patching vulnerabilities change all the time

Remember when computer security was simple? Advice was as easy as, "Don't boot with a floppy drive in your A: drive" and "Don't enable the macro to run." Boy, do I long for the days of yesteryear.

More and more, application vulnerabilities are being announced every day, whether it's something attacking Apple QuickTime, Macromedia Flash, YouTube videos, Adobe Acrobat, or Microsoft Office. And telling people not to open untrusted content is like telling them not to open e-mail from people they don't know. It's not bad advice, but you can't stop there.

You've got mail
On the "don't open e-mail from people you don't know" recommendation, malware has been using e-mail address books for nearly a decade now. Malicious spam and e-mail often comes from our friends, parents, and coworkers. The better advice is not to open e-mail that is unexpected, seems out of character for the sender, and contains links or content to click. When in doubt, e-mail or call the sender and confirm that they really meant to send it. Or do like me, and just delete it when there's a shadow of a doubt. I can't trust my friends and associates to thoroughly validate the stuff they send me. To them it's a cute little animated GIF or a YouTube video of a hot girl dripping barbeque sauce over a less hot car. To me, it's probably malware. It's just the way my mind works.

All these years later, you still can't tell people to open e-mails from only people they trust. Targeted spearphishing is becoming more common. You can't count on mispellings (sic) and bad grammar to alert you to a phishing attack. They have your name and your interest [for example, your bank account, Better Business Bureau complaint, 401(k) provider, and so on]. I won't give you my bank logon info, but there's a good chance that I'll respond, strongly, to my Dell laptop warranty expiring earlier than what I paid for or object to an unauthorized change in my 401(k) portfolio. Those malware guys are sneaky.

Surfing safari
Today, the frequent advice you'll get, in the face of application malware, is to not open content from or visit untrusted Web sites. That is so 20th century! Unless you've been hiding under a rock for the last few years, security article after security article has been detailing how malware is being served up by the Web sites we trust most. It's the NFL Web site, travel site, news site, political gabfest site, and blog that we all love. They get compromised, we visit, and we get infected.

The popular Web site is compromised through its own application vulnerability and ends up serving malware to visiting users. Or it has banner ads that push malicious content. Or the favorite search engine contains highly ranked results that are thoroughly malicious. If you haven't gotten the memo, malware is infecting us from sites and people we explicitly trust! And this isn't something new. Years ago, during the initial minutes of the Nimba worm outbreak in 2001, one of the world's most popular news Web sites tried to infect me. I was reading that hour's news when all of a sudden Notepad kept popping up, displaying gobbledygook (that's a technical term). I had closed Notepad a few times before I realized that what was happening was a result of my computer security defense. In an effort to render malicious scriptable content harmless, I had remapped the Windows Scripting Host file extensions (such as ".vbs") to be reassociated with Notepad instead of Wscript.exe or Cscript.exe. I finally realized that my defense was actually working. What I thought was ASCII character gobbledygook was instead encrypted executable content.

Patch and learn
The advice I give family, friends, and readers is this: Stay fully patched, with both your OS and your applications. If you don't check your entire patch status on a regular basis, you're probably not completely patched. Run Secunia's Software Inspector as a check if you don't have anything else. It isn't enough just to check your OS and biggest vendor's patching status. Run anti-malware and firewall software on the computer and keep it up to date. Perimeter security won't suffice.

Educate your end-users about the risk of attacks from Web sites they know and love. Users should be encouraged to be skeptical about all downloads, whether or not they come from a "trusted" site. Tell your users to never install video codecs, even if they promise to let them see the latest cool video. Explain to them that free software is rarely ever free. Teach them how to recognize malware warnings from their legitimate anti-malware software and, conversely, how to spot fake advertisements telling them that they're infected. Tell them not to download and run anti-malware programs that appear to detect the threat first and then require the download. That's backward.

Tell them that they should not run those funny videos and click on joke e-mail links sent to them by well-meaning friends. They should do that at home. They shouldn't be downloading music at work. Tell them how many music networks and peer-to-peer file sharing programs are big agents of infection. Remind them that they should not install software without prior approval. Tell them you (or your staff) will be glad to review their download choice to make sure it doesn't contain malware.

There are lots of ways to help users be more secure, but not telling them to remain skeptical on the Web sites they love and trust isn't one of them.

Posted by Roger Grimes on December 7, 2007 03:34 PM