247

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.

Community
  • 1
Lex
  • 4,247
  • 4
  • 19
  • 27
  • Hash both username & password and send across. Of course account creation has to be on HTTPS. Further logins need not be. – जलजनक Mar 05 '13 at 17:29
  • 7
    @SparKotॐ - the problem is that if you hash the username, without a common salt, it is exceedingly difficult to identify the user. With a common salt for the username, it becomes possible to do a rainbow table attack against the logs to find any misentered passwords. – AJ Henderson Mar 05 '13 at 17:31
  • Rainbow table as an siem analyst with app logs and others counting too more then 5000+ eps sounds very inconvinent. There are siem solution like Q1 that would alert on a regex defined to check for username types. – Saladin Mar 05 '13 at 17:39
  • @Lex I'm confused what the risk of someone sniffing the password in this fashion from the wire? How much of threat it implies? If i have something as sslstrip it beats all the security on wire. – Saladin Mar 05 '13 at 18:10
  • 68
    Only log if the username exists in the db? – CodesInChaos Mar 05 '13 at 18:29
  • 1
    @asadz the threat seems pretty big to me, since the password might be transmitted in clear text from the username filed as if it were the username. The likelihood might be minimal, however the likelihood of internal fraud from someone abusing the log viewing privileges of the clear-text stored password that scares me the most. – Lex Mar 05 '13 at 18:38
  • 1
    @Lex but that would be another risk all-together being saved in clear text on machine, I was referring the risk of being sniffed off the wire. The attacker has to be very lucky in that case. Depending upon the response of the system (if it ask for one time token / password) or pre-auth in some sort of way then the chance of actual compromise is far less. – Saladin Mar 05 '13 at 18:41
  • @asadz I agree with you 100% – Lex Mar 05 '13 at 18:42
  • 1
    @CodesInChaos that's an interesting idea and I am sure it is possible to implement a regex filter for this. – Lex Mar 05 '13 at 18:42
  • 5
    Those of us who can type without looking at the keyboard can make that mistake too. Usually we also don't actually need to look at the screen and if one is slightly distracted such a mistake is easy to make. This is the advantage of the windows XP Home edition and later interface where it is a menu of users to pick from. Of course, not useful with more than a handful of users. – ewanm89 Mar 05 '13 at 18:58
  • 7
    This used to happen to me all the time, for the following reason: typically, when I unlock my computer, it remembers that I was the last user and only the password needs to be entered. I often `[ctrl]-[alt]-[del]` and enter my password before power is restored to my monitor. However, if my last login was via remote desktop, the username is cleared. Following my normal routine in this scenario results in the password being entered as the username. – Allan Mar 05 '13 at 20:47
  • 1
    Typing my password into something other than a password entry box is probably the leading cause of password changes for me. I should probably make that mistake more often! – Ben Jackson Mar 06 '13 at 02:12
  • I have two machines and one keyboard. Using MouseWithoutborders I sometimes type my password into whereever I THINK the cursor is focussed. Not always the box that needs the login – mplungjan Mar 06 '13 at 13:33
  • 8
    I suddenly feel the need to change various passwords... Also, when I have done this in the past, often times what happens is I'm typing really fast and accidentally miss the "tab" key to move to the next field. In other words... An account failed to login: MikeSP@$$W0RD – MikeS Mar 06 '13 at 15:49
  • 3
    I have noticed a really annoying bug where in a web page I will switch to the password field and start typing before the page finishes loading, then when the page does finish (partway through me typing my password) it will rip the focus away from the password field and back to the default (usually the username field). I wish everyone would make sure their product/web site does not do this. – Sam Woods Mar 06 '13 at 17:01
  • If possible, can you add a new field, like re enter password and add a clientside validation? – Sufyan Mar 06 '13 at 12:34
  • @Lex "...for some reason..." Just speculating on the reason: Is there javascript on the page that puts focus on the username box after the page loads? My banking website does this and I found myself typing my pw in the username field because of the asynch load. (e.g. I typed in my username and while typing--or right before typing--my pw, page would fully load, set focus to username and my pw would go in username field). – ray023 Mar 06 '13 at 19:29
  • @Sufyan - yeah, that would also be effective, but it would be a usability hit as it requires extra work on the user's part which is generally going to make it poorly received. Not saying it couldn't be the right choice in some situations, but it wouldn't be a popular one. – AJ Henderson Mar 06 '13 at 20:30
  • -> User P@$$w0rd does not **exit** is an obvious typo. – Alvin Wong Mar 07 '13 at 01:02
  • 1
    [Apologies if someone else already made this comment] This kind of stuff happens a lot more now that so many people use things like KeePass to auto-type their credentials. It's very easy to have the focus in the wrong field and then the auto-typed name, tab, password, enter sequence fills in the wrong fields. – jarmod Mar 07 '13 at 02:22
  • @ray023 Can't tell you that, I am afraid. However this also happens to people doing their mistakes on their windows logon too. – Lex Mar 07 '13 at 11:48
  • I recently had something similar when a user put the `Authorization Basic ` in the URL itself (query param) instead than in the HTTP header... sorry for him but his request went to the "NCSA-logs" file and we cannot simply prevent logging that as we don't parse the log message before logging it. – рüффп Dec 22 '16 at 22:04

