Passwords being sent in clear text due to users' mistake in typing it in the username field

One thought is to not allow form submission if there is not a value in the password box. Generally if they accidentally entered the password in the username, then there likely isn't going to be anything in the password dialog.

It is worth noting that this does not have to be simply done client side, but could also be done on a server as long as the transport used is secure and the input is not logged until after passing a check about the password field not being empty.

Assuming your backend application and SIEM needs to view failed login attempts to various applications (and thus show the "User P@$$w0rd is not valid" error message) then it is not going to be trivial to stop this.

However, ensuring that all applications that send sensitive data including usernames and passwords implement HTTPS (encrypted HTTP using SSL) is a good way to ensure that network devices and anyone on the network can not obtain the password that was mistakingly entered into the username box!

So the problem is that you don't want analysts to see the passwords in the sensitive log files?

Caution: Even if you were to use Javascript it doesn't deal with the password data that is stored on your disk in plain text.

A better solution is to preprocess the logs before the analysts see them and redact information in the logs.

You can do this line-by-line filtering if you whitelist lines or blacklist other lines. For example:

You can whitelist usernames when they appear in a log file that

• Have a pattern ( [az] + number) or ([az] + period + [az])
• include a Domain Name followed by a slash "\" for AD environments
• appear multiple times
• Can be washed against an LDAP directory of known usernames before the analysts see it

You also identify and blacklist passwords by:

• The password policy often follows a pattern (one symbol, upper/lower, x characters...)

You can use this knowledge to build a custom log data cleanser to protect the information you don't want analysts to see.

So what does a filtered line look like?

You can simply redact questionable usernames by hashing them, and assigning them a human ID and storing them in a secure location:

 eb574b236133e60c989c6f472f07827b   Redact1
 7e67b89a695bfbffc05b7ed2c38f927f   Redact2
 ..etc

The analysts can see if a particular entry is occurring over and over again if the hash repeats in frequency.

The exact hashing method (or encryption method) you choose is subject to risks since this "hash database" will contain high value information. And seeding will (by its nature) prevent frequency analysis which may or may not be of value to you.