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

Question

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)?

---

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.

Answer 1

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.

Answer 2

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!

Answer 3

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.

Answer 4

I can only identify three problems with what you're discussing.

1. Users aren't inputting information correctly.
2. Analysts can discern passwords from logs.
3. Passwords are being sent in clear-text and are susceptible to man-in-the-middle eavesdropping.

In my opinion, this is fairly simple to fix.

1. Accept user error, grudgingly.
2. Don't log invalid usernames, instead log failed attempts and IP.
3. Don't send usernames in clear-text. Use technology like HTTPS or use javascript to encode the plain-text (e.g. ROT13).

Example log of a failed login and then a successful retry.

[00:00:00] An account failed to login from 192.168.1.100
[00:21:00] Successful login 'root' from 192.168.1.100

---

Reading over other answers, I would like to include this.

• Validate all fields prior to submission.
• Consider breaking up the form between multiple pages as Eric G mentioned.

Answer 5

A solution I have seen a few banks implement, at least in web apps, is to have a two page login.

1. On the first page accept only the username
2. On the next page in the process request the password and only echo the username back so it is not an editable field

Therefore the only input on the second page should be the password. Since the user knows they must clear the first page with a username, they know they must clear that gate, then the only option on the second page is the password.

If you can implement this workflow, it will help focus the users on what they are typing and when.

---

Also, considering your logging: Maybe you can change your logging to not include actual credentials?

E.g., On a successful login, use the primary key id instead of echoing back the input: "The user with id: '2342342' has attempted to logon" then "The user with id '2342342' has successfully provided a password".

If you do a lookup and the username is not there, then something like "User from IP address '192.168.0.10' attempted to logon with a non-valid user id".

This would be your app level logs. Web server logs may include query parameters, so that might be a little harder to address or maybe you can put some type of proxy filter in between the action and when the log is written to redact the log content based on certain rules. This would be platform specific, but it looks like it may be possible on Apache.

As a secondary control, limit read access to the various log files you are processing.

Answer 6

From what you describe of your architecture, this is infeasible, but in my opinion the correct solution is: Don't send the username in the clear, and don't log usernames of failed login attempts. The only place the username and password should go is to the subsystem which checks the password; until that occurs, the username is unauthenticated, arbitrary data — anyone with access to the login form, which in a web application is the entire Internet, can type in anything they want however often they want — and therefore tells you very little of interest. (Unless your login form is not exposed to the Internet.)

this would probably eliminate a lot of the log analysis for not being able to tell who did what....?

Given a username without the correct password, you don't know that the request is actually from that user, so you still don't know who did the login attempt.

Answer 7

Generally speaking, all client Code are Smart Enough to handle Basic Errors

1. User ID and or Password Missing
2. Password not matching the Guidelines

So in any case when you are still seeing these entries in the Log,

User P@$$w0rd does not exit [...]
An account failed to login: P@$$w0rd [...]

None of the Client Validation worked and the System ended up sending the unencrypted password over the network. So what was in the Password Field? Definitely not blank as the Client Validation would fail. It must me something different from password

So Make it a two pass authentication

1. First Pass, send all encrypted details including password to the server. Verify if Password field is empty.
2. First Pass, Verify if the Password matches the Guidelines else Error Out.
3. First Pass, next check if the password is present in your DB. If not Error Out.
4. Send back an RPC response to the Client and let it send the User ID and Password now.
5. Now perform the authentication process

The whole essence of this process is to

1. Minimize risk. Note, you cannot eliminate the risk to Zero
2. Not trusting the Client.

And finally, get your interface reviewed by a UX Expert. It may be, your interface has some flaw causing Users to enter Password in the ID field.

Answer 8

The general problem is password-based authentication. Every mom-and-pop shop insists on having own authentication with passwords. This is stupid.

Let some other identity provider do the hard work of keeping credentials secure. Do the same as StackOverflow does: allow authenticating with OpenID, Gmail, etc.

Your users will thank you for not needing yet another password somewhere.

Answer 9

Client side javascript seems reasonable.

Check password field is not empty, prior to submission. Check that the username is in a valid form. Especially elegant is something where the username is required to be an email address. You could additionally forbid password at your password set/change mechanism from being in the form of an email address. Then simply check that the username is in the form of a valid email address prior to submitting the form. This could be done similarly with say special characters or numbers. (E.g., numbers/special characters are required in passwords but forbidden from usernames).

Additionally, use an up-to-date library SSL for all form submissions (this should be done to prevent network eavesdroppers from listening in). Require elevated permissions to read these logs (e.g., the webserver account can write to these logs, but only root can read them). As soon as the password fails the authentication step, don't propagate the username to other systems. (Also use SSL between distinct internal systems to prevent network eavesdroppers).

Answer 10

I like the approach that my current company takes to this problem: if you type your password into the wrong box, an automated system causes your password to expire immediately. Thus the user has to change their password, and the password that is in the log is now no longer vulnerable.

Of course, this is still not ideal if the user is still using that password for another system, but hopefully being forced to change their password will make a user more cognizant of the possible security risks.

Answer 11

