Skip to main content

The Security Tightrope

Security can seem like a tightrope at times.

Obviously, too little security is a bad thing (I considered including examples, but there are too many to choose from). However, too much security can be dangerous too.

If security makes a system too difficult to use, users will start to work around it. They'll write down their impossible-to-remember passwords, share their user accounts with colleagues, install back-doors into the system, smuggle data onto their laptops, make copies of the office store room key, you name it! None of it's malicious, but these workarounds open doors for hackers.

Now, if this were just a human problem, then you could kid yourself that this is really just a question of enforcement. The funny thing is, with technology getting smarter, it's not just people working around your security system - the computers are doing it too.

A common "security" measure for Wi-Fi is to use a "hidden" Wi-Fi network. This is a network that doesn't announce its name, so clients have to enter the name of the network manually, in order to connect. Now, the words "security" and "hidden" are in quotes for a good reason (at most, it'll slow an attacker down), but things get worse when you consider how devices actually connect to your network. Since your network isn't announcing its presence, devices have no choice but to call out for it. But devices don't know if your network is in range until they call for it. So these devices are constantly calling out for your network - on the train, in Starbucks, all over the place. Already, this is good for hackers, as they can sit in a coffee shop and get information about Wi-Fi networks all across the city, but they can do more than that: they can answer the calls, and trick devices into talking to them.

Now, you might point out that hidden networks aren't really a security measure. They're obfuscation at best. But there are lots of similar obfuscation techniques, that are widely recommended as genuine security techniques: blocking pings, removing version information, automated code obfuscation, MAC filtering, obscure TCP ports, Citrix access, and many others. These other techniques don't force devices to work around them, so they're not as harmful as hidden networks, but they may well force users to work around them, which is almost as bad, as none of them offer much security themselves.

There's a third type of workaround, which is neither man nor machine: process workarounds. There's a system I had to work with with once (it was written by Accenture, which tells your something already), which had an impossible to remember password scheme, and forced you to change it with great regularity. I don't think I ever typed the correct password into the box. I always just ended up using the password reset mechanism, which needed my first school and mother's maiden name. So my de facto password was an easily learned piece of personal information - exactly the sort of thing you should never use as a password. These side channels are a very real security threat - as Mat Honan can attest.

So what's the solution? I think the key point is to make sure you're getting enough "bang for your buck" out of your security scheme.

Obfuscation schemes are usually poor value, as they're not difficult to defeat, and they can make systems harder to use and debug. They're particularly problematic, as obfuscation schemes are often deployed when no-one can think of any better way to secure the system. Some systems deliberately avoid using obfuscation, to avoid a false sense of security.

Passwords are reasonably good (although passphrases are better), but there's still a danger of brute force attacks against passwords. You can reduce the risk of passwords being brute forced by requiring them to be changed regularly (this is poor value - users will hate it, and they'll probably just change it to "password1", "password2", etc), or by using the best modern password algorithms (this is good value - PBKDF2 or scrypt make passwords much harder to brute force, and are totally invisible to the user), ideally in conjunction with rate limited login attempts (also good value).

SSL and SSH are good value security mechanisms. You can also add public key authentication to SSL and SSH, but this may or may not be good value, depending on your user base - tech savvy users will like the fact that they no longer need a password, but non-technical users will be baffled by certificates. If not, keyrings and password managers can also be good value (but are utterly terrifying to most IT security departments).

I have misgivings about Kerberos as a security mechanism (it has some weaknesses that people don't like to talk about), but in some cases it can be a good value security mechanism.

If you still need more security, then you can think about rolling out some medium value security techniques, like two factor authentication and RSA secure token. They're effective, but they're a pain, and if your IT helpdesk gets into the habit of just letting people in, they're worse than useless.

Biometrics are famously poor value.

So, think about the threats. Think about your options, and their benefits and downsides. With luck, you'll be able to find a solution which eliminates all the threats, without forcing your users to open the back doors.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.