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.

CidTori
  • 183
  • 6
  • 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 '18 at 13:12

3 Answers3

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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • 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. – Shane Andrie Jul 11 '18 at 16:01
  • @ShaneAndrie and do you have one method to share? – schroeder Jul 11 '18 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. – Shane Andrie Jul 11 '18 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 '18 at 16:25
  • That's an interesting reason to log an username corresponding to an existing account, but what about an unknown username? (see my clarification) – CidTori Jul 11 '18 at 18:05
  • 3
    @CidTori well, in my experience, it has been very useful to discover mis-configured services reaching out to unknown services – schroeder Jul 11 '18 at 18:44
  • Well I was thinking more about a Human to Machine than a Machine to Machine context, but that's a valid point. So what about a user-typed unknown username? – CidTori Jul 12 '18 at 07:58
  • How does one tell the difference between the two? – schroeder Jul 12 '18 at 08:00
  • Most of the time, you know if the service you design is meant to be used by humans or machines. So I'm talking about a situation where you know that most users will be humans. – CidTori Jul 12 '18 at 10:51
  • Well, then, your question is getting very, very specific. For systems that are logging user-based user access, is there a security benefit to logging the *username field* of a *failed login attempt* of a user that is *not in the user database*? With this refinement, the answer could be 'no'. Then you are in Shane's domain above where all you need to know is that there is an attack happening because the target does not exist. – schroeder Jul 12 '18 at 11:32
  • Well yes it's specific, as were your answers: the benefits are knowing that an user account is under brute-force attack (which does not apply if the username is not linked to an account) or that a service is misconfigured (which does not apply if the user is not a machine, because I suppose a human would check again it's username or have it sent to them if they can't remember it). I just wanted to be sure that there were no other benefits for you. By the way, could you add the benefit about misconfigured services in your answer? – CidTori Jul 12 '18 at 15:05
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.

Ivan
  • 6,288
  • 3
  • 18
  • 22
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.

Michael Ströder
  • 307
  • 1
  • 6