We’ve all done it. You sit down bleary eyed at your terminal and tap in your username then instinctively hit tab and type in your password. You hit return before you realise that you didn’t hit tab correctly. The problem is now that you’ve typed your username and password into the field reserved for your username. Now if you’re using https (and really if you have a login page not on https then what are you doing!) then at least the traffic will encrypted but what happens when the failed login attempt is logged to warn the administrator about a potential brute force attack. The username and password will then be stored for posterity in this form. Again this shouldn’t be a problem because the logs are probably (and if this is not the case you really should question what you are doing in such a position of authority) only accessible via a secured login (at worst) and on the local network encrypted to an admin only(at best). But what happens when the sort of attack described here occurs *1, this is where a file edited or written to by an editor of some sort is accessible by the temporary files it leaves behind. Then we can look and see what usernames have been entered in this way.
My proposal is that as a matter of course we should not store usernames when the password field is blank and simply log the failed logon attempt. That way if we start to get lots of failed logins with blank passwords we can watch them but for the most part we can assume that if we see one or two that they are simply trying to login in the manner described above. This prevents potentially a users password being written down and easily accessible to a malicious entity. After all no one will be logging in without a password anyway right?!? (Say NO to blank passwords).
Of course what we could do is hash the username before logging and then keep a rainbow table of the users names – if the name doesn’t appear in the rainbow table then we can assume that this situation above has occurred. Again a malicious entity won’t be getting without a real username anyway. We just need to take care of timing attacks to reveal usernames – but for the most part its better to assume that an attacker already has them (most organisations use an easy to guess system for employee username – normally email address) so this isn’t a problem really.
As a user if you ever type your password into the username field you must instantly change the password – no questions – it is safer to assume that this scenario described has not been taken into account. It is also best to not give your system administrator your password too – which you would be in this circumstance.
If both users and administrators take responsibility in the way that they should (although anecdotal evidence suggests that sys admins will be more adept at this) then the risk of this type of attack is mitigated.
*1 – tl;dr A crashing instance of some text editors (like VIM) will leave behind a temporary file which can be accessed by a url (because it isn’t a protected type, like .php for instance).