While authenticating, should attempts with invalid user names be logged? OWASP Logging Cheat Sheet says that authentication failures must always be logged. I can observe several programs doing this, including login on Linux:

login[1234]: FAILED LOGIN 1 FROM tty2 FOR foo, Authentication failure

It has happened that I accidentally typed in the password in the user name field which is then logged. Should a (web) application always log invalid user names? Why would it not be sufficient for an authentication system to log only invalid authentication attempts for valid user names?


5 Answers 5


Yes. But on the other hand you don't want the log file to potentially contain the passwords, which would happen if someone botched the login and sent the password instead of the username.

What I think might be a viable compromise could be to log:

  • attempts with valid usernames and invalid passwords, logging the username but not the password.
  • attempts with invalid usernames (which might be passwords or whatever), logging the username as "INVALID".

The rationale is that several attempts with a single valid username will tell you of a possible bruteforcing against that username; a swarm of attempts against the INVALID username will warn of a large-scale "username with obvious password" attack, which, if you have a proper password policy, is irritating but harmless. Even more so the attempts against well-known users.

It is conceivable that someone might be attempting to bruteforce a single invalid username; if that's a concern, you might log invalid usernames as (partial and/or salted) hashes. The value of this cleartext information, even if captured by hostile parties, would be essentially nil.

A very small number of attempts on the INVALID username may be due to users misspelling their own names, or entering the password instead of the name; or paranoids that intentionally botch their first login believing this to protect against credential capture.

Especially if quickly followed by a valid login from the same address (unless it's a system masquerading a large network...), an occasional authentication error of this kind could be considered noise and ignored.

(You might further distinguish a small set of "valid invalid names" such as info, admin*, Administrator, guest, if you wanted, but that's probably overkill).

Also, for the truly paranoid, you could pad all valid usernames and the string "INVALID" to be the same, fixed length (say... 20 characters?). If by any chance an attacker could be able to remotely observe the log file's growth, he would thus be unable to tell whether a username was existing or not on the system.

  • This expresses exactly what I was thinking of, targeted attacks with correct usernames should be logged, where invalid usernames come from typos in the username, entering a password or stupid bots (which take a dictionary and hope that insecure credentials are used).
    – Lekensteyn
    Commented Mar 29, 2013 at 16:17

You should log invalid usernames.

Consider the scenario where an attacker is performing an online bruteforce attack against your service using a dictionary of username and passwords. The attacker is not performing a targeted attack against any particular account on your system, instead he is trying out random usernames.

If you do not log invalid usernames, there is a chance that a bruteforce attack might go unnoticed. If you log invalid usernames as well as information such as IP addresses, there is a higher chance of being able to recognize a bruteforce attack against your system which allows you to take appropriate actions to stop the attack.

  • If a brute-force attack is going on (possibly from multiple IP addresses), it should be sufficient to log the attempt without username right?
    – Lekensteyn
    Commented Mar 24, 2013 at 13:14
  • 1
    But what if you wind up logging passwords in cleartext? You have to treat the log file as full of passwords. Commented Mar 26, 2013 at 12:58

You can log the encrypted value of the invalid usernames.

If someone is performing a brute force attack from multiple IP addresses, you can/have to identify it by analyzing the traffic on your web server, not by looking at the logged usernames. This can be done at the application layer. If you receive an unusual number of login requests from an IP address, you can simply block that IP address (for a period that you think would be appropriate). Otherwise you might find your web server compromised long before you get a chance to look at the logged usernames/passwords.

But now assume a legitimate user accidentally enters his/her password in the username box. If you store the raw text, the logged username (password) can be read by an intruder (assume an intruder has somehow gained access to your data files). Your goal is to make the data unreadable by the intruder in this situation. This is when encryption comes in handy.

If you are using a DBMS, the encryption can be done by the database system. For example you can encrypt the tables/columns that store the usernames and hash the passwords.

If, you are storing this information in, let's say a CSV file, this encryption can be done at the application layer. If you are able to use public key cryptography, then your life is going to be easy. The application can simply encrypt the entered values using the public key and you (or whoever knows the private key) can decrypt them with the private key - it should be fairly easy to keep the private key safe. If you have to use symmetric key cryptography, there are several ways to store the secret key securely (do a search online). It may not going to be as secure and as easy as using public key encryption but it is much better than keeping raw text, right?

Bear in mind that the goal is to make intrusion costly, not to make your system 100% immune... because that's simply not practical.

  • Encrypted or hashed? Encryption with a symmetric key is useless and asymmetric is probably computationally expensive for these purposes?
    – Lekensteyn
    Commented Mar 29, 2013 at 16:11
  • Encrypted, not hashed. There is absolutely nothing wrong with symmetric encryption and there are several ways to implement this solution. You might also want to mention the reason you think symmetric encryption is "useless".
    – Radix
    Commented Apr 4, 2013 at 17:12
  • 1
    What is the point of encrypting the usernames? If it is for anonymity, it will fail when (logging/application) server is compromised.
    – Lekensteyn
    Commented Apr 4, 2013 at 17:17

Follow the link makerofthings7 provided as a comment, as that had a lot of detail on how to stop it in the first place, but you should still log all attempts.

Why would it not be sufficient for an authentication system to log only invalid authentication attempts for valid user names?

An invalid log-on attempt could indicate a possible attack. If you only log those with valid usernames, you will not see all of the attack which may help you counteract the attempt better if it is distributed or it may give you some other useful information.

In a rare case, if the log is exposed/accessible, the attacker could use this to enumerate valid/invalid usernames (A/B test on each logon; though if your logs are publicly exposed...).

The root problem is that the password might be logged. This could also happen with a low likelihood if the user typed the password in the username field, but still put some content in the password field.

In may be best to encrypt the whole log or at least the username portion (or any other PII that is included) when stored. Any SIEM, etc can still correlate if the encryption is always the same for a given value. Since its a good idea to store all invalid attempts, encryption allows you to keep all of that an limit exposure of passwords.


I think this question is driven by case-definition and it varies according to requirements for analysis. Consider this,

An attacker using dictionary brute force attack; can lock legitimate users (considering) he keeps a dictionary that is well-social engineered for his attack environment. In this attacker is abusing the account lockout policy.

Now, in the above scenario was a honeypot system (running vulnerable telnet service) you can learn a lot about the attacker way of using the dictionary. If the users in the dictionary matches the organization lists you can probably alert system administrators to change usernames.

like some maths and stats can help on analyzing trend e.g data say that the attacker is hitting the right username after 80% failed attempts after every five minute. This number gives you the safe or grace period for action.

  • What you are trying to say is that you are for logging usernames so that admins can know if a particular user is getting hit? Secondarily, as a means to perform research on brute-force techniques.
    – schroeder
    Commented Mar 26, 2013 at 23:40
  • @schroeder thats pricely what i mean.
    – Saladin
    Commented Mar 27, 2013 at 4:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .