Security-through-obscurity is rightfully derided under most circumstances. My favorite examples are silly copy-protection schemes that are trivially foiled:
- The seekrit write-protect tab on 3.5″ diskettes. Y’all youngsters may not remember these at all, but back in the last millennium, commercial software was distributed on diskettes. These had a little plastic tab that you could open when you wanted to write-protect the diskette. This was a useful way to protect us from our own mistakes. Modern SD camera cards have a switch that is similar to these, and I think that is a nice thing. But the vendors who thought that shipping their software with the write-tab open gave them meaningful copy-protection were thinking very strangely, because you could still copy the diskette. Some of them went as far as removing the tab entirely. So the remedy was sticking a piece of tape over the hole. (I am not making this up! I was there!)
- Draw a line with a felt-tipped pen around the edge of a compact disk
- Apply a small piece of tape to the edge of the CD
- Hit the “shift” key
- Wait for a Norwegian coding brainiac to break the Super-Seekrit encryption key and write and distribute a decoder
What’s the common problem with all of these? Aside from trying to take away our fair-use rights and demonstrating all the business acumen and brain-power of turnips, they depend on secrecy to work, because once you discover how to defeat the copy-protection, all devices “protected” with the same device are broken. Good security works in the clear: you can see it, you can understand how it works, and you still can’t defeat it. Or, the cost of defeating it is too high to be worthwhile. I suppose you could argue that the RIAA and MPAA are trying to make the cost too high by buying bad laws and suing everyone in sight. But I don’t count that as security, but rather pitching fits that don’t solve their problems. Like when your toddler is overtired and nothing, but nothing is right with the world.
SSH, SSL, and GPG are three excellent examples of transparent, strong security mechanisms. There are zero secrets with any of these; anyone can dissect and study them. Reams of documentation abound. But they are easy to use, and they are effective. With canny use of “forward secrecy” they even provide protection against successful attacks. In a nutshell, “forward secrecy” means your encryption/decryption keys are changed on a regular basis, so a successful attacker only makes a limited gain, and then has to start all over.
When Security-through-obscurity Works
Let’s refine our concepts a bit here, because there is a place in your security architecture for security-through-obscurity. To quote Jay Beale of the Bastille Linux project:
“First, what does the security professional mean by bad “security through obscurity?” We really mean “security implemented solely through obscurity.” This describes the state where your entire method of security resides in hoping that the attacker doesn’t know something about the setup of your network, computer or program. One simple case is where you put your company’s secrets on an internal webserver, with no password-protection on the pages. Instead of relying on passwords or another acceptable method of access control, you’re relying on something different. You’re assuming that no one will know about that webserver except for the internal company employees who you’ve told.”
Hopefully no one is silly enough to do that. But, in addition to the usual security methods such as access controls and encryption, adding a bit of obscurity can be helpful, because it’s harder for an attacker to find a target. So here in no particular order are my Top Five Security-Through-Obscurity Tips.
1. Change Banners
All servers, such as HTTP and SMTP, display name and version banners. You can see these with telnet or on 404 pages:
Apache/1.3.37 Server at www.somesite.com Port 80
The version number could be useful to an attacker. There is no rule that you have to be honest; you can eliminate the version number, or lie. Some admins think it’s funny to pretend to be a Microsoft IIS server:
HTTP: Server = Microsoft-IIS/5.0
If you think engorging your log files from attracting all manner of attacks is funny, then this one will keep you in stitches.
2. Change Obvious Filenames
Filenames like passwords.txt and map_to_treasure.pdf are just asking for it. A lot of content-management systems use common names for their administrator portals, like www.somesite.com/admin. You could change admin to something less obvious. Don’t forget the fundamentals, like setting proper ownership and permissions on files.
3. Change Common Ports
This one gets mocked a lot, but it can make a difference. I know from my own log files that putting sshd on a non-standard port cuts those dumb automated brute-force SSH attacks that infest the Internet to nearly nothing. It also works for non-public HTTP servers that don’t need to use port 80, private SMTP servers- any server where using a different port doesn’t mess with minds of your users.
4. Put Passwords on Paper
Oh, how I wish the person who started the “never write down your passwords” craze were available for a public thwapping. This is the dumbest security advice of all time. Of course you should write them down, and keep them safe. How else are you going to remember good strong passwords, especially less-used ones? Because passwords themselves are a form of security-through-obscurity, so yours must be strong, and they must be protected. Where else should you keep them, on your computer? As if. Paper travels with you. Paper is not susceptible to power outages or file corruption. Paper is not vulnerable to remote attacks. Paper can be easily stored and hidden. If your users are too incompetent to keep a piece of paper safe, then don’t let them near anything sensitive.
I think a PIN-protected smart card that users control and can store gazillions of passwords on would be cool. Here we are in the new millennium, and keyboards still don’t have built-in scanners, and smart cards are not even close to ubiquitous. (At least not in the U.S.) People are already used to handling debit cards, so it wouldn’t be a scary new thing. My theory is vendors are not interested in anything that gives control to the user; they want big fat expensive centrally-controlled systems, which is not an attractive proposition to most folks.
5. Physical Locks Are Nice
This is so obvious I am embarrassed to even say it, but I encounter it all the time: lock your doors. What is it with people? What could be easier than locking a door? But they’re so busy worrying about some Russian mobster penetrating their network from afar they forget common sense.
The idea behind these tips is to set up additional roadblocks that are low-cost to implement. They will deter less-skilled attackers, and some of them, like changing ports and using physical locks, will show evidence of someone messing around where they shouldn’t be.
Resources
- Defeating the Sony root kit with tape
- The felt-pen trick
- So sue me; Jon Johansen’s blog
- Cory Doctorow’s excellent “Microsoft Research DRM talk”
- Freedom to Tinker reveals the shift-key secret
- OpenVPN and the SSL VPN Revolution has an excellent explanation of how “forward secrecy” works
- “Security Through Obscurity” Ain’t What They Think It Is
- Write down your passwords
