Eight Things to Learn from the Gawker Fiasco

by P. J. Connolly

Some organizations have more to fear from inside attacks than from the outside ones. Others can trust users implicitly, but have a public profile—whether deserved or not—which makes them targets with a very high value.

If you’re calling yourself a technology company, you have to protect your core technology; in the case of Gawker and its founder Nick Denton, this was the Ganja framework, which Gnosis captured from poorly secured servers and made available as a torrent.

If you dare people to hack into your systems, you’d better have an intrusion detection system in place and security policies that correctly identify the probable attackers and their possible approaches.

Patching public-facing systems is not only necessary, it’s vital. It’s one thing to be a week or two behind to allow for testing before a general rollout, but some Gawker systems were reported to be up to a year behind on kernel patches.

Gawker’s authentication database, which linked user IDs, e-mail addresses and passwords, was encrypted using the obsolete DES algorithm; it can be assumed that every account’s password would be decrypted before the end of December.

Gawker’s IT policy for employee accounts broke rules that were commonplace by the mid-1990s: no dictionary words, no repeated numeric strings, change passwords on a regular basis.

Using the same password on multiple mission-critical systems isn’t a valid approach to single sign-on; key Gawker employees it seems have used the same credentials for everything they touched, making the break-in that much easier.

If your site already has a relationship with an OAuth provider such as Facebook or Twitter, you might want to take advantage of the provider’s authentication architecture, instead of trying to duplicate it.