2

From time to time, some users can accidently type their password in the username field, either because they missed the tab key or because they thought their account was simply locked, not logged out (on Windows for example).

According to some questions on this site, if passwords of failed authentication attempts should not be logged, usernames often are.
That question even states that:

It seems reasonable that someone (even a security-conscious admin) would consider logging attempted usernames both useful and safe.

How is it useful or safe?
Are their other benefits to logging the username of a failed authentication attempt?

Clarification: I'm mostly interested in the logging of unknown usernames, but answers to the more general question are welcome.

1
  • 3
    In reality, of course, it's not safe at all. Would you like to find your user's passwords? Search for Windows Event ID 4625 and you'll catch all those people who mistakenly typed their password into the user field - a useful side effect of Windows requiring just the password except when (tada) they require both the username and the password to unlock.
    – gowenfawr
    Jul 11, 2018 at 13:12

3 Answers 3

4

The reason you log failed login attempts to accounts is to determine if they are under brute force attack. If the account is sensitive enough, you might then consider putting in additional protections for that account.

Note that brute force attacks do not have to happen all at once and then stop. The clever attacker will try 4 attempts, then wait 15 minutes, then try again.

If you do not log the account name, then you would not know this was happening.

11
  • I disagree, there are plenty of methods used to determine brute force that don't involve the username. It's the skiddy method of trying to determine if brute forcing is happening. Jul 11, 2018 at 16:01
  • @ShaneAndrie and do you have one method to share?
    – schroeder
    Jul 11, 2018 at 16:05
  • IP/Host based source location or time based events. Brute force doesn't typically happen directly on a system. An attacker who try to brute force than wait 15min's is wasting time and the pattern is predictable. Typically a brute forcing event directly at a server for is multiple attempts with different accounts to maximize the time to check for passwords. The username doesn't mater. Brute forcing is typically automated, an the time to try a password is near instantaneous versus a more human-like behavior. Jul 11, 2018 at 16:17
  • @ShaneAndrie I'm thinking that you misread my answer. I'm talking about knowing the target is under attack, not that an attack is happening.
    – schroeder
    Jul 11, 2018 at 16:25
  • 3
    @CidTori well, in my experience, it has been very useful to discover mis-configured services reaching out to unknown services
    – schroeder
    Jul 11, 2018 at 18:44
0

Why log authentication attempts at all if all you're giving yourself to work with is a timestamp, IP address and response code? That doesn't give you any actionable information, unless you're only concerned with implementing IP bans after a number of failed attempts and you have no interest in incident response or remediation.

How is it useful or safe?

If a user types their password in the username field, it's really not that much different than accidentally disclosing it in any other field. They can (and do) accidentally paste it into a chat window or in the address bar (shows up in DNS logs) after grabbing it from their password manager. We can't do away with logging altogether just because users make mistakes that might disclose their password.

When I see passwords logged in the username field, I simply reach out to those users and tell them their password was disclosed and will begin propagating throughout systems and databases, so they need to change it immediately to avoid potential compromise. They made the mistake, so it's on them to fix it-- not for me to reconsider the merit of our logging infrastructure.

Are their other benefits to logging the username of a failed authentication attempt?

If you aren't logging usernames, how do you know if someone is enumerating all of the accounts in your AD, or just really heavily targeting one user?

Without usernames, how can you tell whether or not the attacker is randomly guessing at stock accounts (root, admin, etc) or whether they're targeting sensitive individuals (executives, R&D leads, etc)?

If you see a bunch of failures followed by one or more successes, it's safe to assume a user was compromised. Your boss is under fire and demands answers-- tell me which user(s) were compromised, now!

Take all of your logs and mask the username out from all of them. Pick one event and assume it's an indicator of compromise. Also assume you're in a messy corporate environment that's NATted to hell and obfuscates the IP address at every step. Now tell me how this actor might have moved laterally within your network, starting with that event.

Logging across systems is often incomplete, and enterprises generate a ton of simultaneous events so correlation of timestamps is not always an option. We log details, as many of them as feasible, for a reason-- but if you're not logging something as critical as usernames on failed authentication attempts (literally the record of who's causing trouble at your front door), you're blinding yourself for the benefit of your most incompetent users.

3
  • Judging by the rather aggressive tone of your answer, my question may have upset you. I apologise if that's the case.
    – CidTori
    Jul 12, 2018 at 7:24
  • And what about unknown usernames? (see my clarification)
    – CidTori
    Jul 12, 2018 at 7:24
  • Heh. I'm just a grouch by nature. No offense taken or intended :)
    – Ivan
    Jul 12, 2018 at 7:28
0

I think you want to find out which users are under attack.

But for this you do not necessarily have to log the original username input. It would be sufficient to log a hash of the username and compare that to the hashes of all known usernames.

You must log in to answer this question.

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