The Full Wiki

Security through obscurity: Wikis

  
  

Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.

Encyclopedia

From Wikipedia, the free encyclopedia

Security through (or by) obscurity is a principle in security engineering, which attempts to use secrecy (of design, implementation, etc.) to provide security. A system relying on security through obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that the flaws are not known, and that attackers are unlikely to find them. A system may use security through obscurity as a defense in depth measure; while all known security vulnerabilities would be mitigated through other measures, public disclosure of products and versions in use makes them early targets for newly discovered vulnerabilities in those products and versions. An attacker's first step is usually information gathering; this step is delayed by security through obscurity. The technique stands in contrast with security by design, although many real-world projects include elements of both strategies.

Contents

Background

There is scant formal literature on the issue of security through obscurity. Books on security engineering will cite Kerckhoffs' doctrine from 1883, if they cite anything at all. For example, in a discussion about secrecy and openness in Nuclear Command and Control:[1]

[T]he benefits of reducing the likelihood of an accidental war were considered to outweigh the possible benefits of secrecy. This is a modern reincarnation of Kerckhoffs' doctrine, first put forward in the nineteenth century,[2] that the security of a system should depend on its key, not on its design remaining obscure.

In the field of legal academia, Peter Swire has written about the trade-off between the notion that "security through obscurity is an illusion" and the military notion that "loose lips sink ships"[3] as well as how competition affects the incentives to disclose.[4]

The principle of security through obscurity was more generally accepted in cryptographic work in the days when essentially all well-informed cryptographers were employed by national intelligence agencies, such as the National Security Agency. Now that cryptographers often work at universities, where researchers publish many or even all of their results, and publicly test others' designs, or in private industry, where results are more often controlled by patents and copyrights than by secrecy, the argument has lost some of its former popularity. An example is PGP released as source code, and generally regarded (when properly used) as a military-grade cryptosystem. The wide availability of high quality cryptography was disturbing to the US government, which seems to have been using a security through obscurity analysis to support its opposition to such work. Indeed, such reasoning is very often used by lawyers and administrators to justify policies which were designed to control or limit high quality cryptography only to those authorized.

Viewpoints

Arguments for

Perfect or "unbroken" solutions provide security, but absolutes may be difficult to obtain. Although relying solely on security through obscurity is a very poor design decision, keeping secret some of the details of an otherwise well-engineered system may be a reasonable tactic as part of a defense in depth strategy. For example, security through obscurity may (but cannot be guaranteed to) act as a temporary "speed bump" for attackers while a resolution to a known security issue is implemented. Here, the goal is simply to reduce the short-run risk of exploitation of a vulnerability in the main components of the system.

Security through obscurity can also be used to create a risk that can detect or deter potential attackers. For example, consider a computer network that appears to exhibit a known vulnerability. Lacking the security layout of the target, the attacker must consider whether to attempt to exploit the vulnerability or not. If the system is set to detect this vulnerability, it will recognize that it is under attack and can respond, either by locking the system down until proper administrators have a chance to react, by monitoring the attack and tracing the assailant, or by disconnecting the attacker. The essence of this principle is that raising the time or risk involved, the attacker is denied the information required to make a solid risk-reward decision about whether to attack in the first place.

A variant of the defense in the previous paragraph is to have a double-layer of detection of the exploit; both of which are kept secret but one is allowed to be "leaked". The idea is to give the attacker a false sense of confidence that the obscurity has been uncovered and defeated. An example of where this would be used is as part of a honeypot. In neither of these cases is there any actual reliance on obscurity for security; these are perhaps better termed obscurity bait in an active security defense.

However, it can be argued that a sufficiently well-implemented system based on security through obscurity simply becomes another variant on a key-based scheme, with the obscure details of the system acting as the secret key value.

There is a general consensus, even among those who argue in favor of security through obscurity, that security through obscurity should never be used as a primary security measure. It is, at best, a secondary measure; and disclosure of the obscurity should not result in a compromise.

