CA-2000-01 Poor Error Handling in Password Authentication May Result in Authentication Failure

This advisory is being published jointly by the CUSERT Coordination Center,
d0d-CERT, and the d0d Joint Task Force for Computer User Stupidity (JTF-CUS).

Original release date: February 19, 2000

Last revised: December 25, 2012

A complete revision history is at the end of this file.

Systems Affected

  • ASCII based Password Authentication Modules


Poor error handling in many Password Authentication Modules which rely
on ASCII based data-input may result in a failure to authenticate users.
This could result in a denial of service to those users.

I. Description


Most Password Authentication Modules accept user input in the form of
ASCII encoded characters. The ASCII character set represents characters as 8 bit
binary values, with different values for each character, including different
values for upper and lower-case letters.

Most keyboards include a key labeled “Caps Lock”
which toggles an LED light on the keyboard itself on and off. While this light
is on, all keyboard input is interpreted to be in upper-case.

ASCII based Password Authentication Modules, due to a limitation in
the ASCII Character Set, and poor error handling will interpret these upper-case
letters to be different from lower-case letters.

II. Impact

Users may unintentionally provide Password Authentication Modules with
the correct password in upper-case, however poor error handling may cause that
password to be interpreted as incorrect, resulting in a denial of service to the

Use of Less-Common Character Sets May Present Additional Risk

Browsers interpret the information they receive according to the character
set chosen by the user if no character set is specified in the page returned by
the web server. However, many web sites fail to explicitly specify the character
set (even if they encode or filter characters with special meaning in the
ISO-8859-1), leaving users of alternate character sets at risk.

III. Solution

Solutions for Users

None of the solutions that users can take are complete solutions. In the end,
it is up to the Password Authentication Module developers to modify their
applications to eliminate these types of problems.

However, users have two basic options to reduce their risk of being denied
service through this vulnerability. The first, ensuring that the Caps Lock light
is not lit, provides the most protection but has the side effect for many users
of disabling functionality that is important to them, such as typing in ALL CAPS
in Internet Relay Chat (IRC) rooms and electronic mail.

The second solution, holding down the “Shift” key while the Caps
Lock light is lit, will allow passwords to be entered in the correct (lower)
case, however this method is inconvenient and users may often forget to perform
this action before authenticating.

The third solution, not using any services that require password
authentication, will significantly reduce a user’s exposure. Users should select
this option when they require the lowest possible level of risk.

Users who decide to continue operating their password authenticated services
should periodically revisit the CUSERT/CC web site for updates, as well as
review other sources of security information to learn of any increases in threat
or risk related to this vulnerability.

CERT/CC Contact Information

Email:¬†[email protected]


+1 900-IMA-USER (24-hour hotline)

 CUSERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)

Monday through Friday; they are on call for emergencies during other hours, on
U.S. holidays, and on weekends.

Getting security information

CUSERT publications and other security information are available from our web

Copyright 2000 Blake R. Swopes.


Any material furnished by Computer User Stupidity Emergency Response
Team/Coordination Center is furnished on an “as is” basis. CUSERT
makes no warranties of any kind, either expressed or implied as to any matter
including, but not limited to, warranty of fitness for a particular purpose or
merchantability, exclusivity or results obtained from use of the material. CUSERT
does not make any warranty of any kind with respect to freedom from patent,
trademark, or copyright infringement.

Revision History

February 19, 2000: Initial release.
April 23, 2000: Corrected obsolete link in page
February 1, 2001: Modified CUSERT link.
May 12, 2001: Fixed formatting errors.
December 25, 2012: Moved to new CMS.

Share the love

Leave a Reply