Closed Bug 1232585 Opened 9 years ago Closed 9 years ago

Don't delete recorded login failures on successful login

Categories

(Bugzilla :: Administration, task)

task
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jmcdonal, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151102093730 Steps to reproduce: When a user logs in successfully from an IP address, Bugzilla deletes all previous login failures for that user and IP address from the login_failures table (see clear_login_failures routine in Bugzilla/User.pm). Deleting this data hinders some auditing activities. Actual results: Successful login deletes all previous failed login records for the same IP address. Expected results: The data should be kept for a reasonable period, ideally configurable per site via data/params.json. (Six months might be a good default.)
If we do this, this would add extra complexity to track how many attempts you have left to log in before locking out your account. The goal of the login_failure table is to prevent brute force and abuse, not to log all historical attempts. If I typo'ed my password and it took me 2 or 3 attempts to log in (which happens from time to time), I honestly think you don't care. And if I managed to lock my account because I failed 5 times in a row, then 1) the admin already got an email about these attempts with all the data in it, and 2) the data is not deleted from the DB, so you can already audit them. If you need to keep everything for some reason, I suggest you write an extension to log all attempts. Reopen if you disagree, with an explanation about why you care about successful logins.
Severity: normal → enhancement
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
The use-case that prompted me to file this bug was that a user's manager emailed me claiming that the user's password had been changed without their consent. The audit_log only showed that the user had used the Forgot Password function, making me suspect that the user had simply forgotten their password. The apache logs are also consistent with that conclusion, but without the evidence of failed login attempts I can't entirely satisfy the manager that their team member's account was not hacked.
You need to log in before you can comment on or make changes to this bug.