log failed authentication attempts for audit trail?

[brainwane]

Should we log and display failed authentication attempts? Especially with the new API tokens, it would likely be useful to see failed attempts (and reasons why they failed) in the user security log.

But the concern with logging failed authentication attempts is that an attacker could use them to spam the event log, drowning out legitimately malicious events with junk (or causing security fatigue for the target user). We could mitigate that somewhat by being choosy with which failures we log, e.g., correct password but failed 2FA.

(condensed from conversation between @di and @woodruffw ; followup to #5863)

[woodruffw]

Thanks @brainwane!

To copy what I was about to put into a new issue (apologies for duplication):

---

The following events might be useful:

• Failed user sign-on
• Failed API token authentication (either completely wrong, or wrong scope)

Of concern: a malicious agent could spam a target user or project's event log by intentionally sending the wrong password or wrong API token repeatedly, causing the user to miss "legitimate" attempts to breach their account. This could be minimized by only logging failed partial authentication attempts, e.g. correct password with incorrect 2FA, or correct API token but incorrect scope. This would cause us to miss some events, but would also reduce the potential for spam-induced fatigue.

[cjerdonek]

To address the spam issue for "uninteresting" failed attempts, what about the idea of displaying just a count of failed attempts (e.g. over the last N days). That way people would still see some indication of failed attempts (as well as the degree).

[woodruffw]

To address the spam issue for "uninteresting" failed attempts, what about the idea of displaying just a count of failed attempts (e.g. over the last N days). That way people would still see some indication of failed attempts (as well as the degree).

This is a good solution for the client side, but we'd probably also need to do some deduplication on the server side to prevent an adversary from clogging up the DB.

OTOH, thinking about this a bit more, the existing rate-limiting framework should provide us with adequate cover for most failed authentication events. So maybe I was overthinking this and it isn't an issue at all 🙂