Talk:Security through obscurity
From Wikipedia, the free encyclopedia
Contents |
[edit] 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)
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
[edit] 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)
- 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.
[edit] 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)
[edit] 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)
-
[edit] "Advantages and disadvantages of security by obscurity"
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)
[edit] 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)
[edit] 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)
[edit] 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)
