63

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.

EDIT

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.

Standalone software

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.

Linux:

OpenSSH via modified auth-passwd.c; using PAM via overloading pam_sm_authenticate function

EDIT #2

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)

edwinksl
  • 109
  • 6
Drew Lex
  • 2,013
  • 2
  • 19
  • 24
  • Related (about a specific case, whereas this question is more general): [Should passwords be revealed in error message?](http://security.stackexchange.com/q/15452) – Gilles 'SO- stop being evil' Jul 05 '12 at 00:22
  • User should be delayed and logged but not with plaintext password. You need to have user on separate thread or context to do it, or it might freeze other users in some cases. – Andrew Smith Jul 05 '12 at 04:54
  • Related: http://security.stackexchange.com/questions/8323/is-it-legal-to-log-passwords-from-failed-logins – Andrei Botalov Jul 05 '12 at 07:07
  • @AndrewSmith "_You need to have user on separate thread or context to do it_" can you explain what you mean by "context"? – curiousguy Jul 05 '12 at 15:48
  • I've seen trojan'ed `ssh` and `sshd` binaries on rooted servers in several instances which have been modified to (along with installing a "back door" password) log successful passwords to a file hidden somewhere. I imagine it's part of a kit, since I see the same code everywhere. Which just goes to emphasize the importance of **using SSH keys**. – tylerl Jul 06 '12 at 00:39
  • @tylerl "_Which just goes to emphasize the importance of using SSH keys_" Couldn't a "trojan'ed `ssh`" leak your SSH private key? – curiousguy Jul 06 '12 at 23:22
  • @curiousguy Your key should be stored safely on your own computer, not on your server. – tylerl Jul 07 '12 at 05:26
  • @tylerl I see: the server is compromised, not the computer from where you `ssh` (and you don't use the `ssh` client on the server). Anyway, the `sshd` does not need your password to access all your files on the server. – curiousguy Jul 07 '12 at 05:59
  • 1
    @curiousguy The implication is that since it is frequently the case that the same password is used on multiple servers (not wise, but common nonetheless), if the sshd gathers these passwords, they can be useful for spreading the attack. Using ssh keys minimizes your exposure. The ssh client on the server is trojaned for the same reason, which is why it is unwise to use SSH *from* a suspect server (or indeed any server if it can be avoided). Exposure can be further limited by using a key agent, but that comes with its own exposures, so... – tylerl Jul 07 '12 at 07:01

5 Answers5

72

Logging the value of a failed password attempt (cleartext or otherwise) seems like a security anti-pattern. I've never seen a web app that does this, and I'm not aware of any default system services such as SSH that do either. As pointed out by @tylerl below, most systems simply log meta-information about an access attempt (e.g. username, time, perhaps IP address, etc.).

Why This Should Be a Security Anti-Pattern

Offhand, I can think of three reasons why logging the value of a failed password attempt is a bad idea:

1. User Typos

It's extremely common for people to mistype a password by one or two characters. Examining a log file of failed attempts would make many of these easy to figure out, especially if you could contrast a sequence of failed attempts with a successful auth.

2. Guess-and-Check

Many people have two-or-three passwords they cycle through for everything. Consequently, when they forget which password they used on a given site, they just cycle through all of them until they find a match. This would make it trivial to hack their accounts on other sites.

3. Log Bloat

Storing failed passwords serves no useful purpose for the vast majority of authentication services in production today. While there may be some edge cases, for most people, storing this data is simply throwing away disk space.

On Relevant Legislation / Standards

I don't know of any standards (PCI, HIPAA, etc.) that specifically address procedures for storing failed login attempts, but I think that granted the above facts a good legal argument could be made for why the same standards that apply to storing passwords in general should also apply to failed-password attempts as well. In other words, you could make a legal argument that a failed-password is still categorically a password, and as such it is subject to the same standards.

While I'm certainly not a lawyer, I wouldn't want a judge to have to decide whether or not I was negligent or in violation of industry standards because failed passwords were stored in cleartext and consumers suffered the consequences. I don't think that would end with a favorable decision.

I agree with the OP that it might be useful for the various standards bodies to address this issue specifically (if they indeed haven't already). To that end, my suggestion would be to create a compliance standard of not storing the value of failed password attempts at all.

Mark
  • 1,320
  • 1
  • 11
  • 12
  • 1
    Under HIPAA, I believe that you need generate a failed login attempt audit record(without password information), but they don't say anything about logging. If it's not in HIPAA, then implementation frameworks like IHE require it. – Oleksi Jul 05 '12 at 03:34
  • 1
    @Oleksi good point. I've updated my answer to specify that I meant storing the value of an access attempt. Any software in the Healthcare industry should maintain a log of both successful and failed access attempts as part of the HIPAA/Meaningful Use auditing controls. Of course, that log should not include the password values. – Mark Jul 05 '12 at 03:41
  • according to the [article:](http://www.dailymail.co.uk/news/article-1255888/Facebook-founder-Mark-Zuckerberg-hacked-emails-rivals-journalists.html) suggested by [@dr jimbob below](http://security.stackexchange.com/a/16839/10923), Facebook was collecting the value of failed passwords attempts as early as 2004. There's nothing in terms of legislation that I am aware of that might have required them to remove such practice. – Drew Lex Jul 05 '12 at 10:59
  • 9
    @DrewLex - Facebook is a perfect example of what NOT to do when it comes to security and privacy. – Ramhound Jul 05 '12 at 11:48
  • 2
    @Drew Lex - While facebook still has frequent security holes/privacy breaches, I doubt they log incorrect password attempts anymore (and businessinsider's accusation from an anonymous 'friend' that Z bragged about it is not proof that this actually happened -- people lie). It seems more likely for a college kid acting on his own to do something like that (why not log information could be useful/cool), versus a billion dollar multinational corporation with real professionals who may worry about doing things that could only be helpful to do illegal things. – dr jimbob Jul 06 '12 at 15:16
  • PCI defines "Password" as the following: >A string of characters that serve as an authenticator of the user. – Drew Lex Jul 06 '12 at 18:29
  • Kevin Mitnick was doing a hack and had a logger on a remote server. An inexperienced sysadmin could not exactly remember the password for the server, so the sysadmin kept cycling through his passwords (all of which were network passwords), making Kevin's job easier in that he no longer needed to hack/crack passwords. Allowing a program to record failed passwords is pretty much doing the same thing – cutrightjm Feb 22 '14 at 14:38
  • 1
    My boss initially wanted me to lock a SHA256 of the failed password in the table, and I managed to persuade him against it. But I'm thinking it could be useful to store a bcrypt hash+salt of the last failed password and use it to determine if the same wrong password is retried (we have an IoT use case where devices may keep autoonomously trying to log in with the wrong password) – Andy Apr 11 '19 at 00:51
17

There's no legitimate purpose to log plaintext passwords for any application; especially for an incorrect login. It may be logged by chance--I've casually looked at auth.log for other purposes, and seen an user accidentally type their password into the login field (and I do record the login fields to see what accounts are attempted to be logged in) -- however I notified the user of it and they changed their password.

On the flip-side, as a user the conservative assumption is to say that every random application you use is logging every password of incorrect attempts. This is why it is a bad idea to have a small (three) of random passwords you cycle through, versus a unique password for each site managed in an encrypted password list (possibly using a tool like keepass).

On this note, Mark Zuckerberg (facebook founder) has been accused by businessinsider.com of using logs of login/password combinations (even from incorrect entries) from thefacebook.com (an early version of facebook) to hack into the email accounts of Harvard Crimson journalists who were investigating him. From the daily mail::

However after further claims emerged, Zuckerberg apparently became anxious that the paper would run a story on him after all.

Business Insider claimed he then told a friend how he had hacked into the accounts of Crimson staff.

He allegedly told the friend that he used TheFacebook.com to search for members who said they were Crimson staff.

Then, he allegedly examined a report of failed logins to see if any of the Crimson members had ever entered an incorrect password into TheFacebook.com.

Also somewhat relevant xkcd (imagine that the evil accounts also logged attempted passwords to increase their success rate).

Community
  • 1
dr jimbob
  • 38,768
  • 8
  • 92
  • 161
  • 1
    +1 just mentioning the XKCD would be enought to explain everything – woliveirajr Jul 10 '12 at 20:04
  • @dr jimbob - Re "There's no legitimate purpose to log plaintext passwords for any application" - what about determining if an user account is attacked by means of brute force? – Drew Lex Jul 14 '12 at 01:29
  • 1
    @Drew Lex - You can (and should) log that someone has entered an incorrect password to some user's account from IP address at some time, and possibly enable extra security (require CAPTCHAs, delays between retries, block an IP address, lock an account, etc) if the failed logins are too frequent (e.g., starting at about ~5 consecutive attempts). But there's no legitimate reason to log the passwords they actually are typing. – dr jimbob Jul 16 '12 at 20:07
  • +1 for XKCD, it has all the necesary info in it ;) – Radu Maris Mar 06 '13 at 15:31
  • @drjimbob, I had this idea that I asked a question about, can this be a point in your opinion? thanks http://security.stackexchange.com/questions/66484/temporarily-save-failed-logins-password-hashes-for-using-against-brute-force-att – dav Mar 11 '15 at 12:24
6

It is not uncommon to log the fact that an authentication attempt has failed and which user it was for. This can prove very useful in forensic troubleshooting. It is extremely uncommon and irresponsible from a security perspective to log what the password was that was rejected. This information serve no useful purpose and can be used against you.

EDIT
You should hopefully be able to expect that a reputable and well-organized company would not be selling your password information since this would really be bad for them if it was found out. But in the interest of your own security, you should always be prepared for information you give out to be used against you because it is always a possibility. This goes double for any organization whose reputation you can't reliably establish.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • +1 I adjusted my answer to clarify that I meant logging the cleartext value of a password attempt. I also updated with a reference to your reply on what meta-information is valuable for auditing/logging purposes. – Mark Jul 05 '12 at 03:34
6

There are some terrific answers above, so this is just a quick and simplified perspective from the U.S. government polices on managing computer systems which process classified information.

(1) The entire computer system must be protected to the highest standard required by any data on that machine. This includes logs stored on or off the machine.

For example, if you intentionally or accidentally put "secret" data on a computer, EVERY part of that computer must now be protected as "secret" information. This is the case even if you had an unclassified computer (like at home for example) which received an email with classified information. The entire computer, and everything on it is now classified "secret."

(2) The passwords to that machine are also classified at the highest level of protection required by any data on that machine.

For example, if you have any "secret" data on that machine, wherever you store the password it also requires that same level of protection.

As applied to your question, regardless of the standard you are applying, such as PCI-DSS, NISPOM, etc, you can not have passwords in clear text in the logs if the requirement is that they be protected (such as hashed and salted).

So in summary, if any regulatory scheme is applied to your computer system in question, and that regulation says you can not have clear text passwords, then you can not have clear text passwords in your logs.

OnTheShelf
  • 309
  • 2
  • 1
  • 1
    I agree that it should be the case that any string of characters entered via password field should be considered as "user data" or "password data" regardless if this turns out to be valid or not. Unfortunately, "password" is defined as the string that validates, meaning that values that don't meet this criteria fail to be considered passwords. No standard defines this broader def of a "password". [SP800-53](http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf) is quiet about failed password values. – Drew Lex Jul 14 '12 at 01:39
  • 3
    Any information a user asserts as a security token, even if misspelled, will be treated as a password by any competent regulatory authority. A security manager using an argument that a user asserted password which fails to authenticate the user does not require protection at the level of the system should be removed from their position on the grounds of malfeasance. In most regulated environments I would also expect them to be barred from future work in regulated security programs. More importantly it would make them look incredibly amateurish. – OnTheShelf Jul 19 '12 at 23:12
2

No. It is common for users to have a pool of passwords, and to cycle through them trying to figure out which one is in use for a given site. Logging just means that when you get compromised, their alternates get added to the cracker pool of whoever hit you.

John Haugeland
  • 21
  • 1