Note: This page is part of the us-cert.gov archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact info@us-cert.gov if you have any questions about the US-CERT website archive.

Note: This page is part of the us-cert.gov archive.

This document is part of the US-CERT website archive. These documents are no longer updated and may contain outdated information. Links may also no longer function. Please contact info@us-cert.gov if you have any questions about the US-CERT website archive.

Use Authentication Mechanisms, Where Appropriate, Correctly

Original release date: June 19, 2013 Author(s): William L. Fithen Maturity Levels and Audience Indicators: L4  / D/P  SDLC Life Cycles: Implementation  Copyright: Copyright © Carnegie Mellon University 2005-2012.

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

Security Policies to be Preserved

  • Policy #1

    • Access to computing resources is granted only to authentic individuals.

References

CitationBibliographic 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.