Obscurity Still Isn’t Security

Today Slashdot had a story about how a news story about an Australian transportation plan was broken early by a newspaper. The transport minister said the access of this information was akin to the newspaper trying to “pick the lock off a secure office and take highly confidential documents”.  What was the brilliant security plan that was supposed to be protecting this information?  The information was all stored on an unpublished URL with no security or authentication in place.

We in the security industry call this “security by obscurity“.  And it is not security at all. Security by obscurity is basically counter to Kerckhoffs’ principle which basically states “secrets do not remain secret, so the design–not the secret–must provide the security”. While arguments can be made in certain situations for withholding or obscuring information or processes, it cannot be the only thing protecting your private information.  I have seen security by obscurity practiced wrongly in these situations:

• The implementer does not have confidence in their security protections and controls.  Therefore, they protect the knowledge of whatever these controls are, hoping that they won’t be revealed. Ultimately these efforts usually fail, the weak countermeasures are discovered and exploited.
• The implementer believes that they have done something “new and improved” or “groundbreaking” when it comes to security.  Whether this is a brand new way to do encryption over wireless networks or a different way of authenticating users, it often would benefit of having a couple–or a few thousand–extra eyes look at it and check their work.
• The implementer or user feels a sense of safety because of their use of obscure or proprietary systems or protocols. For example, “nobody can crack my system because they would never expect someone to develop something in MUMPS that authenticated using the gopher protocol.”
• The implementer or user feels that the secret renders them invisible. The case above, an unpublished URL was no protection. Similarly, telling your wireless network not to broadcast an SSID, or using a username that isn’t related to your real name are attempts to hide information which generally won’t be successful.

And yet, there are some situations where security by obscurity is a useful thing–but only when combined with other efforts.

• Changing well-known usernames and network ports.  Why not stop automated attacks and script kiddies if you can?  I see countless failed login attempts on systems which expose the ssh port. Moving ssh to a non-standard port won’t stop a determined attacker from finding it, but it will stop the constant failed login attempts.
• Use non-default usernames for privileged accounts.  In a similar way, it is easy to try an exhaustive password attack against Administrator (Windows) or root (*nix), but may be harder for the attacker to realize that the Administrator account is actually disabled and the username used for administration is “gocrazy”.
• Do not expose information about system use and value. Naming your accounting server “accountingserver” and the system you keep your confidential information on “topsecretstorage” only helps your attacker.
• Change installation defaults. If you are installing a piece of software which might be an attack vector, try changing some of the installation defaults – change the directory structure, the name of configuration files, use non-standard environment variables, etc.

The above bits can help obscure key parts to help protect you, but those alone won’t protect you–whether your adversary is a newspaper seeking a scoop, or some other advanced persistent threat.  You still need to have a strong security policy, and concentrate on security at every phase of your development lifecycle. And/or <shameless plug>involve some others who can help</shameless plug>.