On Marathi Wikipedia too we have got users complaining that there are notification of Failed Login attempts.

Users affected list can be found at https://mr.wikipedia.org/wiki/विकिपीडिया:मे_२०१८_सजगता_संदेश

Is there any matters to worry?.

Regards
Tiven2240
Admin MrWp

In T193769#4182030, @Tiven2240 wrote:

On Marathi Wikipedia too we have got users complaining that there are notification of Failed Login attempts.

Users affected list can be found at https://mr.wikipedia.org/wiki/विकिपीडिया:मे_२०१८_सजगता_संदेश

Is there any matters to worry?.

Regards
Tiven2240
Admin MrWp

See https://lists.wikimedia.org/pipermail/wikimedia-l/2018-May/090145.html . You may recommend that all users with advanced user rights at your wiki enable further security steps such as https://meta.wikimedia.org/wiki/Help:Two-factor_authentication .

Is there any matters to worry?.

You should generally not worry about the current situation. We are monitoring closely. As always please ensure you are using a strong password.

In T193769#4180966, @EtaoinWu wrote:

Since the crack started, the CAPTCHA error rate was high.
However, at about 5/3 18:30 UTC, the CAPTCHA error rate suddenly falls (from almost 100% to a normal rate).
Guess: the cracker find a way to bypass the CAPTCHA check (e.g. proxies, fake IP's).

We have a pretty good idea why that happened. Rest assured, the attacker did not find a way to bypass captchas.

In T193769#4180966, @EtaoinWu wrote:

Since the crack started, the CAPTCHA error rate was high.
However, at about 5/3 18:30 UTC, the CAPTCHA error rate suddenly falls (from almost 100% to a normal rate).
Guess: the cracker find a way to bypass the CAPTCHA check (e.g. proxies, fake IP's).

Or they gave up (temporarily)? Don't jump to conclusions so quickly :)

For the record: also report on fawiki (and apparently, the attack was not through fawiki itself, but through enwiki).

In T193769#4182826, @Huji wrote:

In T193769#4180966, @EtaoinWu wrote:

Since the crack started, the CAPTCHA error rate was high.
However, at about 5/3 18:30 UTC, the CAPTCHA error rate suddenly falls (from almost 100% to a normal rate).
Guess: the cracker find a way to bypass the CAPTCHA check (e.g. proxies, fake IP's).

Or they gave up (temporarily)? Don't jump to conclusions so quickly :)

No, it was something I specifically did at about 18:20 that would result in a change to the stats. (Nothing to see here, move along ;)

Cool cool!

In addition to technical security mitigation and investigation, I hope that WMF Legal is involved in this matter, perhaps on one or more restricted Phab task(s). Feel free to revert my tagging of WMF-Legal on this task if someone with relevant knowledge thinks that the tag is unnecessary.

Can I please be added to T193762 ? Thanks.

You carnt be added unless you have signed the nda.

In T193769#4187140, @MarcoAurelio wrote:

Can I please be added to T193762 ? Thanks.

Sorry, but for the duration of the incident we are limiting the bug to people in the security group, and won't be adding others unless they have a "need to know"

Hi everyone. While the attacker continues to try and login, we are currently blocking his/her login attempts. At this time, there is no need to panic or do anything. We of course encourage all users to always use a strong password.

2FA is currently available for "Edit filter manager" but not "Edit filter helper" (which can view the filters on enwiki). Would it be prudent to enable access to 2FA for that group? What about "Account Creator"?

Established users that are not in user groups that would let them use 2FA by default can request at https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions#Requests_for_other_global_permissions to be added to the global oathauth-tester group so they can enable the feature on their accounts; provided that they've read and understood https://meta.wikimedia.org/wiki/Help:Two-factor_authentication specially with regards to the recovery tokens (scratch codes).

Is there anything actionable in this task? If not, it can probably should be closed and the generic suggestions about login hardening moved to a generic tracking task.

@JBennett: No updates for ten months. What is left to do in this task? Should it be closed or have a lower priority nowadays? Same question for the subtask...