<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">Proper design - for as long as people have talked about proper design for username/password handling - is to *never* log a failed username anywhere, exactly because this kind of inversion is a very common failure mode.</div></div></blockquote></div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">What about handling password brute force attacks? If you don't log the username then how can you tell who has been attached?</div></div></div></blockquote>While it's good policy *at the client* not to distinguish between "incorrect user" and "incorrect password" (though the gain isn't huge), the *server* knows which of the two is the case, and *valid* usernames on the system appear in logs all the time. So if you see a failure with a valid username and an invalid password, you can go ahead and log it. That covers password brute force attacks.</div><div><br class=""></div><div>There are certainly some well-known "usernames" that may not actually correspond to a user on any particular system - e.g., "admin" - and you could safely log those as well. In fact, if you want to spot brute force attempts in general, something like "more than 10 failed attempts to log in to any username within 15 minutes, whether the username is known or not, are logged" is probably pretty safe: Users may put their password in the username field by accident, but they are very unlikely to do it 10 times in a row.</div><div><br class=""></div><div>I suppose you could also specifically recognize the case that password is a valid username and username is the password for that account and treat it specially. But just how much are you gaining for all this added complexity in one of the most security-critical components of the system? Keep it simple is good advice in genera....</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class="">You could keep a tally of failed login attempts on the user's account, but you couldn't tie that directly to a specific attack unless you also logged the time of each failure along with.</div></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div dir="auto" class="">I'd have thought the incident response benefits of logging the username outweighed the negatives. Especially as logging a password which was submitted as a username wouldn't reveal the username so wouldn't be that much use to someone who got hold of the logs. Unless the user logged in straight after and you logged that, then the two could be tied together.</div></div></div></blockquote>If I know it's the password of *some* user on the system, the next thing I as an attacker am going to do is try it against *all* the valid usernames on the system. That's a pretty easy brute force attack on many systems, and very few have enough users that I can't spread my attempts out over a couple of days making it very unlikely you're going to notice.</div><div><div> -- Jerry</div><div class=""><br class=""></div></div><br class=""></body></html>