Talk:Security through obscurity/Archive 1

Archive 1

Removal of NIST quote from the Criticism section

I have removed the following quote taken from NIST's "Guide to General Server Security" publication: "System security should not depend on the secrecy of the implementation or its components."

I believe it to be mis-interpreted and not relevant to security by obscurity apart from situations where it would be used a single security measure.

I read this quote as a criticism of corporate, non-open-source server systems, with secretive security patches and similar closed solutions.

References

Problems

"An example is PGP released as source code, and generally regarded (when properly used) as a military-grade cryptosystem."

Please define "military-grade" if there is such definition. I simply don't know it and usually is regarded as snake oil.

"Vulnerabilities in various versions of Microsoft Windows, its default web browser Internet Explorer, and its mail applications Outlook and Outlook Express have caused worldwide problems when computer viruses, Trojan horses, or computer worms have exploited them."

Now this is biased and is an obvious attack to Windows probably by a Windows hater (or linux fanboi). I could restate the sence as:

"Vulnerabilities in various versions of Linux, its default web browser Firefox, and its mail applications Thunderbird have caused worldwide problems when computer viruses, Trojan horses, or computer worms have exploited them."

Wich is also a true statement however attacks Linux.

"Cisco router operating system software was accidentally exposed on a corporate network."

Is there a reference to this?

"Linus's law that many eyes make all bugs shallow also suggests improved security for algorithms and protocols whose details are published. More people can review the details of such algorithms, identify flaws, and fix the flaws sooner. Proponents of this viewpoint expect that the frequency and severity of security compromises will be less severe for open than for proprietary or secret software."

This is taken as a proof and is completely false. The real truth has proven that many security holes have existed in open source software for instance like the linux kernel and OpenSSL. (no intention of specific attack) but i can provide lots of references for this claiming. —Preceding unsigned comment added by 200.55.135.211 (talk) 00:31, 12 July 2009 (UTC)

"e.g., the Morris worm of 1988 spread through some obscure—though widely visible to those who looked—vulnerabilities". Is this really an example proving that the security by design principle is flawed or the opposite? 1988 is a long time to go without a worm, virus, or other malware outbreak.

"Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of simplicity." - This is not correct in any sense for IT. In reality, security through obscurity is done (almost) exclusively in order to simplify a system. In reality, this is a principal mostly used by people who are unsure of the proper way to do something or they are too lazy to do it the right way. For the later group, this is ALWAYS done for the purpose of simplicity. For the former group, the result is still typically more simple than it should be (which is why they didn't bother to figure out the right way to handle it). If this doesn't hold true for other types of engineers it would be best to explain what type of engineering this applies to. 98.214.146.140 (talk) 08:22, 14 September 2014 (UTC)

Example of a civilian answer to military-grade can be found here "http://www.quora.com/Cryptography/How-is-military-grade-encryption-defined".

"Security through obscurity" is used by all military systems not visible to the operator. NSA Suite A Cryptography. "Open security" is only for civilians. There are other practical differences between civilian and military operation. There are also other techniques used that don't get used by open security. Therefore, no civilian implementation, PGP or the like can ever be military grade. This is independent of whether a certain encryption is better or not. Having a theoretically good encryption to based on is always good, regardless of which "grade." Mightyname (talk) 18:57, 15 September 2014 (UTC)

I agree that the phrase appears to capture the wrong cause. The reason security-through-obscurity is not an acceptable main security approach is that it's dangerous. One cannot know when an attacker will discover the details of the design or implementation, quite possibly then uncovering vulnerabilities therein. The term "security through obscurity" is usually used to denote shoddy implementations, where the system's security mechanisms are kept secret in the hope that this will keep the system secure; by contrast, designing the system with real and robust security in mind does not rely on the mechanisms being secret, but on the actual security of the design-and-implementation. --Mathieu ottawa (talk) 01:08, 20 March 2015 (UTC)

Straw man

Security through obscurity is a straw man. I think the phrase is notable, however it only exists through criticism. I think the article needs to be rewritten in that light. Zeth (talk) 22:52, 5 January 2008 (UTC)

This article has mistakes.

For example, if somebody stores a spare key under the doormat in case they are locked out of the house, then they are relying on security through obscurity. The theoretical security vulnerability is that anybody could break into the house by unlocking the door using the spare key. However, the house owner believes that the location of the key is not known to the public, and that a burglar is unlikely to find it. In this instance, since burglars often know likely hiding places, some assert that the house owner would be poorly advised to do so.

This example is incorrect. The security method M is hiding a key in a hidden place. The key K is where that place is. Thus for this example the key would be hiding the key under the doormat.

M() = Hide key K = Doormat

M(K)

In Symetric encryption algorithms the K is always secret. Security through obscurity is when the Method M is kept a secret, not the K.

No, the "method" is "hiding the key under the dormat". This is correct in the sense that it is illustrating that security through mearly assuming no one knows about a method is insufficient. If you can propose a better illustration, please edit as such (maybe using a key in the example is confusing?). -- Joseph Lorenzo Hall 20:30, 4 February 2006 (UTC)

It seems to me that every methods relies on a certain degree of obscurity, since there is always a key that must not be given to the public. I understand that some systems need more secrecy than just a key. But in the key under the mat example, what difference is there between, say a combination lock -hundreds of possibilities- and hiding the key in a flower pot if you have a lot of flower pots? An attacker can always try all the possibilities, whether it's numbers or hiding places (under the mat, in a flower pot, on top of the window ledge....)?

It is in line with established encyption principles to hide the key and not the method because keeping secrets takes effort and resources, so keep the secret as minimal and manageable as possible. Not knowing that the cat's out of the bag results in a false sense of security, as seen in examples ranging from the Enigma Machine to modern day DRM schemes. —Preceding unsigned comment added by 66.18.209.46 (talk) 07:51, 8 January 2011 (UTC)

An example is the Windows CD keys, a lot of them were leaked out, how (fundamentally) different is that from other security flaws being leaked out? AtikuX 08:21, 1 October 2007 (UTC)

---

so fix it... by the way it has another probable mistake...i don't think many eyes makes the bug shallow is not linus's but the one who wrote the cathedral and the bazaar,can somene who knows it change it 00 tux 07:16, 18 March 2006 (UTC) i was wrong even if it has been "formulated and named by Eric S. Raymond in his essay"(the linus law page) it's correct... 00 tux

POV in article

• It is important to separate description of the practice of security through obscurity with criticism of it.

---

Operators of systems that rely on security by obscurity often keep the fact that their system is broken secret, so as not to destroy confidence in their service or product.

That seems POV to me.

Also, the beginning of the article says that it's a controversial security practice. I thought that it was a pejorative term, and that people who actually practive it call it something else. -- Khym Chanur 07:52, Nov 20, 2003 (UTC)

Sorry to notice this comment so tardily. The problem noted seems to center around the meaning of 'broken'. Since a cryptosystem is designed to provide security (whichever aspect(s) is the design intent), if it fails to do so, it's broken by the only relevant test -- failure to do as intended. In engineering, an engine breaks when it doesn't work any more; same thing here, in principle. That I don't know about details of the security breach is, I think, irrelevant. You might, and so learn what was to have been securely held, even if he and I remain in pathetic ignorance.

Thus, I would argue there is no POV around broken in the sentence quoted. ww 15:32, 12 May 2004 (UTC)

POV in article title

The assertion "Operators of systems that rely on security by obscurity often keep the fact that their system is broken secret, so as not to destroy confidence in their service or product." appears convoluted. If this assertion translates to "providers often misrepresent their security products", it would be nice to see a list of these so that purchasers can be wary, or contact their states' attorney general. If this assertion translates to "corporations often use security techniques that they know are imperfect", we have an interesting starting point. In the latter case, the status quo lingo appears POV.

Security through obscurity is a pejorative term. Nobody would promote their security system and use the words 'security through obscurity'. 'Security through obscurity' is only a term that would be applied by other people in order to criticise the practice of keeping an algorithm secret. I believe the introduction needs to point out that it is a pejorative term for a given security practice. mmj (talk) 01:20, 2 February 2009 (UTC)

Furthermore I find it quite strange that an article about a pejorative term like this has arguments 'for' and 'against', as if 'security through obscurity' was the name of an actual security practice and that some people would be proud to have this label applied. mmj (talk) 01:23, 2 February 2009 (UTC)

Pejorative is often, as in this case, in the eye (or ear) of the beholder. So to your ear it's pejorative and POV, to another ear it's neither. In any case, it's the common term in use and so we are not free to impose on WP our own idea of what to term it. I agree that it's an odd term, but there are many odd terms (eg, idioms, similes, metaphors, ...) which have become standard usage, however pdd they appeared to some when first used.

The article uses the term neutrally, whatever you hear, and this accounts for the pro and anti sections. My own personal belief is that there can be no security when it depends on the adversary's incompetence at finding the key (or other macguffin) hiding place. Only a security scheme which is robust enough to survive full knowledge in the hands of an adversary seems worth bothering with to me. The problem is that so few reach this standard. ww (talk) 06:17, 2 February 2009 (UTC)

I realise that there are both positive and negative aspects of the security practice described in this article, and appreciate and support the importance of covering both well. However, surely the term 'security through obscurity' is a pejorative term to describe this security practice. So, if we are truly concerned about supporting neutral point of view we would not have used this pejorative term as the official title of the article. What about, for instance, if this article had been named something like "secrecy in security" (could be improved, but you get the idea) and the introduction said something along the lines of "... sometimes known pejoratively as security by obscurity by critics..." (with a couple of citations)? I think that would be a much more fair, and sane, way to do this. But as it stands, I think that what we have here is an article with a title that is a pejorative term used by those who wish to criticise this security practice, which then goes on to treat it as if it is the generally accepted name for this security practice. If there is an NPOV problem, that is it. Perhaps there is scope for a separate article with the title if "Security by obscurity", but such an article should be clearly about the movement against secrecy in security, not about the practice itself, which deserves an article with a more neutral title. mmj (talk) 12:17, 7 February 2009 (UTC)

Wikipedia should go with the most common use of a term. "Security by obscurity" and "Security through obscurity" are the common terms to describe the practice of obtaining security by keeping design and/or implementation details secret. "Secrecy in security" is not common at all as you can confirm for example by a simple Google search. By deviating from the most common use of a term wikipedia would become biased. Hence changing the title of the article would be a bad idea and in fact violate wikipedia policy. The correct treatment is to use the most common usage and to report on different views. The current treatment of the term does do this and the article is quite fair in my opinion. 92.106.82.196 (talk) 14:35, 7 February 2009 (UTC)

I'm really not seeing how the title is pejorative...it seems like a perfectly accurate description of the practice. That of adding security to a system by limiting knowledge of exactly how the system is secured. Can someone provide a clearer explanation to me of how it is pejorative? 99.172.41.123 (talk) 16:24, 1 April 2010 (UTC)

A little late, but I agree: the term isn't necessarily a pejorative. I read the article today and noticed the fact that the article starts with describing the term as a "pejorative" too, it seems a little strange. In itself it is a simple and factual description of a method that isn't necessarily flawed or ineffective at all. In a lot of cases "security through obscurity" can be very effective indeed, and one could even argue that is the single most used method in the world.* Even though a lot of people believe that security through obscurity is flawed and ineffective, and thus use the term (partly wrongly so) as a pejorative to describe a method of security as ineffective by assocation, doesn't mean that the term is necessarily a pejorative to all people all the time. It is a factual description of the method and since an Encyclopedia is about facts, the description thus fits perfectly. There isn't and there couldn't be a more factual and objective description to describe this method "non-pejorativily", so in my opinion it would be better do change the current text slightly by adding something along the lines of "Although the term in itself is a factual description of a method that can be (very) effective in certain situations, the term is frequently used as a pejorative to imply a given method of security as flawed or ineffective, by associating it with the (percieved) flawed aspects of "obscurity through obscurity". RagingR2 (talk) 21:36, 4 January 2011 (UTC)

* What I mentioned above about "security through obscurity" arguably being the most used method in the world, leads me to another point that disturbs me about the article. Granted, this statemeny may (probably) not be true if we talk about computer security, military security or any other kind of high tech/proffesional security. But in the real world, "security through obscurity" is a much more broadly applied term. Hiding a key where no-one will find it, putting something vulnerable or essential out of direct sight, using cover or camouflage, executing a coverup plan, concealing evidence or indeed Steganography (as mentioned several times on this discussion page) may all be described as methods of "security through obscurity", and may all be more or less applicable to situations outside the proffesional/military context; used in normal life or even in nature in the case of camouflage. In that sense, I think the scope of the article is somewhat limited right now, whereas Wikipedia articles I think should be as broad as the subject demands. RagingR2 (talk) 22:05, 4 January 2011 (UTC)

security of meaning through obscurity of phrase successful!

I give up. What is meant here by 'their gain'? from article

specifically, many forms of cryptography are so widely known that preventing their gain by a national government would likely be impossible; the RSA algorithm has actually been memorized in detail by most graduating computer science students.

ww 15:21, 12 May 2004 (UTC)

Maybe specifically, many algorithms are so widely known that preventing any national government from learning them would likely be impossible; the RSA algorithm has actually been memorized in detail by most graduating computer science students. ? — Matt 15:26, 12 May 2004 (UTC)

Matt, Could be, but this is still seriously incoherent. Needs rephrasing. ww 15:31, 12 May 2004 (UTC)

Yes, it's poorly worded currently. — Matt 15:35, 12 May 2004 (UTC)

What about "(they did not change a thing)", that seems a little pointed, maybe something like "Which was not successful" Mbisanz 01:42, August 6, 2005 (UTC)

steganography

In looking at the text on the "useless" DMCA, I sense some straying from the topic of this article. I think the point is that systems should use good security rather than just obscurity. Going down the slippery slope to argue about legal and legislative tactics leads to a whole bunch of stuff that dilutes the value of the article, I fear.

Furthermore, I think we need some text on cases where obscurity is in fact good engineering practice - i.e. steganography. And that article needs to refer to this one.... --NealMcB 21:05, 2004 Jul 19 (UTC)

I think it's fine to mention the DMCA because it's an example of how legislation is used (or is claimed to be used...) to enforce the obscurity of exploits ("security through obscurity") — perfectly on-topic as far as I can see. I agree, however, that the article needs some balance in its treatment; security through obscurity isn't universally bad. Most people running Linux are far safer from attack on the Internet than people running Windows; why? a big component is that Linux is obscure, so there are less viruses, worms and script-kiddies out there that target Linux (and yes, Linux arguably has better intrinsic security). — Matt 02:19, 20 Jul 2004 (UTC)

The problem with this is that the "obscurity" here is actually more related to confusion about the secret. Cryptographers understand that the secret in a system should be as simple as possible, because this means that you can change it easily, and also that you can study it carefully. So, for example, a users password should be the secret, not their login name. Passwords are easy to change, login names not as easy. When we discuss "obscurity" of OS's (meaning Linux vs. Windows), this is not the same kind of obscurity. In fact, in this context Linux is less obscure, because anyone who wants to can see exactly how each part of the system works. In Windows, the secret is (for example) not only your password, but the software that takes your password and uses it.

Matt, I would reverse your phrasing. Linux is not arguably more secure than Windows (modulo incompetent configuration), it is so. Having administered both in production environments, my experience is that there is little room for argument on this. Not if you go by the relative amount of effort (and success or lack thereof) in 'securing' them. And it is only arguably due to Linux' relative obscurity -- same reasoning. Linux source is published for all, after all. This is hardly obscurity!!! Incompetence of attacker is not even remotely comparable to attempted intentional obscurity of design.

As for balance in the article, I think that it's tough to argue that s thru o is sensible in the case of steag while not defensible in the case of poor crypto design. It's an apples and oranges thing. Steag is not design obscurity that some folks are hoping won't be discovered which when lost will allow a successful attack, it's deliberate obsfucation of information upon which depends confidentiality. Not commensurate concepts, really. Comments? Anyone? ww 14:59, 20 Jul 2004 (UTC)

You can't say Windows is "obscure", all you need to do is look up on MSDN, and you will find more infomation on the inner workings of Windows. Internet Explorer, for example, is more of an API then a program, as other programs such as MMC, Compiled Help, and any 3rd party app can use the calls in IE. IE is just API that explorer calls, there is no true stand alone exe file (The iexplore.exe calls explorer and the API dll). All these API calls are well documented. So other then the explorer code, IE completely documented. While it's not open source in the normal sence, you can still see all procedure calls it makes, and with tools like process explorer you can see in real time when it calls them. Just for the Windows OS, the wealth of offical documentation takes up more then 2 DVDs. Then you got 3rd party documentation such as from www.sysinternals.com that is supported and recomended by Microsoft.

What Matt was talking about, it's a more obscure OS in the that it has less users.

As for the "Having administered both in production environments, my experience is that there is little room for argument on this", what did you do for security on the Windows systems? Did you assign NTFS permissions limiting read, write, and execute permissions? Limit the accounts services run on? Drop rights from groups? And what did you do for the linux desktops? And what did you mean by security? Virus attacks and malware because users were using IE without restrictions enabled to the internet group? 216.54.146.100 15:10, 6 March 2006 (UTC)

"Advantages and disadvantages of security by obscurity"

"If it is true that any secret piece of information constitutes a point of potential compromise, then fewer secrets makes a more secure system. Therefore, systems that rely on secret design or operational details, apart from the cryptographic key, are inherently less secure; that is, resident vulnerabilities in any such secret details will render the choice of key (eg, short and simple vs. long and complex) largely irrelevant."

This paragraph is obviously misleading. If I have a perfectly functioning cryptosystem (eg, PGP) and I add a secret to the system by not letting the cryptanalyst know how it works, according to the thrust of this paragraph, I weaken the system. The first sentence is very specious... —Preceding unsigned comment added by 62.40.36.14 (talk) 04:12, 26 August 2008 (UTC)

Yes. By not letting the cryptanalyst community know how the crytosystem works, you do weaken the system. As Bruce Schneier indicates in Secrets & Lies, "New cryptography belongs in academic papers, and then in demonstration systems. It it is truly better, then eventually cryptographers will come to trust it... Security comes from following the crowd. A homegrown algorithm can't possibly be subjected to the hundreds of thousands of hours of cryptanalysis that DES and RSA have seen." (pp. 118-119) The problem comes down to you can't know that you "have a perfectly functioning cryptosystem" unless that system has been subjected to a beating you can't possibly administer yourself.

FWIW, I'm pretty sure that the cryptanalyst already knows how PGP works... so not sure how the (e.g. PGP) fits in here. Paleking (talk) 20:18, 3 April 2009 (UTC)

I disagree, you don't weaken the system, just confidence in the system. Schneier's argument is that you can't be sure how secure your system is unless you allow it to be attacked by as many people as possible. It doesn't change anything about the underlying security of the system. I agree that that para is misleading. It fact it is contradicted by the first para of 'Arguments for', namely that SbO can be (and often is) added as a 'layer above' a well-functioning crypto system, perhaps, for example, to slow down potential attackers. For example, I might implement GWC mode with Camellia, and might decide not to make that aspect of my design public, so that potential attackers have another 'speed bump' to overcome to break my system. It doesn't affect the actual security level of my system, which is well known, as GWC and Camellia have both been publicly scrutinised. Jack joff (talk) 14:27, 9 July 2009 (UTC)

I've reworded the offending paragraphs to make it clear that only a vulnerability 'covered up' by SbO actually reduces the level of security of the system. The next para, about 'full disclosure theorem' is contradicted by the wikipedia article it links to (which states that the reason for preferring full disclosure is that fixes get made sooner, not some ambiguous idea about weakening the crypto key). I therefore removed it. Finally, I reworded the house key example—exploiting a secret vulnerability is not the same as 'adding a crytographic key' (emphasis mine). It may be considered adding another key to the system, but the meaning of 'cryptographic key' is well defined, and is not this. Jack joff (talk) 14:53, 9 July 2009 (UTC)

That section contains no "Advantages".. Shouldn't this be re-worded?

-- agreed. Maybe include the story about the american army using native american dialects for communication to obscure plans from the enemy. That way this entry is also dragged slightly out of the "computer" only corner.

That was only partly for confidentiality and was understood to be weak. It was stronger for authentication: anyone wanting to understand the Navajo language could study and learn it (just like any other language) and many (including Germans) did so. But (just as with other languages) it was far more difficult for adult non-native speakers to learn to speak Navajo without an accent. Since there were at most very few (probably zero) native Navajo working for the Germans, a Navajo code talker, hearing an unaccented Navajo voice coming from the other end of a conversation, knew he was talking to a US army unit. Phr 23:26, 11 February 2006 (UTC)

Say what? Navajo was used exclusively in the pacific theater. The germans never tried breaking the code. Check out code talkers#Cryptographic_properties. I think it's an excellent example of SbO, since it relied on Navajo being unknown outside the United States and was very vulnerable to any Navajo falling into the hands of the Japanese. —Preceding unsigned comment added by 85.179.43.109 (talk) 12:08, 31 May 2008 (UTC)

Actually, since US had used American Indian languages in WWI, Hitler was expecting something similar in the coming war. German linguists were instructed to learn American Indian languages during the 30s against such an eventuality. So the comment above is correct to this extent, if wrong otherwise. The second comment is correct, Navajo wasn't used in Europe in WWII. ww (talk) 23:03, 31 May 2008 (UTC)

"Security through minority"

I've removed this section. It is exceptionally poorly sourced, and mainly contains narrative that isn't encyclopaedic. It is, frankly, unrelated to the subject matter of this article. Yes, the section could be tagged, or even every sentence that's unsourced, but I think until someone comes up with a properly sourced description, and shows how it directly relates to this subject matter, it doesn't belong here. Anastrophe (talk) 00:39, 27 February 2019 (UTC)

My big rewrite

I've just rewritten this page and tried to remove the weasel words. In some places I found them unnecessary, as the headings already use the word "argument," which suggests something not self-evident. In other places, I needed to change the text to read more like an argument (as in "If you believe X, then you can conclude Y,") rather than an assertion (as in "Some people say X"). I also moved some arguments from one section to another. For instance, the phrase "the frequency and severity of the consequences have been rather less severe than for proprietary (ie, secret) software" argues against security through obscurity, not for it. I moved all the historical examples together. Finally, I added summary sentences of my own design at the beginning of some paragraphs.

I deleted only two passages outright:

• "Designers, vendors, or executives actually believe they have ensured security by keeping the design of the system secret. It appears to be difficult for those who approach security in this way to have enough perspective to realise they are inviting trouble, sometimes very big trouble."
• "Others find this line of argument out of synch with reality, and suggest that the public would be better served if the accusers were to specify who has committed fraud."

The first sounds like it amounts to the tautology "those who like security by obscurity are those who like security by obscurity." Regarding the second, I failed to understand how to be more specific about the parties committing fraud.

This article should still cite more sources and verify some of its facts. I tried to preserve all the facts presented in the original, which I don't claim are correct, so if you find errors, you know what to do. Using text from old versions might reintroduce weasel words, so I would correct factual errors individually.

On the other hand, cranks and honest people alike will deny that they have axes to grind, and you may think I'm one of the former, trying to disguise my agenda among all the reorganization. In case you do decide to go back to text from old versions, I want to point out my few objective edits so you can at least retain them. I corrected "posession" to "possession" and changed capitalized words like "OR", "MORE", and "PLUS" to italic versions. I expanded "ASAP", too.

Cheers. --Officiallyover 05:36, 14 March 2006 (UTC)

I'll take a look at this later today... it looks good at first brush. We might want to insert {{fact}} tags where cites are needed. -- Joebeone (Talk) 21:44, 14 March 2006 (UTC)

Sorry to have taken so long to re-read this article. One major thing stands out that I don't particularly like. The notion of the "'key' had now changed" is quite confusing. In all of these cases the key didn't change at all. What did change? The assumption that the key is kept safe... or essentially the power that the key may have given you given the lock system you are using (for example, you could be using a variety of different house keys... from simple to complex... and if a burglar can locate the key, the security in all these cases has now been normalized or made the same... it's essentially as if you have a latch (no key) on the door). From a pedagogcial point of view, I think that all instances of "the key has changed" in this article should be eliminated for better language. I can take a shot if you'd like (while preserving the rest of the text). Good job, otherwise! -- Joebeone (Talk) 02:53, 20 March 2006 (UTC)

Certainly take a shot at it. Thank you for your comments and for taking the time to review the changes. --Officiallyover 08:08, 20 March 2006 (UTC)

Alright... I'm not sure the wording is perfect, but better. We could still improve it. Let me know what you think. best, -- Joebeone (Talk) 02:42, 26 March 2006 (UTC)

Referenced

I added a bunch of references and hope that's enough to justify my removing the unreferenced tag. -- Joebeone (Talk) 22:31, 11 May 2006 (UTC)

I don't want to make any vanity edits, so I'll propose this here and let someone else sort it out. There aren't many treatments of an opposing approach to security -- as I've called it, a "security through visibility" approach -- in existence. Most commentary on "security through obscurity" simply discusses the failures of that de facto methodology, and doesn't address the inverse methodology itself. An article I've written titled Security through visibility does deal with the subject, however, in contrast with the notion of "security through obscurity". It might provide a useful reference item to add to the "external links" section of the article here. Apparently, at least the guys at Second Life thought it qualified as an authoritative resource for their Open Source FAQ. —The preceding unsigned comment was added by Apotheon (talk • contribs) 00:45, 18 April 2007 (UTC).

Sorry about that. I just forgot to sign it. -- Apotheon 21:16, 19 April 2007 (UTC)

Biased Structure (more POV)

The article is structured in a manner that's unnecessarily biased against this approach. It starts with Arguments Against rather than In Favor Of, which is a very unusual way to structure any article about a competing strategy (starting with advantages is more standard form and gives the disadvantages section more material to rebut). --Mahemoff 17:28, 21 October 2006 (UTC)

It may be notable, in this context, that the term "security through obscurity" was likely coined as a pejorative term for certain security practices that were not clearly identified as a "competing strategy" until they were criticized for their (claimed) fallacious predicates. Or something like that. -- Apotheon 14:53, 9 May 2007 (UTC)

Origins

I removed the part about Apollo. The earliest reference I could find in usenet was Crispin, 1984. The true origin is no doubt lost in obscurity. —The preceding unsigned comment was added by Rees11 (talk • contribs) 20:26, 12 January 2007 (UTC).

Running network services using non-standard port

The current examples of security through obscurity is somewhat...obscure. At least for knowledgeable computer users, the most common example of security through obscurity is running network services using a non-standard port. I think this is a particularly good example, because it demonstrates both the pros and cons of the practice. As the only security measure (say, running a default login telnet on port 12345) it's clearly insufficient and foolish, yet combined with existing method could be beneficial.

As a personal anecdote (though I believe I'm not alone in this), I get hundreds of SSH login attempts every few hours or so, and therefore my log file is filled with failed login attempts, drowning out other messages (yes I know how to use grep). After switching to a non-standard port, I've yet to see anything in days. In addition to more readable logs, not having to establish / tear down connections saves memory and CPU cycles (granted, in my case the waste is insignificant). —The preceding unsigned comment was added by Madoka (talk • contribs) 01:21, 15 February 2007 (UTC).

condensed long paragraph

Here's the original text of the now condensed long paragraph. Much of it was removed in the condensation as it confused Bernstein's case with Zimmermans's and attributed (with citation) a motive to Zimemrman that is incorrect. Zimemrman was concerned to retain civil liberties of private discussion in an increasingly electronic world and saw quality crypto as a means to that end.

In the mid-1990's Phil Zimmerman published the source code for PGP, which is commonly considered a military-grade cryptosystem, in book form, in order to taunt the U.S. government into prosecuting him for violating the law that classifies all secure cryptosystems as munitions, which can't be distributed witthout a government license. Zimmerman's counterargument is that publishing a book is protected by the First Amendment, even though any reader could cut the pages from a $60 book and run them through a scanner, then use an OCR program to create a text file. The resulting source files could be compiled using open-source development systems, such as the GNU C Compiler, on nearly any type of computer, anywhere in the world. He was confident that the NSA would attack PGP with little success--even their supercomputers would take eons to factor the product of two very large primes--and that the program would see wide distribution and use; and that the Supreme Court would not send him to prison. In any case PGP's security is based on number theory and the cost of computation, not on obscure design.

If the editor would like to restore some of the removed materail, please discuss it here. ww 16:05, 27 March 2007 (UTC)

Historical Notes

The "Historical Notes" section was lifted almost verbatim from the New Hacker's Dictionary. Maybe it should be credited or removed. Rees11 19:57, 28 March 2007 (UTC)

Security through obscurity in non-computer contexts?

This topic is relevant to overall national security, not just computer security, and therefore should be expanded. For example, would classifying the internal procedures used by the Transportation Security Administration be necessary in order to protect against terror attack, or does it actually prevent vulnerabilities from being addressed? 69.140.164.142 04:45, 23 April 2007 (UTC)

security [ "by" | "through" ] obscurity?

I wonder which is the best way to express this concept, from english linguistical point of view (but not limiting to). ast pronounced it "Security by obscurity", but he also spelled "Kerckhoff" without the trailing "s", so i doubt he is right about it this time... --ThG 19:50, 16 July 2007 (UTC)

Security through rarity?

I have seen two uses of the term "security through obscurity." The first is using secrecy for security. This seems to be the meaning used in formal literature and the intended meaning in this article.

However, I have seen a second use of the term used: that the technology is so uncommon that it is not a target of cracking. Perhaps a better name for this argument may be "security through rarity." The argument is sometimes used (perhaps wrongly) to explain why Windows systems are more often the targets of malware than Linux or Macintosh systems. It is argued that this may result because the uncommonness makes it a de facto secret to an amateur cracker (despite possibly being open source), because the bad guys don't have the tools to develop and test their exploits, because existing exploits would be less available to an amateur cracker, or because crackers have less motivation to target a system that would have less impact.

I have seen significant use of the latter meaning of "security through obscurity," even if it is inaccurate. Perhaps there needs to be an additional section in this article to address security through rarity, or even its own article. 68.191.176.60 21:29, 24 July 2007 (UTC)

There needs to be some coverage of this. I assume that security through rarity is much more common than deliberate security through obscurity. Since rarity and obscurity are sometimes synonyms, it's confusing not to have this mentioned. Also, the two are presumably linked in that they should both offer resistance through deterence of effort. --Wragge 19:49, 23 October 2007 (UTC)

I've added a basic section, using the most common Google term I could find for the concept ("minority"). It's not great though: if people could find a better term or improve the section, that'd be nice. I've tried to avoid writing anything there that wasn't totally obvious to anyone with a brain, but it might still count as "original research" - not sure. DewiMorgan (talk) 18:05, 21 February 2008 (UTC)

The phrase is often used in reference to an OS being less prone to attacks than another due to a smaller market share. Can a reference be made that Macintosh OS7 was more often the target of malware despite an even smaller market share in the 1990s?22yearswothanks (talk) 03:24, 12 November 2010 (UTC)

Historical addition

I seem to recall reading about a big debate in the locksmithing community in the 18th or 19th century regarding this subject. If anyone has a good reference on that and can add a section, that would be great. Gigs (talk) 15:51, 23 December 2007 (UTC)

A few years ago, Matt Blaze of Bell Labs discovered and published a paper on an inherent flaw in a master keying method used by locksmiths, apparently everywhere. There was an immediate uproar in the locksmith community where the flaw had long been known. One of the loudest excoriations of what Blaze had done seems to have been something like, "now that he's told everybody who can read, master key systems [ie, those with this flaw] will now be insecure. Oh Woe is the industry!" Clearly a communal commitment to security through obscurity, and a complete bunk, since there was no security present against any enterprising attacker. The difference after Blaze published was simply that the threshold of effort required of an attacker was lowered to beign able to read, whereas before it had required only a certain amount of grit and enterprise to reach the same degree of knowledge.

In this instance, security through obscurity was, and had been since the first realization of this flaw by some locksmith long ago, completely feckless and ineffective. Indeed no security at all, thee being an effective attack. ww (talk) 15:03, 3 February 2009 (UTC)

Only computing?

Surprised that this article is entirely about computing. Isn't the term used in other contexts, such as in a military context where a small force is used because it is safer overall, because their small size makes it harder for their enemies to find them? We could even apply the term to a non-security situation such as the articles included at this AFD, which survived for years because nobody found them. Nyttend (talk) 23:26, 8 July 2009 (UTC)

A more fitting and less biased analogy than the doormat key

"An unlocked trapdoor hidden behind bushes"

I think that would fit better ont he definition of security thru obscurity than the doormat key analogy, since not all security thru obscurity actually involve "keys" (cryptographic or otherwise), and it sounds less biased, keys int he doormat is way too common, too easy to guess, in many cases what is obscured in security thru obscurity is somthing that has not been seen before, and somtimes in places where people aren't used to finding them. (on a sidenote, eventhough with this alterations uggestion i'm tilting the bias towards security thru obscurity, i still don't support security thru obscurity, i'm just trying to contribute to the improvement of the article in regards to WP rules, guidelines etc)--TiagoTiago (talk) 15:37, 6 November 2009 (UTC)

About the demonstration of the perfect cypher

I read Shannon believed he got a demonstration that ensures if you want to cypher without adding entropy you need your key has the same length of the message. Could it be interesting? —Preceding unsigned comment added by 95.39.137.224 (talk) 14:08, 14 May 2011 (UTC)

Sounds Borgesian. Bjhodge8 (talk) 20:41, 29 April 2017 (UTC)

Definitions

Its tough to write authoritatively without definitions. Definitions in this case, determine which references support what content. At issue in this article is a difference between a "defense" and a deterrent". They exist at different points along the continuum defining a system life cycle. Consideration of the topic from the standpoint of a security event also shows them at different points.

There is a difference between a deterrent and a defense. The term "paper tiger" comes to mind as does a device made for automobiles that locks the steering column. A defense is triggered by an attempt to breach -- yet marketing terms obscure the difference between the terms. Likewise, similarly-convoluted definitions can be found in CISSP (and other) study references.

Trapping an intruder is a defense while posting a sign saying intruders will be trapped, is a deterrent. The former requires action while the latter is threat-only. Obfuscation is not encryption.

IMO Kernel.package (talk) 23:56, 2 October 2011 (UTC)

Complete straw-man.

In literal terms all forms of password security are security by obscurity. If the password itself were not obscure, there would be zero security. In fact the main security issue in offices is the use of non-obscure passwords such the name of the user's car or sport, rather than questions of password length or complexity.

That being the case, I fail to see how use of a nonstandard port differs in principle from using a stronger password. If the random port means that an attacker has to try the password on 65535 ports instead of one, that increases the password strength by a factor of 65535, an increase equal to adding four hex characters to the password's length. In fact the real increase in strength is larger than that, since trying multiple passwords on multiple random ports is very likely to alert someone to the attack, whereas a concerted attack on one port which is expected to be frequently accessed (eg port 25) may not.

Two prime examples of lack of obscurity concern spamming. The use of predefined email addresses such as info@... etc promotes bruteforce spam attacks. Since domains are by nature non-obscure, all a spammer has to do is to lookup the domain and then try the predefined addresses. This will call for typically less than ten tries to find a hit, and hence will probably not trip any bruteforce filter on the recipient server. Moral: Don't use predefined addresses.

On webpages, the use of the mailto: HTML construct is a virtual 'kick me' sign to spammers. By removing any possible obscurity as to what constitutes an email address within the page, it makes robotic address harvesting very easy. The mailto: URL syntax ought to be deprecated, as this simple change would have a huge impact on the worldwide spam volume. Furthermore, any email addresses quoted in a webpage should be given in a sufficiently obscure manner that a robot would have to use a different harvesting method for every site it visits. This will make address harvesting impractical. Naturally the challenge here is to devise shemes which are transparent to the site visitor but pose obscurity problems for the robot. The main point is that it is far more effective to make it impossible for the robot to tell which word or phrase in the page IS an email address, than to lightly encrypt that email address. The latter can be broken by brute force methods, the former cannot. --Anteaus (talk) 13:41, 14 January 2013 (UTC)

"Open source repercussions" appears off topic.

The "Open source repercussions" section seems, for the most part, a reiteration of the Open-source software security page.

The first sentence does mention obscurity, and so, though I have trouble understanding it, the sentence may be on topic. However, the following sentences discuss Security Incentives, Software Flexibility, Bug Frequency, and many other general security problems that are more suited to the Open-source software security page.

It is true that Open Source software, by its nature, cannot use security through obscurity, and this fact should be reflected in the article. But it should require only a few sentences to explain, possibly in the Historical Notes section, with a link to the Open-source software security page for further reading.

First post. My apologies for any improper tone or errors. In the spirit of being bold (Wikipedia:Be bold) I will make this change.

Kenkron (talk) 17:41, 19 July 2013 (UTC)

Example of where it works

The /etc/shadow file is an example of where security through obscurity works. Because the shadow file can not be read by un-privileged users, the password hash can not be checked against rainbow files like was possible when the hashes were stored in /etc/passwd.

That is security through obscurity and it does not mean that *nix systems do not continue to advance the hashing algorithm used for passwords. Security through obscurity is only flawed when it is used instead of proper techniques, not in addition to proper techniques. — Preceding unsigned comment added by 75.128.2.73 (talk) 06:44, 9 December 2014 (UTC)

Open security and obscurity used together?

"The technique stands in contrast with security by design and open security, although many real-world projects include elements of all strategies."

Umm, how can you use obscurity and open security at the same time? Isn't open security, by definition, not security through obscurity? Oiyarbepsy (talk) 19:44, 9 July 2016 (UTC)

Practical Example

Ok, maybe i have been reading too many humorous articles, but would it be a good idea to add a practical example using an obscure link which, once clicked, reveals the pitfalls of security by obscurity? (oh nd also DO NOT click on these links; they have been engineered to break wikipedia as per Beans!_{56independent/notacoworcat}^Talk 08:08, 10 November 2022 (UTC)

Intense Editorial Bias in this Article

1. The article does not say a single positive thing about security through obscurity in its entire text, only a litany of criticisms. Humorously, they felt the need to add a criticism section in an article consisting of nothing but criticism. 2. The article is focused entirely on information technology security, or, by way of analogy, locks in the history section. Security through Obscurity is a perfectly valid way to, say, position a nuclear launch site/vehicle. There is no mention whatsoever of myriad other security contexts. 3. The criticism amounts to a strawman that security through obscurity is the only method of security being used, rather than in concert with other forms of security. --166.182.84.28 (talk) 20:50, 3 July 2023 (UTC)

I will be correcting this. Thanks for pointing it out. skarz (talk) 04:13, 5 April 2024 (UTC)

In addition to everything you mentioned, there's also no actual difference between STO and the alternative. Adding more hex characters to a hash just increases its obscurity. 207.91.187.66 (talk) 18:03, 1 July 2024 (UTC)