An commonly-accepted example of this is the cryptographic salts of a password storage system. Should the system be compromised, both the list of the encrypted passwords and the salt may be compromised: in this case, an attacker will be able to run a dictionary attack against the encrypted passwords, and their security will rely only on the quality of the user-chosen passwords. Where the salt-generating algorithm is not compromised, dictionary attacks can become infeasible, given a good enough hashing algorithm and salt. The obscured salt, then, may be considered a secondary-level key: compromising it does not fully compromise the passwords, but does weaken security significantly.

Arguments against

In cryptography proper, the argument against security by obscurity dates back to at least Kerckhoffs' principle, put forth in 1883 by Auguste Kerckhoffs. The principle holds that design of a cryptographic system should not require secrecy and should not cause "inconvenience" if it falls into the hands of the enemy. This principle has been paraphrased in several ways:

  • system designers should assume that the entire design of a security system is known to all attackers, with the exception of the cryptographic key.
  • the security of a cryptographic system resides entirely in the cryptographic key.
  • more recently, in the 1940s, Claude Shannon put it bluntly; "the enemy knows the system".

The greater the number of points of compromise in a system, the greater the chance that an attack on one of those points of compromise exists, or will be developed. Systems which include secrets of design or operation which are also points of compromise are less secure than equivalent systems without these points of compromise if the effort required to obtain the vulnerability caused by the secret design or method of operation, and the effort to exploit this vulnerability is less than the effort required to obtain the secret key. The security level of the system is then reduced to the effort required to exploit the vulnerability.

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 that spare key. Furthermore, since burglars often know likely hiding places, the house owner will experience greater risk of a burglary by hiding the key in this way, since the effort of finding the key is likely to be less effort to the burglar than breaking in by another means. The owner has in effect added a vulnerability—the fact that the entry key is stored under the doormat—to the system, and one which is very easy to guess and exploit.

In the past, several algorithms, or software systems with secret internal details, have seen those internal details become public. Accidental disclosure has happened several times, for instance in the notable case of GSM confidential cipher documentation being contributed to the University of Bradford neglecting to impose the usual confidentiality requirements.. Furthermore, vulnerabilities have been discovered and exploited in software, even when the internal details remained secret. Taken together, these and other examples suggest that it is difficult or ineffective to keep the details of systems and algorithms secret.

  • The A5/1 cipher for GSM mobile cellular telephone system became public knowledge partly through reverse engineering
  • Details of the RSADSI (RSA Data Security, Inc.) cryptographic algorithm software were revealed, probably deliberately, through publication of alleged RC4 source on Usenet.
  • 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 taken advantage of those vulnerabilities. Indeed, assorted government agencies (eg the US Department of Commerce) have from time to time issued security warnings about the use of that software.
  • Cisco router operating system software was accidentally exposed to public access on a corporate network.
  • Details of Diebold Election Systems voting machine software were published on a publicly accessible Web site. (See Bev Harris)
  • The once open source Doom port, ZDaemon, had been renowned for security through obscurity; binary cheats were released and the source was closed because of this. Though this may have reduced the number of cheats, it still remains possible and several cheats exist.

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.

Operators and developers/vendors of systems that rely on security by obscurity may keep the fact that their system is broken secret to avoid destroying confidence in their service or product and thus its marketability, and this may amount to fraudulent misrepresentation of the security of their products. Instances have been known, from at least the 1960s, of companies delaying release of fixes or patches to suit their corporate priorities rather than customer concerns or risks. Application of the law in this respect has been less than vigorous, in part because vendors almost universally impose terms of use as a part of licensing contracts in order to disclaim their apparently existing obligations under statutes and common law that require fitness for use or similar quality standards.

Open source repercussions