Mostly the EASIEST answer is the right answer. Now we notice that every email address has a "@" sign in it Just before the domain name. Making "@" a NON ACCEPTABLE key in password makes the solution pretty obvious. If the username does NOT have @ and ALL USERNAMES are email addresses, then Log only those that have atleast @ in them.

Now if the username DONOT have "@", it probably might make some users angry but this is a neat solution. That is to have ONE SINGLE special character that comes BEFORE a password. Just like ALL USERNAMES that are email accounts have a format. All answers have a special character at the start or at the end, whatever. So when the user is entering a password, you let him know that he needs to type it in.

Third solution is that COLOR CODING. Make username Field Yellow and Password Field RED. Red normally catches your attention because it is used for sensitive stuff. So even if they are looking at the keyboard, the will VERY QUICKLY LEARN that passwords are red. So basically the textfield AND THE label of password is red preferably in a separate box and Username label and textfield ALL YELLOW.

Answer 12

Why not just respond with this?

That username does not exist

Answer 13

How much control do you have over the receiving server's handling of this? It seems like the solution that a user proposed above, to hash both the username and password, would be workable a couple of ways:

Method 1 (requiring JavaScript): Hash both username and password. In your database, store hashed usernames, and then do your auth lookup using that field. This would be ideal if you have some control over the way the data is treated on your server, but do not control its logging capacity.

Method 2 (not requiring JavaScript): Receive username in plaintext as usual, but convert it to a hash as in method 1 once you receive it on the server. When the attempt fails, log the hash, not the username. The logs will still be useful (slightly less useful when inspected cursorily), since each hash will still uniquely identify a user. Neither of these are as elegant as the top response here (and I would suggest using that as well), but they are more thorough.

Answer 14

A simple, yet annoying solution could be to have a on-screen keypad layout of html buttons, where users can only type their username using these buttons, this will prevent the mistake from being made, I realize how annoying this could turn out to be, but after the first login, you could use a cookie to remember the username and not require it again. Javascript will be required of course. Now its impossible to send the password in plain text by accident. Hope it helps.

Answer 15

I have a different take... What problem are you trying to really solve?

1. Bad passwords? I.e. when you see a person use "password" (or a variant) you want to be able to trace back to the user and correct it?

2. Passwords being sent in the clear?

3. Or the issue with idiots who can't type or read forms (or maybe a badly designed UI)?

Always remember that whenever you "add" to the system you are potentially adding complexity, and you are definitely adding code - both which increase the possibility you open security "holes" in your overall architecture somewhere (could be in the stack, could be via the web, could be over the net...). So in resolving any of the 3 you must measure whether the value of solving them is worth the risk of poking a hole you don't know about - the devil you know is always better than the devil you don't.

Now to each.

Resolving bad passwords should be done at the set up and change of the password via the validation rules. And only there. To add another place to do so, only means you risk getting validation rules confused or out of synch.

Passwords being sent in the clear. Who cares? Granted might "feel" unsafe, but remember this is n part authentication and if you only have 1 part it is no different than having a word in a dictionary. Maybe, just maybe if you have an active sniffer it may give them some clues, but then the intrusion already in place is your real problem, not some occasional, random, fat-fingering of passwords in the user name field. Now if you have all parts being sent in the clear, big problem.

Issue of idiots or bad UI design. Re-mediate users or UI. Simple. Provide active help on UI, have departments go through some training or something. Easy fix that requires limited, low risk coding changes (or should - be careful with the UI aspect though).

While I admire a lot of the suggestions on here, and many of them have wonderful ideas at their core. I recommend a KISS, no BS approach, always remembering that if you add to your systems you risk adding to your insecurity.

Just my 2 cents.

Answer 16

• only allow of transmitting md5 hashes of usernames AND passwords (or similar hash), so that whatever gets logged in the log files will always look like a fixed length of random characters, which will not make anyone be able to quickly guess that it is an md5 of a password or a username.

Con: To compare with usernames in your database you have to either store two columns e.g. 'username' and 'md5(username)' OR you have to dynamically hash every time you're querying username for login.

---

• create a log entry only if the username exists in the database, otherwise, log ip only.

---

• only allow the user to click enter using the mouse, not the keyboard, or only allow the keyboard after 5 seconds of last entered character in either fields, which will give the user time to look at the screen and see his mistake.

---

• do some restriction to allowed usernames and passwords:

  1. passwords must contain a special character like !@#$%^&*()
  2. usernames must NOT contain any special character

This way, you can do javascript to quickly identify whether the entered is username or password.

Answer 17

Biometrics are fairly inexpensive now and work at least 80% of the time. I find it great on TabletPCs and have been wanting to deploy biometric keyboards because it is faster ( at least for that 80% of the time).

I bet this was not nearly as much of a problem with Win2000, WinXP, Win2003, and WinVista because by default, the username field was already filled with the last successful username. Not exactly sure which version of ActiveDirectory or workstation changed, but the default now is for the username field to be blank which makes this problem more prevalent.

Answer 18

As a variation of Daniel Prydens answer:

One could have a minimum password length and a maximum username length. For example, passwords must be at least 16 characters long, usernames may be at most 15 characters wrong. Then, if a string of 16 characters or longer is typed into the username field, do not write it into the log file.