While selecting unique passwords for each purpose is a great idea, in practice this rarely happens. Therefore many select passwords from a personal pool of passwords that are easily remembered. When authenticating into systems that are used infrequently it is very probable that a number of passwords from such pool are tried sequentially. Alternatively, failed passwords are very close to the actual password in case of a typo.
Since almost nobody describes the password policy in effect, including how rejected passwords are handled, should one start assuming that these are collected in a database that is sold to the highest bidder?
Is there an implementation guidance? What usually happens with a candidate password when this is rejected? Are they being logged, immediately discarded or left to hang around until garbage collected? Are failed password handling procedures part of any audited controls? It seems that there are plenty of implementation requirements and recommendations regarding how valid passwords should be handled, but vague regarding rejected password values.
I will try to list here the various implementations that log failed login security credentials in order to get a feel about how widespread this procedure is:
Content Management Systems:
Joomla via Login Failed Log plugin
This Small Plug-in collect logs about each failed login attempt of your Joomla site’s administrator and sends an email about each of those to the super administrator of the site with the username, password, ip address and error.
KPlaylist v1.3 and v1.4 - a free PHP system that makes your music collection available via the Internet.
is logging the usernames and passwords of failed login attempts in the apache error log
Drupal 5.x before version 5.19 and Drupal 6.x before version 6.13.
When an anonymous user fails to login due to mistyping his username or password, and the page he is on contains a sortable table, the (incorrect) username and password are included in links on the table. If the user visits these links the password may then be leaked to external sites via the HTTP referrer.
Reporting Server included with Symantec Client Security 3.1 and SAV CE 10.1
The administrator password for Symantec Reporting Server could be disclosed after a failed login attempt.
OpenSSH via modified auth-passwd.c; using PAM via overloading pam_sm_authenticate function
It seems that there is a consensus, and recording the failed passwords or PINS is regarded as a serious/major security risk, nevertheless as far as I know, the following standards provide no guidance, audited procedure or controls that specifically address this risk:
PCI-DSS: Passwords procedures addressed in 8.4. and 8.5. (failed passwords are protected only during transmission; after validation not considered passwords, therefore not required to be protected)
FIPS140-2: Authentication addressed in 4.3 (life-cycle of failed authentication data only partially addressed)