Software which is deliberately released as open source cannot be said to be relying on security through obscurity (the design being publicly available), but it can nevertheless also experience security debacles (e.g., the Morris worm of 1988 spread through some obscure—if widely visible to those who bothered to look—vulnerabilities). An argument sometimes used against open-source security is that developers tend to be less enthusiastic about performing deep reviews as they are about contributing new code. Such work is sometimes seen as less interesting and less appreciated by peers, especially if an analysis, however diligent and time-consuming, does not turn up much of interest. Combined with the fact that open-source is dominated by a culture of volunteering, the argument goes, security sometimes receives less thorough treatment than it might in an environment in which security reviews were part of someone's job description.[5]

Security through minority

A variant of the basic approach is to rely on the properties (including whatever vulnerabilities might be present) of a product which is not widely adopted, thus lowering the prominence of those vulnerabilities (should they become known) against random or even automated attacks. This does not currently appear to have a single defining term, "minority"[6] being the most common but "rarity",[7] "unpopularity",[8] "scarcity", "lack of interest", and others also being used.

This variant is most commonly encountered in explanations of why the number of known vulnerability exploits for products with the largest market share tends to be higher than a linear relationship to market share would suggest,[6] but is also a factor in product choice for some large organisations.

Security through minority may be helpful for organisations who will not be subject to targeted attacks, suggesting the use of a product in the long tail. However, finding a new vulnerability in a market leading product is likely harder than for obscure products, as the low hanging fruit vulnerabilities are more likely to have already turned up, which may suggest these products are better for organisations who expect to receive many targeted attacks. The issue is further confused by the fact that new vulnerabilities in minority products cause all known users of that (perhaps easily identified) product to become targets. With market leading products, the likelihood of being randomly targeted with a new vulnerability remains greater.

The whole issue is closely linked with, and in a sense depends upon, the widely used term security through diversity - the wide range of "long tail" minority products is clearly more diverse than a the market leader in any product type, so a random attack will be less likely to succeed.

Historical notes

There are conflicting stories about the origin of this term. Fans of MIT's ITS say it was coined in opposition to Multics users down the hall, for whom security was far more an issue than on ITS. Within the ITS culture the term referred, self-mockingly, to the poor coverage of the documentation and obscurity of many commands, and to the attitude that by the time a tourist figured out how to make trouble he'd generally got over the urge to make it, because he felt part of the community.

One instance of deliberate security through obscurity on ITS has been noted: the command to allow patching the running ITS system (altmode altmode control-R) echoed as ##^D. Typing Alt Alt Control-D set a flag that would prevent patching the system even if the user later got it right.

References & notes

  1. ^ See page 240 of: Anderson, Ross (2001). Security Engineering: A Guide to Building Dependable Distributed Systems. New York, NY: John Wiley & Sons, Inc.. ISBN 0-471-38922-6. http://www.cl.cam.ac.uk/~rja14/book.html.  
  2. ^ Auguste Kerckhoffs (January 9, 1883). "La Cryptographie Militaire". Journal des Sciences Militaires: 5–38. http://www.cl.cam.ac.uk/users/fapp2/kerckhoffs/.  
  3. ^ Peter P. Swire (2004). "A Model for When Disclosure Helps Security: What is Different About Computer and Network Security?". Journal on Telecommunications and High Technology Law 2. http://ssrn.com/abstract=531782.  
  4. ^ Peter P. Swire (January 2006). "A Theory of Disclosure for Security and Competitive Reasons: Open Source, Proprietary Software, and Government Agencies". Houston Law Review 42. http://ssrn.com/abstract=842228.  
  5. ^ See "How Closely Is Open Source Code Examined?" by Larry Seltzer, Feb. 22, 2004, eWeek.com. Retrieved 2008-05-01.
  6. ^ a b "Mac Users Finally Waking Up to Security" by Kiltak, December 19, 2006, at [Geeks are Sexy] Technology News. Retrieved 2008-05-01.
  7. ^ Crypto-Gram Newsletter, August 15, 2003, by Bruce Schneier. Retrieved 2008-05-01.
  8. ^ "When 'Security Through Obscurity' Isn't So Bad" by CmdrTaco, July 23, 2001, Slashdot. Retrieved 2008-05-01.

See also

External links








Got something to say? Make a comment.
Your name
Your email address
Message