Security through obscurity
“Loose lips sink ships.”
(Wikipedia)
Hackers use exposed information and feedback from their actions to their benefit. They probe and research systems using techniques such as footprinting, enumeration, and fingerprinting. Knowing information such as server attributes, configurations, or software versions can be helpful in finding and exploiting system vulnerabilities. It is similar to a safe cracker knowing the brand and model of the safe they are trying to crack. The attacker could know specific weaknesses or even zero-day exploits. Having more information helps to narrow the field of exploits and to focus their efforts.
Limiting exposed information means not reporting any more information than is absolutely necessary. Be stingy about what information is given out. Everything could be a clue, including interface feedback, form structure, or URLs. Servers should not report software versions (often these are included in response headers).
The classic example is:
“The username was found, but the password is incorrect.”
This information would allow an attacker to enter an arbitrary username into a login page and determine if there is an account present for that username. Given enough time, the attacker could build a complete list of active usernames. This process is called “enumeration”. With a valid username, an attacker could then begin the process of determining the correct password to match that username (possibly using brute force or dictionary attacks).
Limiting exposed information is not the same as relying on security through obscurity. Strictly, security through obscurity means using a protection mechanism whose strength depends heavily on its obscurity, such that knowledge of its algorithms or key data is sufficient to defeat the mechanism (CWE-656: Reliance on Security Through Obscurity). Developers sometimes believe that they are increasing security by obscuring features. For example, they might hide an admin area with a URL like “somesite.com/xyzxyz/admin.php”. Or they might use unexpected variable names. Making features or code deceptive or obscure does very little to increase security. In fact, making the code less clear and simple often causes bugs which make the system less secure. CWE-656 notes that obscurity can be one small part of defense in depth, since it can create more work for an attacker, but it is a significant risk if used as the primary means of protection.
Limit exposed information, but realize that deception offers little additional security.