Abstract
Incorrectly using, or failing to use, authentication mechanisms can introduce vulnerability.
Description
The following are frequent design defects that produce vulnerable systems:
Using no authentication when it is required.
Failure to understand the limitations of the authentication scheme or mechanism. For example, HTTP basic authentication authenticates the user, not the server.
Failure to separate authentication and authorization.
Designing passwords that are inherently weak and disallowing passwords that are strong. For example, a system that supports only eight-character passwords composed of alphanumeric characters is a poor design (something that many web sites do) [VU#243592].
Using weak authentication based on untrustworthy attributes, such as network address information [VU#30308].
Disabling a subsystem's built-in access controls through identity sharing. This is a common practice in web sites that use back-end databases.
Failing to propagate authentication across a multi-tier application.
Designing a secure container for secrets and then exposing the secrets outside the container. This has occurred in several implementations of smart cards.
Applicable Context
Missing, incomplete, or incorrect application of an authentication mechanism.
Impacts Being Mitigated
Minimally: The least impact of this vulnerability is unauthenticated access to computing resources.
Security Policies to be Preserved
Access to computing resources is granted only to authentic individuals.
References
Citation | Bibliographic Entry |
---|---|
[VU#243592] | Cohen, Cory & Lanza, Jeffrey. Vulnerability Note VU#243592: Alcatel ADSL modems provide EXPERT administrative account with an easily reversible encrypted password. http://www.kb.cert.org/vuls/id/243592 (2001). |
[VU#30308] | Rafail, Jason. Vulnerability Note VU#30308: lpd hostname authentication bypassed with spoofed DNS. http://www.kb.cert.org/vuls/id/30308 (2001). |
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
NO WARRANTY
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.