18 Answers18

367

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.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • 22
    Simple, yet elegant. Wish I could give it a +5. – Iszi Mar 05 '13 at 18:27
  • Indeed. If we try and combine this with some basic level filter as suggested by @CodesInChaos. +1 – Lex Mar 05 '13 at 18:45
  • 2
    A bypassed javascript control would sent the username across the wire thats where the risk applies. It would be picked by something similar to wireshark and if its ssl it still would be e.g sslstrip http://www.thoughtcrime.org/software/sslstrip/ – Saladin Mar 05 '13 at 19:39
  • 9
    too bad we can't convince MS to implement this for the windows login dialog. – Dan Is Fiddling By Firelight Mar 05 '13 at 20:33
  • 27
    @asadz - yeah, it isn't a prevention against an attacker doing something, the question was just about what could be done to prevent passwords from ending up in log files by users making mistakes though. – AJ Henderson Mar 05 '13 at 21:18
  • 2
    Can this be guaranteed without JavaScript controls in modern browsers? Is there any type of form required element before HTML5 (http://john.foliot.ca/required-inputs/) – Eric G Mar 05 '13 at 21:19
  • @DanNeely But Windows login dialog can have a password of zero length. So this solution cannot be implemented there, can it be? – Anurag Kalia Mar 05 '13 at 23:01
  • 1
    @EricG: Given that the OP's *main* concern is with server logs rather than with network sniffing, the logic could be duplicated server-side before including the username in the log-message. – ruakh Mar 05 '13 at 23:34
  • @ruakh: That's a good point, but that isn't what the answer says, it says prevent form submission, not prevent logging, which is suggested in a couple of the other answers. – Eric G Mar 06 '13 at 00:32
  • @EricG: Yes, I agree. Much of the purpose of comments is to help improve answers, so I was suggesting something that I thought would help address your problem with this answer. – ruakh Mar 06 '13 at 00:34
  • @AnuragKalia so only enable it in the event of a password policy being in place. – Dan Is Fiddling By Firelight Mar 06 '13 at 01:05
  • @AJ Henderson popular contribution:). – Saladin Mar 06 '13 at 07:36
  • Agree - nice quick and easy win there for the client side. – fixulate Mar 06 '13 at 09:44
  • Does anyone have a concrete way to do this, or are we relying on JavaScript only? If so, should we expand this answer with some detail? – Eric G Mar 06 '13 at 23:55
  • @EricG - I have updated the answer to reflect that this could also be done server side. While Form is a key word to HTML post, it was never an intended implication of my answer. The idea is simply that you don't process a login attempt until the password field has a value. This could be on the server or client. – AJ Henderson Mar 07 '13 at 00:05
  • @Iszi You *can* give it a +5 by dropping a bounty. – Anko Mar 07 '13 at 00:46
  • @AJHenderson: I would assume your web server logs or network traffic logs may contain the password though. You could stop processing before any application level logs are formed. You would need filters on your web/network logging. – Eric G Mar 07 '13 at 01:28
  • 1
    @EricG - if you are logging every forum submission's Post data, that's going to be a lot of logging. I suppose you would still have to be careful with how you set things up, but I think that you could probably work around having it get logged as long as it doesn't actually try the authentication. Granted, it may not work in all systems. – AJ Henderson Mar 07 '13 at 04:04
  • Beautiful solution, thanks for this suggestion! All login dialogs should implement this. I'll start by implementing it in one of my applications. – basic6 Jul 12 '14 at 15:30
  • Nowadays, many login dialogs ask for the username on page one and for the password on page two. For such dialogs, this solution sadly doesn't work. – gerrit Jul 25 '22 at 15:37
