Secure error messages in software systems
This article may have been previously nominated for deletion: Wikipedia:Articles for deletion/Secure error messages in software systems exists. It is proposed that this article be deleted because of the following concern:
If you can address this concern by improving, copyediting, sourcing, renaming, or merging the page, please edit this page and do so. You may remove this message if you improve the article or otherwise object to deletion for any reason. Although not required, you are encouraged to explain why you object to the deletion, either in your edit summary or on the talk page. If this template is removed, do not replace it. This message has remained in place for seven days, so the article may be deleted without further notice. Find sources: "Secure error messages in software systems" – news · newspapers · books · scholar · JSTOR Nominator: Please consider notifying the author/project: {{subst:proposed deletion notify|Secure error messages in software systems|concern=Essay-like how-to content}} ~~~~ Timestamp: 20111230014754 01:47, 30 December 2011 (UTC) Administrators: delete |
In computer security and usability of software systems, an important issue is the design of error messages in a way that prevents security vulnerabilities. This aspect of software security has only recently begun to receive increased attention. Some of the primary recommended design principles include:
- When asking a question, give the user enough information to make an intelligent decision. Otherwise, for lack of information, they will choose the choice that allows them to make progress, often resulting in compromised security.
- Don't give so much information that the user is overwhelmed or confused and so unable to make an intelligent decision. If this additional information is sometimes useful for debugging or advanced diagnosing, either hide it by default, log it in a separate location, or require special privileges to view it.
- Don't give error messages that could be exploited by a cracker to obtain information that is otherwise difficult to obtain. Again, if this information is useful, log it in a separate location or strictly limit access to it. A commonly-cited example of this is a system that shows either "Invalid user" or "Invalid password" depending on which is incorrect. This allows an attacker to determine a valid username without knowledge of any user passwords, and so is considered[citation needed] by some to be less secure. Another common example is the IIS 5.0 web server's error page, which features a complete technical description of the error including a source code fragment.
External links
- Everett McKay. MSDN: Writing Error Messages for Security Features.