Page MenuHomePhabricator

Alert ops/security on many 2FA failures
Open, MediumPublic


Two-factor authentication codes are short and shown as the user types them in so failures should be rare. A dedicated attacker can brute-force them given enough time (the current throttling is 10 per minute, and there are 10^6 possibilities, 3 of which are acceptable, so for a single account there is about 1% chance of success for every 5 hours spent attacking; practically guaranteed success in a month or so). We should have aggressive security alerts (icinga etc) for frequent 2FA failures.

That would require either dedicated logging or improving AuthManagerLoginAuthenticateAudit (which currently only learns the outcome of the login attempt, not the step at which it failed - cf T137194: AuthManager cannot audit passwords) or adding a similar audit hook to OATHAuth.

See also T158379: Warn the user after a certain number of failed 2FA attempts about alerting the account owner.

Related incident:

Event Timeline

Also, we don't currently log abandoned logins (ie. a multistep form where a later step is never submitted and the session times out), but a successful password check followed by a 2FA screen that never gets submitted should ring alarm bells.

Is this alerts to a user of their failures, or more generally for WMF deployment? Or both?

I was thinking of icinga-type alerts. But adding 2FA alerts to LoginNotify (T140167) would be nice too.

Tgr renamed this task from Alert on many 2FA failures to Alert ops/security on many 2FA failures.Nov 18 2017, 9:47 PM
Tgr updated the task description. (Show Details)
Tgr updated the task description. (Show Details)

A brute force attack on a 2FA enabled account is kinda impossible since the code changes every 30 second and you have 10.077.696 possible combinations i personally think the web server is able to handle that many request in 30 seconds

This is a common misconception, periodically changing the code does actually very little against bruteforce attacks. (It is there to protect against replay attacks.) The attacker would just keep trying numbers at random; the expected amount of attempts needed is approximately same.

chasemp triaged this task as Medium priority.Dec 9 2019, 5:20 PM
chasemp added a project: Security-Team.

The easy option here is to just increment a counter in statsd for each 2FA success and another for each 2FA failure. We already do the same for login (c.f. so I'd think there's no issue with making this data public?