39

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!

fixulate
  • 788
  • 4
  • 9
  • Indeed. that would solve half of my problems/concerns. +1. Thanks very much. – Lex Mar 05 '13 at 16:32
  • 1
    I guess ssl is a workaround not a code fix. Problems should be fixed at source at best. – Saladin Mar 05 '13 at 17:35
  • @asadz: the fact that the application shows the username when it is entered incorrectly is not an application bug, it is intended functionality and does not require a fix imo. – fixulate Mar 06 '13 at 09:34
  • @devcity2012 An intended functionality perhaps but poorly thought of; there is a part of requirements analysis in software engineering; this is where these things should be sough preferably using Sequence diagram;how come there is no check for a form before submission? Input validation void ? – Saladin Mar 06 '13 at 09:48
  • 1
    If the form takes a username and a password and both are present and then the backend is configured to display the username, that is not an application error if the user mistakingly enters his/her password in the username textfield. – fixulate Mar 06 '13 at 09:50
  • I'm talking it as a problem only in a sense where a request would be submitted just based upon user-name field? – Saladin Mar 06 '13 at 09:53
  • Yeah sure, then that can be stopped yes. :) – fixulate Mar 06 '13 at 10:00
22

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.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 4
    +1 it's a good idea to always assume that logs contain sensitive information unless explicitly redacted or until proven otherwise. – Daniel Pryden Mar 06 '13 at 06:27
22

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.
Nathan Goings
  • 858
  • 6
  • 14
  • 1
    I'm not sure what exactly you mean by "roll your own in javascript" but I'm pretty sure it's a bad idea. – Samuel Edwin Ward Mar 10 '13 at 18:23
  • -1 never roll your own https in javascript. If that's not what you meant please clarify. – makerofthings7 Aug 24 '13 at 14:24
  • @makerofthings7 I clarified. I never said roll https in javascript, I said OR javascript (clarified with encryption). Although not the easiest to implement *correctly*, there are resources for that kind of solution. It's a valid answer and I don't see why it's worth a negative point. – Nathan Goings Aug 28 '13 at 20:07
  • Javascript with crypto code delivered from the server (which is what you seem to describe) is rarely a good idea. The server can modify that JS code and expose the local private keys. Another vector is XSS/CSRF. It's a risky security design. HTTPS should be a minimum. Let me know if you're thinking of some other deployment, such as a HTML/SPA application wrapped in PhoneGap or something similar. – makerofthings7 Aug 28 '13 at 20:49
  • 1
    @makerofthings7, My thought process was not for man-in-the-middle. That is a can of worms. I was picturing eavesdropping. One of the systems I worked on encoded all form data with javascript (with a random key) so that coworkers couldn't snoop on each other. – Nathan Goings Aug 28 '13 at 21:25
14

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.

Eric G
  • 9,691
  • 4
  • 31
  • 58
  • serial authentication? perhaps – Saladin Mar 05 '13 at 19:50
  • 10
    Two step forms are actually the one place I am most likely to trip up and throw my password in the username field on the first page! – Caleb Mar 07 '13 at 11:01
  • I would be interested to know more about the UX case, do you have any reason you think this happens? Does the site login store your username on repeat visits or not? I would imagine that would help (but could hurt) since you wouldn't even have a box to type in if it prefills your username. Let me know some more details and I'll see if I can add some additional info to my response. – Eric G Mar 08 '13 at 03:58
  • 1
    This makes me much less frustrated that one of my banks does this, thanks for this answer (hah). – enderland Mar 09 '13 at 02:17
5

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.

Kevin Reid
  • 151
  • 3
  • +1 for posing the question to me as to whether we really need to know the username or not. I tend to think that we still need to username in the logs, but could be convinced otherwise should the arguments be strong enough. One of the reasons is to use correlation engine to put together time, frequency, source and destination IPs with the username. As I said, still don't have a very conclusive opinion about it, but thanks for the thought: it put me to think even more about it.@KevinReid – Lex Mar 07 '13 at 11:40
4

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.

Abhijit
  • 141
  • 2
  • Excellent suggestion. I think the majority of answers here so far put a good summary and it all makes a lot sense. +1 – Lex Mar 05 '13 at 19:30
