In terms of application layer authentication, it is common to track failed login attempts to existing user accounts. However, I have not seen anyone tracking failed login attempts of non-existing user accounts (meaning those that cannot be identified using public identifier, e.g. email).
-
1To better clarify and understand the problem, I would ask you at first: If so, which attributes would you track on non-existent account login attempt?– laikaAug 18, 2013 at 9:06
-
Well, I was thinking to include this as part of the question, though didn't want to make it too broad. My research shows that storing password in plain text wouldn't be wise for this case. However, I would still include username. I was also thinking about storing simple password hash, that would allow me to tell whether user is retrying the same silly password over and over again OR there are thousands of different login attempts.– GajusAug 18, 2013 at 9:12
-
Therefore, what would you do if you notice in your logs statistically significant pairs of unsuccessful attempts with 1) same username, various passwords and 2) same username, same password. This breakdown can go on, as you apply another metrics of identifying the source.– laikaAug 18, 2013 at 9:28
-
1Just to be clear, I am aiming to identify a malicious host activity, rather than user trying to desperately remember his forgotten username/password. If I see same user (based on IP) to attempt 100 different username, I will ban it (for a duration of time, such as 5 minutes). If I see same IP attempting 100 different passwords against same username, I will ban it, and vice-versa, if I see same password attempted against 100 different usernames, I will ban those IPs.– GajusAug 18, 2013 at 9:50
Add a comment
|
2 Answers
You are looking at different types of attacks. Logging failed attempts for known users is an attack against a specific user. By definition, a failed login attempt against a non-existent user will always fail since there is no password to match. This could show attempts to enumerate users or it may show attempts to profile an application.
From some of your follows ups above, it seems you want to log each entry but are concerned that the logs could lead to security concerns. For example, if a real users mistypes their id, and puts in the real password, this could lead to targeted attempts using variations of the username (attempting to use the incorrect username to reach the real username) with the typed password or variations.
I would recommend logging the IP and usernames to perform heuristics and to create blocking rules (stop brute forcing from an IP by blocking the IP for some period of time or requiring a CAPTCHA, etc.). Usernames combined with passwords may be helpful in identifying the methodology of the attacker (e.g., they think you are using application backend A which has default username X and default password Y). However, generally, you want to take action to block the attack and identify the source. There is greater risk in recording the passwords, even if hashed, than the value you might get from analyzing these passwords or hashes, since knowing the passwords isn't a good key to block future attacks, since any given password may be valid for another user.
One drawback to logging failed user attempts is that some users type their password into the username field and press submit. Sounds silly but it has happened enough times to be a concern.
This can happen with typing too quick, a password manager, or some other automated means.
answered Aug 19, 2013 at 6:28
-
1I agree. There are some other questions that relate to this as well. I am in favor of a two page logon to reduce this.– Eric GAug 19, 2013 at 18:05
-
@EricG by two page do you mean one page for username, a second for password? Is the username validated (I assume not)..? Aug 22, 2013 at 21:54
-
You only have one input box on the first page, no search, nothing else, just an <input /> for the username. You may wish to use cookies, etc. to remember this for the user. The user is trained to only enter either the username or password per page. Since they know they have to clear the username page first, they are less likely to type the password in the username box; therefore, this may help to reduce the risk of logging a password in a place where the username is expected.– Eric GAug 22, 2013 at 22:35
-
Here is the original answer where I discussed this in more detail: security.stackexchange.com/questions/32003/…– Eric GAug 22, 2013 at 22:37