Five mistakes of data encryption

Computerworld - If you follow the media today, you might conclude that data encryption is everywhere. However, is this "good" encryption? A classic saying "Encryption is easy; key management is hard" illustrates one of the pitfalls that await those implementing encryption enterprise-wide or even SMB-wide. This article covers some of the other mistakes that often occur when organizations try to use encryption to protect data at rest and data in transit and thus improve their security posture.

The first mistake is not using encryption when it is easy and accepted. I'm talking about those pesky plain text protocols such as telnet and FTP. One can argue that people should have abandoned the above protocols for a host of other reasons, but, as the latest Solaris telnet 0day fiasco indicates, enough people are still using them.

Similarly, while using HTTP for sensitive online transaction is not common, one still sees such instances on lesser known e-commerce Web sites. Exposing sensitive information to known, actively used attacks, such as sniffing, is inexcusable. While risk of sniffing is typically overshadowed by the risks to stored data, there is indeed no excuse to not encrypting the data in transit when it is easy and does not cost any extra.

The second mistake has been mentioned by most cryptographers out there: inventing your own cryptographic algorithm. Sorry, but most of us are not that smart! Cryptography is a science just like physics and mathematics (in fact, we all know that it is based on the latter), and, amateurs have no place in it. On the other hand, if you are looking to secure a highly-sought spot in Bruce Schneier’s doghouse, go help yourself to a copy of Crypto for Dummies and start coding right away.

An interesting extension of this mistake has to do with failing to correctly implement a well-designed cryptographic algorithm. Indeed, algorithm design is hard, but quality implementation isn't an easy job either. As a result, people who chose to re-implement a "known good" crypto algorithm might be doing themselves a disservice, if a proven implementation exists (as a cryptographic library, for example)

Every security pro worth his salt will recognize the third mistake: "hard-coding" secrets. As we know, security of a quality cryptographic algorithm does not depend on its secrecy, but on its key or password. If you inadvertently make such password available for attackers, the game is over. Embedding passwords in code (binaries), configuration files or other "hidden" files is just that: providing your secret to attackers. And, no, your XOR’ing the password with a string of characters does not count: it just replaces your credible "secured by AES" label by a purely humorous "protected by the power of XOR."  You can only secure a password by encrypting it and then your problem does not go away since you have to deal with a new password.