4

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.

nalply
  • 141
  • 6
3

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

dr jimbob
  • 38,768
  • 8
  • 92
  • 161
3

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.

Daniel Pryden
  • 895
  • 1
  • 6
  • 12
  • 1
    How does this work? Does it check the `username` against the `password` stored in the database, if they match, force reset? Is this web based or also at the Windows/LDAP level? If so, is this a custom or off the shelf product? – Eric G Mar 06 '13 at 05:14
  • @EricG: It's a custom system, and I didn't build it, so I don't really know how it was implemented. That said, I believe it works by hashing the username and checking the hashes against the password hashes. My understanding is that they keep a database somewhere of "passwords found under suspicious circumstances" and expire any active passwords that match that list. – Daniel Pryden Mar 06 '13 at 06:23
  • I think you missed the part where he was asking how they know that the password was entered into the name field. – jcolebrand Mar 06 '13 at 16:48
  • 1
    @jcolebrand: Sorry, I thought I explained that: hash whatever gets entered into the username field and check the hash against the password database. Optionally use something like a Bloom filter if you have a really big password database and want to check quickly. I have no idea if this is what they actually do, though: maybe there's an even better way. – Daniel Pryden Mar 06 '13 at 22:05
  • 3
    That may actually be a valid thing to do. Then the problem is I can put in 1234567 or password1 etc and invalidate a whole lotta passwords. If I think I know my buddies password, etc. – jcolebrand Mar 06 '13 at 22:21
  • 2
    I'm with EricG. I don't understand how to actually implement this in a secure way. If the password database is storing password using a salt (and using a slow password hash like bcrypt), it's not easy to verify whether an incorrect username is actually someone's password, and if so, find whose it was -- the best you can do is exhaustive search over all users in the database, which is not scalable. If the password database doesn't use a salt (or doesn't use a slow password hash), you've got more serious problems -- that's a definite no-no. – D.W. Mar 07 '13 at 08:57
2

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.

Izac Mac
  • 121
  • 1
  • 2
    Using email addresses as user names is far from universal for public apps, and is rare in in-house apps. Color coding is unlikely to help: the usual reason for using the wrong field are inattention to which field is focused (especially when the username field is usually pre-filled but for some reason isn't in one instance). – Gilles 'SO- stop being evil' Mar 06 '13 at 15:52
0

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.

gerrit
  • 1,829
  • 1
  • 17
  • 26
0

Why not just respond with this?

That username does not exist
Alex Gordon
  • 101
  • 2
  • 9
    You probably shouldn't do this, or even take a different amount of time in the response. Responses like this and sometimes the difference in the amount of time it takes to process can be abused provide a list of valid usernames, which could even be used for reasons other than just attempting to gain access to the site/service itself (e.g. they could try to send an email to that same username in gmail, etc.). – Gary S. Weaver Mar 05 '13 at 20:17
  • @GaryS.Weaver: <- Yes. e.g., you create an A/B test in your brute forcer and whenever you get the different conditions you know you have identified a valid username. – Eric G Mar 05 '13 at 20:22
  • @GaryS.Weaver there's no fool proof solution, but dont u think that's a little overkill? he's not running americanexpress.com – Alex Gordon Mar 05 '13 at 20:31
  • @Артём-Царионов it's up to you, him, and everyone else to implement security as they see fit. – Gary S. Weaver Mar 05 '13 at 21:10
  • 1
    The problem in the question is that the username ends up in log files which makes a permanent record of the username in plain text. If the server was ever compromised or an admin wasn't honest, they could access the user's account without any record in the system. The log file still needs to know what usernames are being tried, so the solution would need to somehow prevent a password from being stored in a log if it is put in the username field. – AJ Henderson Mar 05 '13 at 21:25
  • @AJHenderson thank you! i didnt understand at first – Alex Gordon Mar 05 '13 at 21:40
0

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.

A. Wilson
  • 121
  • 6
0
  • 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.

sharp12345
  • 1,969
  • 3
  • 13
  • 23
0

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.

louis_coetzee
  • 101
  • true, however what about people logging into their Windows Domain from a laptop? We collect these logs too. – Lex Mar 07 '13 at 11:42
0

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.

Tek Tengu
  • 1,699
  • 11
  • 13
0

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.

rjt
  • 284
  • 1
  • 5