It's common knowledge that a security system is only as effective as its weakest point. You can install a reinforced steel door with a two-phase palm-print/retinal-scan entry to protect your home, but if you leave a first-floor window open, you're more vulnerable than your neighbor with a simple deadbolt. One of Nate's clients learned this lesson first hand with its e-commerce Web site. The operation didn't involve terribly sensitive data: there were no bank accounts, no Social Security numbers, nor even any credit card numbers. Pre-approved customers would simply sign in and place their orders. Accounts payable and fulfillment would take it from there.

Yet the Web site painted a different picture, featuring two-factor authentication, encrypted databases and a giant padlock graphic advertising "secure."

Before Nate's team arrived, hacking the Web site proved to be about as difficult as entering a house through an open, ground-floor window. The original developers managed to implement virtually every type of vulnerability:

  • Query String Replacement. Users could (and did) fiddle with the URL in the address bar (for example, changing "/viewOrder.asp?OrderNumber= 80023" to "/viewOrder.asp?OrderNumber= 80024") to view other customer's data.
  • SQL Injection. By using single-quote characters, attackers were able to easily "inject" SQL code. For example, typing "' OR '' = '" in the Password textbox would result in a query that asked for users "WHERE Password='' OR '' = ''." Because an empty string ('') is always equal to itself, this would always return a user.
  • Trusting the Browser. Instead of using server-side code to disable and hide unauthorized navigation links, CSS and JavaScript were used. A quick "View Source" or even a line or two of JavaScript type in the address bar could (and did) easily bypass the protection.

Every time the Web site was hacked, the original developers insisted it was an infrastructure problem. They had the company buy a secure certificate. Then they added a separate database server. Then they installed a firewall to put between the servers. Then an intrusion detection server. And so on. Still, hackers waltzed right in.

Eventually, the company decided that enough was enough and hired Nate and his team to remediate the problems. But his hands were tied as the client insisted on dictating security requirements. And dictate they did:

  • All data must be encrypted twice: first through Rijndael/AES and then through RSA-512
  • Decryption/encryption keys must change daily and then be stored (after being encrypted) in a database
  • Passwords must contain three uppercase letters, three lowercase letters, one number, and one special character, and must be stored (after being encrypted) in a "Hardware Vault," which only the production server could access
  • No words of any known language shall be used for database table or column names

Try as he might, Nate was unable to convince his client that such requirements provided only the illusion of security. Encryption is meaningless when the application dutifully jumps through all the decryption hoops and displays it to unauthorized users. And obfuscating column names only makes it slightly less convenient for a dedicated hacker; could a column filled with "someone@somewhere.com" be anything but e-mail addresses?

Nate, however, was able to break the tasks into two separate phases with the hope that the second one would never come. The first phase involved patching up the actual vulnerabilities (a task he had to fight for) and implementing the least-absurd security requirements from the customer. The second phase involved implementing the most ridiculous mandates, such as the rotating encryption keys.

It's been a solid year and a half since Phase One was deployed, and there hasn't been a single break-in. Nate says that Phase Two is still technically "planned, but not a priority." In the meantime, developers have learned to deal with the "obfuscated" database naming convention: SELECT emaNtsriF, emaNtsaL, sserddA, ytiC, etatS, rebmuNenohP ... FROM sremotsuC.

Secure This was originally published in Alex's DevDisasters column in the September 01, 2007 issue of Redmond Developer News. RDN is a free magazine for influential readers that provides insight into Microsoft's plans, and news on the latest happenings and products in the Windows development marketplace.