When Good Security Administration Goes Bad

In a recent post entitled Security Administration – Tradeoffs I discussed the dangers of making things worse in an attempt to make them better. All changes have a downside, however small, and if you can’t see a downside it means you haven’t analyzed the change sufficiently.

This was brought into stark contract when I read this post on Eric Raymond’s blog. The essentials are that some people are agitating to make AIS ship information encrypted and secure (AIS is information that ships broadcast about their position to other ships and shore receivers for collision avoidance.) The idea is that this information can be exploited by pirates and terrorists. While this is technically true, it doesn’t take a very deep analysis to see what the downsides of this would be.

The biggest hole that I can see, and Eric points it out clearly, is that any system would need to have a way so that ships could still read the transmissions of surrounding transponders. What is to prevent this technology getting into the hands of pirates? A technology that by necessity must be installed on thousands of vessels, and access given to any number of individuals of varying degrees of trustworthiness? It doesn’t seem like a huge problem for pirates to pose as normal ship operators who need the equipment, or failing that, to take control of a small vessel and torture the captain for his encryption keys. This change might thwart the casual, weekend pirating teens but not professionals.

It’s a case seeing a problem (pirates using AIS information to track down targets) and posing a solution (prevent pirates from getting AIS information with encryption) without fully considering the real world weaknesses of encryption technology or the costs, not just in implementing the solution but in the fragility this would introduce to collision avoidance. I’m reminded of password complexity requirements which see a problem (easy to break passwords) and posing a solution (require really complex passwords) without fully considering how those complexity requirements will just cause people to store unmemorable passwords on paper or in files on computers.

Consider the following two passwords I just made up off the top of my head 7sne02mnw6slie$a and [email protected]. Both have the same length and one is very obviously easier to remember without much strain. The second password wouldn’t fly in a lot of places, and may even drive a security officer to an early grave. In fact, I’m almost certain that even the first password isn’t complex enough for a couple of places that I’ve worked. So which password is more secure? Let’s see what my computer thinks.

Hmmmm, okay. Maybe my computer is stupid. Let me see what GMail has to say.



I know which password I’d rather use, and which I’d rather have my users go with (the password reset cost savings alone would be huge.) Still, some people’s guts will tell them that the first password is clearly superior. 

Another example. I recently got a new phone and I had to select a 4 digit PIN for customer service. As we should all know, 4 digits provide for 10,000 possible PINs. However there was a requirement that no two digits next to each other could be identical or consecutive, so 1274 is not a valid PIN. That simple requirement actually reduces the number of possible PINs by nearly two-thirds to 3,430. This may still be sufficient, but I’d be willing to bet that whomever created the requirement didn’t consider this consequence.

No security system is ever fool-proof, particularly when the fool is the one designing the system.