In Cryptography and computer security, security through obscurity (sometimes security by obscurity) is to some a controversial principle in security engineering, which attempts to use Secrecy (of design, implementation, etc.) to ensure 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.

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.

Others believe that hiding a spare key under the doormat is reasonable, because it facilitates entry for those that are aware of its existence and bars entry to many nonprofessionals. They acknowledge that a professional may be able to find the spare, but note that the determined have many other techniques for entry, such as using a knife to unlatch a window, lifting a sliding door out of its tracks, or using a ladder to gain access to an unsecured second story window.

Extending the point of view in the first example above, a person could give a spare key to a neighbour. He could then tell everybody about it who needs to know. Provided the neighbour is a responsible person, he will not give the key to a burglar, only to the owner (or maybe a legitimate fireman who needs to put out a fire in the house). In this case the Algorithm is known, but its security is not dependent on that knowledge.

In knows the system . Historically, security through obscurity has been a very feeble reed on which to rely in cryptographic matters. Obscure codes, cyphers, and crypto systems have repeatedly fallen to attack regardless of the obscurity of their vulnerabilities.

The full disclosure movement goes further, suggesting that security flaws should be disclosed as soon as possible, delaying the information no longer than is necessary to release a fix or workaround for the immediate threat.

= Arguments against security by obscurity=

Some argue that security through obscurity is flawed. If a system s security depends solely or primarily on keeping an exploitable weakness hidden, then, in their view, if that weakness is discovered, the security is easily compromised. It is argued that keeping the details of widely-used systems and algorithms secret is difficult. In Cryptography, for example, there are a number of examples of proprietary ciphers becoming public knowledge, either by reverse engineering (e.g. A5/1), or by a leaked description (e.g. RC4).

Furthermore, keeping algorithms and protocols unpublished means that the ability to review the security is limited only to a few. It is argued that allowing everyone to review the security will mean that any flaws or weaknesses can be identified and fixed sooner.

Some argue that operators and developers/vendors of systems that rely on security by obscurity often keep the fact that their system is broken secret, to avoid destroying confidence in their service or product and thus its marketability. Following this train of thought, it is considered possible that this may amount in some cases to fraud misrepresentation of the security of their products, though application of the law in this respect has been less than vigorous, in part because Terms of Use imposed by vendors as a part of licensing contracts have (more or less successfully) disclaimed their apparent obligations under statutes and common law in many jurisdictions requiring fitness for use or similar quality standards. 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 accusers also assert that often, such designers or vendors, or executives thereat, 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.

This security practice sets users up for trouble when the software they use is accidentally or deliberately disclosed, as has occurred in several cases: *Diebold — voting machine software; apparently accidental publication on an official Web site *Microsoft — Microsoft Windows and other software; apparently deliberate penetration of a corporate development network *RSADSI — cryptographic algorithm software; probably deliberate publication of alleged RC4 (cipher) source on Usenet *Cisco Systems — router operating system software; accidental exposure on a corporate network

Others believe the above citations do not support the assertions made regarding the allegedly nefarious intentions of software writers. They suggest that building secure code is challenging, and that the existence of attacks by criminal elements does not imply any degree of dishonest intentions on behalf of the victims.

When secure since obscure software is widely used, there is potential for widespread trouble; for instance, assorted vulnerabilities in the various versions of the Microsoft Windows operating system or its mandatory components such as its default web browser Internet Explorer, or its mail applications (Microsoft Outlook or Outlook Express) have caused world wide problems when computer viruses, Trojan horse (computing), computer worms, and so on have exploited them.

Software which is deliberately released as Open Source can never be said, certainly in theory, and in practice as well, 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), though the frequency and severity of the consequences have been rather less severe than for proprietary (ie, secret) software. The reason for this divergence has been attributed to the theory that many eyes make all bugs shallow (see Linus s law).

Notwithstanding the above, some executives support security through obscurity for protecting corporate information. They appreciate the quest for perfect or unbroken solutions, but suggest that absolutes are rarely obtained. Obfuscated_code corporate software, in their view, is a rational choice for mitigating the risks of reverse engineering and theft of intellectual property. Software obfuscation is not advertised as absolute protection, but it can thwart many attacks that otherwise would be simple.

= Historical note =

There are conflicting stories about the origin of this term. It has been claimed that it was first used in the altmode control-R) echoed as $$^D. Typing alt alt ^D set a flag that would prevent patching the system even if the user later got it right.

= See also =

=External links=