Security Through Obscurity

Using unknown or obscure security procedures allegedly keeps systems safe by having unknown flaws instead of "routine" flaws or exploits. For example, self-rolled encryption allegedly cannot be broken by known exploits in public or widely-available systems. (Hackers share or sell exploits to common systems or sub-systems). Instead, the hacker has to study a custom encryption mechanism, and may deem it not worth the effort if the gains are likely to be small, or so the reasoning goes.

On 3/25/03 GeorgeBush declared that SecurityThroughObscurity is the official policy of the USA. Bush's order enables the "reclassification" of presently unclassified material, and calls for a purge of all online material relating to �vulnerabilities or capabilities of systems, installations, infrastructures, projects, plans or protection services relating to the national security, which includes defense against transnational terrorism.� (http://www.msnbc.com/news/891209.asp?0bl=-0)

Goodbye, CERT.

moved from LinuxPerceptionProblems (The premise of this page has nothing to do with obscurity. Does BadLinuxAdvocacy dictate this discussion be taken out of context and approached from an unrelated view?)

I would really appreciate it if you explained why you don't believe this page has anything to with obscurity. I would also welcome other suggestions for a different premise and page title. -- francis

Good title worth defining or discussing, but why mired with Linux vs ClosedSource? I would expect a page on SecurityThroughObscurity to discuss the relative advantages and disadvantages of obscuring data to secure information.

Just because this discussion starts with a Linux vs ClosedSource chunk of text does not mean it's limited to only that example. (How about hiding your wallet in your shoe while at the beach?)

[When I was in a class on network security, we used the term SecurityThroughObscurity to mean OSes that were less used.. Linux doesn't really fit the bill anymore. The Mac OS used to, but now its built on a BSD core. The BeOS would be a prime example that still has relatively modern functionality. The conclusion in that class and elsewhere i.e. "Hacking Exposed" (ISBN 0072227427 - I forget the author) and other books on security is that SecurityThroughObscurity is rather weak.]

Many systems "obscure" information as a barrier. When opening up a PayPal account you must visually interpret and confirm random characters within a dynamically generated GIF. This barrier keeps credit thieves from launching batch attacks against them (assuming they don't counter the obscurity with OCR technology).

I don't think distributed binaries provide enough of a disincentive to be called obscure. After all, they're just machine instructions with openly defined header structures.

I postulated in LinuxPerceptionProblems that there is a perception that binaries from established vendors are "safer" than Linux because there is no source code available. There is at least a hurdle to taking the time to ReverseEngineer the binary before understanding the algorithm. To consumers, binaries are very obscure. But this is not to say vendors should rely on this perception as a means to providing security, it is merely an exploitable marketing option (what many so fondly disdain as "FUD").

Obfuscating byte code is a good example of SecurityThroughObscurity (or SecurityThroughObfuscation? depending on your pedantic level of interpretation). Having your Java or DotNet code disassembled by a would-be security hacker is not a comforting thought. This has created a market for obfuscating these binaries and subsequently de-scrambling them in the JIT compiler or VM.

-- ML

If I use Linux for eCommerce, everyone now has the source code to the encryption/security I'm depending on to run my business. At least there's a ReverseEngineering barrier to cracking EvilEmpire? code.

You should never rely on the ReverseEngineering barrier, if you want to promise flawless encryption/security to your customers. Instead, you should use a well-researched encryption method that is intrinsically difficult to crack. The best way to improve encryption technology is to expose it to a wider audience, who can look for flaws.

-- SteveHowell

Heartily agree. If experience has taught us anything, it is that security through (only) obscurity is hopeless. If your eCommerce security doesn't rely on a well-known algorithm, and the source code hasn't been audited by people who know what to look for, *and* the rest of your process hasn't been scrutinized - it is probably next to worthless. If you have a big enough organization (there are only a few of them) with enough expert eyeballs you can probably make a secure closed source solution. If not, a minimum requirement will be visible source, to the crypto community at least. This is one of several minimum requirements. Open source makes this one a non-issue. Another clarification: using Linux for your hypothetical eCommerce solution in no way implies that your security and encryption code is open source. It is a good idea (regardless of OS), but it doesn't follow from using Linux.

The best way to improve encryption technology is to expose it to a wider audience, who can look for flaws.

Heartily disagree. Unfortunately, it's usually my tax money that funds this so called 'wider audience' (i.e. academia) to review using a sloth-like bureaucratic process.

The best way is to improve eCommerce encryption technology is to get it into the hands of a few specialists who are financially motivated by paying customers. The results of which are a "ghost" technology that hackers don't even know exists. -- ML

This has been tried many, many times. Each time it has failed. Even if you could get a couple of world class crypto/security people in your corporation (highly unlikely unless you are MS, IBM, or similar), it simply doesn't work. Experience shows that the only algorithms and approaches worth a damn are those that have been thoroughly vetted by the community. Even good crypto people make mistakes, and the good algorithms have been through several iterations of refinement. It is easy to see the appeal of this sort of argument, but it is simply wrong. Don't take my word for it, ask any 100 crypto experts, or do a bit of reading (even better) on your own of primary sources.

It sounds like an interesting argument but:

'financial motivation' is an oxymoron since giving financial rewards or punishments to people only crushes their motivation.
the focus on "a few good specialists" is typical technocratic thinking, and the traditional weakness of technocracies (as with all rigid bureaucracies) is that they leaves no room for innovation, creativity, or original thinking. And without these elements, it's impossible to do research. (These are all things which the academic community ML so disparages has learned many long centuries ago.)
the idea of a "ghost" technology in eCommerce is sheer idiocy. To become popular enough to serve its purpose, it would need to be easily available, and as a result of becoming popular, it would attract enormous attention. The combination of availability and attention is the antithesis of a "ghost". (Most of the world is not like the military, Michael.)

The best way is to improve eCommerce encryption technology is to get it into the hands of a few specialists who are financially motivated by paying customers.

Like the guys who made CSS for DVD? Riiight....

How about hiding your wallet in your shoe while at the beach?

Hey, I've done that sometimes, and not had a problem with it. Depends on what beach you're at, what's in your wallet, and how smelly your shoes are. -- fh

"Smells like... petuniaaaaaaaaaaaaaaa"

I suspect SecurityThroughObscurity will work better for low-level hacking, such as ScriptKiddies, but less well against determined hackers. ScriptKiddies will generally give up if their "generic" hacking tools are not working on a given system; they'll just go to somebody else's system instead. However, if your system has something that a particular experienced hacker (or ally of) really wants, then self-rolled security is probably relatively easy to dissect, succumbing to methodical probing and near-miss pattern analysis.

A "physical" analogy would be a front-door lock. "Common" crooks would typically practice for off-the-shelf locks and have tools made for such locks that they get on the under-ground crime network. A DIY (self-rolled) lock may stump such a crook, and rather than keep at it, they'd go to the next house. They are not looking for "clever puzzles" to entertain them. (If they were smart and patient, they'd probably not be in the blue-collar crime biz.) It's an economic decision for them, and at a point they'll decide that trying other houses will be more fruitful than fiddling with a stubborn case.

Now if you had a million-dollar painting in your house and an expert art thief knew that fact, they'd probably try the standard lock hacks, but go out and hire a real lock expert when the "standard" tools and tricks don't work. The self-rolled lock would probably succumb. Thus, SecurityThroughObscurity could potentially be at least as affective as standard or off-the-shelf security, but not for "elite" lock crackers. Of course, ItDepends. Some DIY locks may be fairly good and some not. Off-the-shelf locks probably provide more predictable security, though.

CategorySecurity