Upon reviewing the Logs generated by different SIEMs (Splunk, HP Logger Trial and the AlienVault platform’s SIEM) I noticed that for some reason quite a few users tend to make the mistake of typing their passwords in the username field, either in the OS Domain logon, or within web applications. I am guessing those are people who cannot type without looking at the keyboard and in trying to do so, doing it fast, end up typing their passwords in the wrong field. This means that the password is sent in plain text everywhere in the network and end up recorded on the logs with an event that says something along the lines:

```
User P@$$w0rd does not exist [...]

```

Or

```
An account failed to login: P@$$w0rd [...]

```

(where P@$$w0rd is the actual user's password)

It becomes pretty obvious to work out to whom the passwords belong: usually the previous or very next (un)successful event on the same log file will tell you an event triggered by the same user. 

Any other Analyst, looking at the logs, could get someone else’s credentials without the due owner even being aware of that; the worst case scenario is network eavesdropping, or actual log file compromise. 

I am looking for a general guidance to help preventing this. I assume simply masking the username is not feasible and even if it were, this would probably eliminate a lot of the log analysis for not being able to tell who did what.

**Note:** There is already a post on a similar issue, but I am trying to address a way to prevent it.
[What's the risk if I accidently type my password into a username field (Windows logon)?](https://security.stackexchange.com/questions/14907/whats-the-risk-if-i-accidently-type-my-password-into-a-username-field-windows "What's the risk if I accidently type my password into a username field (Windows logon)?")

---

**Accepted Answer:** I wish I could select a few answers from the list. Unfortunately I have to stick to just one in the forum, but in practice I can combine them. Thanks very much for all the answers; I see there is no single solution. As I agree that adding 'things' add complexity which increase likelihood of security holes, I have to agree with most of the voters that @AJHenderson has the most elegant and simplest answer as a first approach. Definitely SSL and a simple code verification on the server or even at the client side. As I am looking to mitigate not against malicious users, but the distracted ones, this will do fine. Once this is in place, we can start looking at expanding the implementation to ill-intended users if appropriate. Thanks ever so much again for everyone's input.