One of the few things that most people in the security community seem to agree on is that there is a dire need for better security around Web applications. That need begins with the lack of security training for most Web developers and extends through the inconsistent use of Web-application testing, both pre-deployment and post-deployment. But one issue that has been overlooked for years probably belongs at the top of the list of Web application security woes: the haphazard use of cryptography.
Cryptography is an incredibly complex and difficult discipline to master. People spend decades studying, designing and implementing encryption algorithms and protocols and still routinely make mistakes that lead to weaknesses and even failures of their designs. This is why experts recommend that developers avoid implementing their own crypto at all costs and to insist on a rigorous review process if developers decide to use custom crypto. There are a number of well-designed and well-tested crypto libraries available to fit the bill, but experts say there is plenty of room for cryptographers to develop more high-level libraries to fill in the gaps.
The difficulty of developing and implementing crypto libraries hasn’t Web developers in even the largest and most technically savvy organizations from trying. For the last few months, Nate Lawson, a hardware and software security expert who has spent his career designing and testing security systems, has been doing research on the crypto implementations in a variety of Web applications and the findings have been less than pretty. In fact, he’s identified a serious problem in the crypto implementation in an application from Google and is giving a talk at Yahoo this week on implementing crypto in Web applications.
“I noticed a lot of protocols being published, mostly in Web services, and many of the designers aren’t very experienced in crypto and they’re doing a bad job at it,” said Lawson, who spent years working at Cryptography Research on protocol review and implementation. “The hack it till it works mentality just doesn’t work with crypto. Crypto can be very strong, but it’s very unsafe. If you get it exactly right, it’s very resistant to attack. But it’s worse than software in terms of being brittle. If you touch it wrong, it falls apart.”
A prime example of this phenomenon is the PRNG weakness in the Debian Linux distribution that was discovered last year. At the time, there was quite a bit of discussion about the problem, which enabled an attacker to compromise OpenSSL keys generated on certain vulnerable systems. But what was mostly overlooked was the fact that any DSA key that was even used on a compromised system should be considered compromised as well. This greatly expanded the number of bad keys and could have led to a serious crisis had Debian used OpenSSL to sign their software packages, which they don’t.
Lawson recently pointed out another crypto flaw, this one in Google’s KeyCzar crypto library, a situation that shows just how difficult crypto design and implementation can be, even for the most well-funded and careful development organizations.
“It’s really important to use that kind of high-level library to take advantage of this kind of outside review. If you don’t do it with an established library that’s well-reviewed, you run into problems,” Lawson said. “It amazes me because I know how hard it is. It’s a really long, drawn-out process and it can’t be rushed. People just don’t have that awareness of crypto, and that’s where it falls down. This is a dangerous trend. I consider it a failing of the crypto community that we haven’t focused enough on the programmer user. They don’t need yet another copy of AES, they need carefully implemented and reviewed libraries that generate cookies.”
One of the key things driving this trend is the huge volume of Web applications that are deployed every day and the ease of development, which lowers the bar for users who want to put up their own applications without waiting for a formal development process.
“The speed with which companies develop Web applications is very high, and that doesn’t it very well with crypto design,” Lawson said. “A good benchmark is if you spend a month developing the crypto you need to spend a year reviewing it. It’s a huge undertaking and you can’t take it that casually. You have to think about the requirements and do exactly that, and nothing else and implement it really carefully. There’s a lot of subtle ways that people poke crypto and get something useful from it.
“Even if you do negative testing, none of that will catch these kinds of flaws. We need to stop inventing new crypto protocols. Use OpenSSL for transport and GPG or KeyCzar for encrypting data at rest. These libraries continue to be the focus of reviewers.”
