Jump to content

Wikipedia:Arbitration/Requests/Motions

Edit links
Page semi-protected
From Wikipedia, the free encyclopedia
< Wikipedia:Arbitration‎ | Requests

This is an old revision of this page, as edited by L235 (talk | contribs) at 20:42, 6 November 2022 (→‎Temporary checkuser privileges for scrutineers (November 2022): enact). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Arbitration Committee proceedings

Currently, there are no requests for arbitration.

[edit]
Open cases

Currently, no arbitration cases are open.

[edit]
Recently closed cases (Past cases)
Case name Closed
Venezuelan politics 25 May 2024
Request name Motions  Case Posted
Amendment request: Article titles and capitalisation none (orig. case) 7 June 2024
Clarification request: mentioning the name of off-wiki threads none none 4 June 2024
Amendment request: India-Pakistan none (orig. case) 7 June 2024
Clarification request: Contentious topics restrictions none none 10 June 2024
Motion name Date posted
Return of permissions 1 October 2022
Temporary checkuser privileges for scrutineers (November 2022) 6 November 2022

Motions

Return of permissions

Return of permissions

The Return of permissions procedure is amended to read as follows:

Removal is protective, intended to prevent harm to the encyclopedia while investigations take place, and the advanced permissions will normally be reinstated if a satisfactory explanation is provided or and the issues are satisfactorily resolved. If the editor in question requests it, or If the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances.

In cases where an administrator account was compromised, the committee will review all available information to determine whether the administrator followed "appropriate personal security practices" and whether the account has been appropriately secured before restoring permissions. Factors used to make this determination include: whether the administrator used a strong password on both their Wikipedia account and associated email account (such as by using a password manager); whether the administrator had reused passwords across Wikipedia or the associated email account and other systems; and how the account was compromised; and whether two factor authentication is being used. If the Committee determines the administrator failed to secure their account adequately or is failing to take reasonable measures to secure their account going forward, the administrator will not be resysopped automatically. In particular, the Arbitration Committee generally will not resysop administrators who failed to use adequate password security practices, such as by reusing their Wikipedia or associated email account passwords on other websites.

Unless otherwise provided by the committee, the administrator may regain their administrative permissions through a successful request for adminship.

Furthermore, the Level II procedure is amended to add:

6. If the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances, provided that the editor in question requests it; failing that, the removal is final. As with a Level I desysop, an administrator desysopped in this manner may still run for adminship again.

For this motion there are 11 active arbitrators. With 0 arbitrators abstaining, 6 support or oppose votes are a majority.

Arbitrator voting

Support
  1. As proposer, with thanks to Barkeep, Salvio, and Kevin for wording. See my comment below for a full explanation of the changes, which serves as my reasoning as well. CaptainEek Edits Ho Cap'n!⚓ 18:59, 1 October 2022 (UTC)[reply]
Oppose
  1. I cannot support this change simply because of this line "In particular, the Arbitration Committee generally will not resysop administrators who failed to use adequate password security practices, such as by reusing their Wikipedia or associated email account passwords on other websites." I have seen a lot of account compromised over the years, leading to emergency desysops - and by and large, I have felt that the administrator in question has simply not realised the security mistakes they have made. I am all for education and improving our administrator account security, but I am not for setting out a guideline stating that we will "generally" be punishing individuals who make mistakes. I would much rather review on a case by case basis. If the individual cannot recognise and will not learn from the mistake, then sure, but if they accept their mistake and update their security, I have no issue with "generally" returning the tools.
    On a wider note, we have hundreds of administrators, all with different levels of technical online ability, each of which has dedicated a large portion of their lives to the encyclopedia. I will not be part of a culture who black balls these hard workers simply for not understanding what they're doing wrong. WormTT(talk) 08:46, 3 October 2022 (UTC)[reply]
  2. The current language already gives leeway to deal with extraordinary cases where an admin is especially sloppy or repeatedly hacked. BEANS is really a factor here, but I'll also add that we don't need any more incentives for admins to be targeted by bad actors (i.e., if you pull it off, maybe you can get them desysopped too!). --BDD (talk) 14:21, 3 October 2022 (UTC)[reply]
  3. I'm generally in agreement with Worm That Turned. I don't think less-than-ideal security practices ought to be a bright-line offense; there's too much nuance involved, and a rule that we would generally not resysop is draconian. Maxim(talk) 13:28, 4 October 2022 (UTC)[reply]
Abstain
Comments

Three big changes: first, I've implemented Salvio's suggestion with some elaboration, and have moved that clause to the Level II procedure instead. The sentence seemed to imply that we open a case to review a compromised account. But we don't, that is just way too much bureaucracy. The discussions have to be private anyway, so the structure of a case isn't necessary. Current practice is that we talk to the compromised admin via email, get their story, do our fact finding, then vote on a private motion. That's how we do basically all private stuff, so no need to specify the modus operandi there. Second, I have clarified that we will still open cases for Level II desysops by simply adding that as point 6. I have used the wording "final", rather than Salvio's "permanent", since one may still RfA again. Third, I have added a clause noting that the Committee will generally not resysop for password security failures. To me, that is key. This in my mind is basically our final warning to admins to get their passwords in order. We raised the issue years ago, and things still haven't been solved. But in the interest of fairness, I think we need to put the admins on notice before we just start pulling hacked permissions. I am also open to sending some sort of mass message to communicate this change. As much as I wish there was a technical solution, the WMF is not known for its speed in implementing technical fixes. Thus we need a social solution. CaptainEek Edits Ho Cap'n!⚓ 18:32, 1 October 2022 (UTC)[reply]

  • I don't have any strong feelings about this topic. If the arbs whose concerns were the impetus to start this discussion like this I stand prepared to support it. if this isn't it, I am prepared to support something else. Barkeep49 (talk) 22:17, 1 October 2022 (UTC)[reply]
    I can support the general direction that we're going. I would like to make it much more explicit that the major issue we are seeing is password reuse and that we will treat that differently going forward – either through ArbCom action or by community action saying we need to take it more seriously (my preferred route). I do not think the removal of the safety valve of a full case is wise; it's not causing any problems and if a desysopped user really does think they want a full case I would support holding one. I do not think we need to add 2FA to this list. I do not think we need to add "or is failing to take reasonable measures to secure their account going forward" to the procedure; that's not what's broken. Best, KevinL (aka L235 · t · c) 20:57, 2 October 2022 (UTC)[reply]
    That's not what was broken here though 2FA would have stopped the last compromise we had. I don't feel strongly on this but I think a reasonable assurance that measures are being taken to secure the account going forward is entirely compatiable with Admin policy of Wikipedia's policy on password strength requirements requires administrators to have strong passwords and follow appropriate personal security practices (emphasis added). Barkeep49 (talk) 21:00, 2 October 2022 (UTC)[reply]
    Sure. I just think that's implied. Best, KevinL (aka L235 · t · c) 21:03, 2 October 2022 (UTC)[reply]

Return of permissions (alternate draft; not yet open to voting)

The Arbitration Committee's procedure titled "Return of permissions" is amended by appending the second paragraph with the following sentence: In particular, the Arbitration Committee generally will not resysop administrators who reused their Wikipedia or associated email account passwords on other websites.

Arbitrator discussion

  • This is my attempt to capture some behind the scenes discussion about this procedure. I'm not precious about any of it so if I've missed the mark in some way from arbs who'd like to see it changed, I hope they will refine the motion or offer their own. I will note that the motion I've proposed does include 2-factor authentication, but it is one criteria among many for whether or not to restore, which is a substantial difference from the previous committee communication that was later walked back. In other words no admin is being forced to use it, but if they choose to use it that decision will factor (positively) in the decision about returning tools. Barkeep49 (talk) 17:28, 26 September 2022 (UTC)[reply]
  • I'll add some detail here. A good portion of the Committee, me included, is unthrilled that administrator accounts keep getting breached because of lax password practices. The Committee has historically erred on the side of returning administrator tools to compromised accounts once administrators are confirmed to be in control of their account. But at least for me, going forward I intend to oppose restoration of permissions (absent compelling community input) on the basis that admins have had ample warning about password practices. Whatever we pass here, I want to make sure we're loud and clear about our changing approach, so that admins have one last chance to make sure they have a strong password, that they're not reusing, and that otherwise conforms to best password security practices. I'm particularly interested in what the community thinks here, especially as to what extent we should weigh password security practices, and in what general situations the community believes we should not return the administrator toolkit, thus forcing the editor to run for adminship again if they want the tools back. Please remember WP:BEANS in your answers, since we're not trying to create an instructional guide for our trolls. CaptainEek Edits Ho Cap'n!⚓ 18:05, 26 September 2022 (UTC)[reply]
    I don't want this discussion to be about 2FA, but understand that it probably will. The Committee has not forgotten the opposition to 2FA expressed in 2019, and is not requiring 2FA, nor do I want to. Even without using 2FA, your account can be uncrackable. However, if you don't use 2FA, you better be conforming to best password security practices. That, in my view, is the bare minimum. The admin tools are more powerful in the wrong hands than people give them credit for (WP:BEANS). CaptainEek Edits Ho Cap'n!⚓ 18:14, 26 September 2022 (UTC)[reply]
    I don't think this motion is "loud and clear" about the change you're outlining Eek. I would suggest if that's the goal - and I suspect you're not the only arb to feel this way - that we would need another motion - perhaps as a complement, perhaps as an alternative - that would communicate the Committee's new view on this topic. Barkeep49 (talk) 20:26, 26 September 2022 (UTC)[reply]
  • As a note, the present wording of WP:RETURN is as a result of a 2019 motion that came after some 6 administrator accounts were compromised (see footnote therein). While any one compromise from an administrator might be a single for that administrator, that administrators continue not to secure their accounts is basically a failure to uphold WP:SECUREADMIN. --Izno (talk) 18:41, 26 September 2022 (UTC)[reply]
    @Legoktm, the current policy is 10 characters for certain permissions holders. Which, to be honest, is also an abysmal minimum. (I am also not particularly certain how that is enforced? When the administrator right is added, how does MediaWiki check? :)
    I am not sure how an audit would be run except at the login step, seeing as the storage of passwords is industry standard (salt + hash). This only (to me) feasibly catches the short passwords and the most common passwords. We might get lucky catching others on the pwned lists, but since we require a user name and not an email to login, I foresee this as being minimal. Still, better something than nothing?
    The RFC TNT mentions is WP:Security review RfC, from 2015. There is an earlier one from 2011, Wikipedia:Village pump (proposals)/Account security. Gosh, do the beginnings of those RFCs look familiar. That makes 4 times this has come up, including 2019 (when Arbcom last modified WP:RETURN) and 2022 (now). While I agree that it would be draconian for Arbcom to desysop someone for the first time, our continuing issues with it indicate to me that might be necessary. It's been over a decade, folks. Izno (talk) 04:51, 27 September 2022 (UTC)[reply]
  • Just throwing some spaghetti at the wall: what if there were a rule saying "if an admin gets compromised and there's public evidence of password reuse, they have to re-RfA"? Enterprisey (talk!) 01:27, 27 September 2022 (UTC)[reply]
    That is what the alternative motion that we voted on said. Desysop, and the community can decide whether Staxringold deserves to retain the permissions. Izno (talk) 04:53, 27 September 2022 (UTC)[reply]
  • The case in hand was covered by the existing wording. There's little point changing the wording unless the committee is willing to enforce its own stated position which has been in place for years. I'm still thinking on the change but the wording "appropriate personal security practices" says what needs to be said in an enduring way. Specifying what those practices are sets a fairly short "best before" date to the advice. Cabayi (talk) 08:18, 27 September 2022 (UTC)[reply]
Follow up to TNT's pointer to HIBP. The site has a NotifyMe option so you'll be informed if it's found that your email is caught in a data breach in the future. Cabayi (talk) 08:25, 27 September 2022 (UTC)[reply]
  • I do think we need to leave 2FA out of this. While I use 2FA on my email accounts associated with WP, I will not ask anybody to use the 2FA method currently implemented by WMF, and do not use it on WP, except where explicitly required by WMF. Consistent with my position in the recent restoration discussion, I support the strictist enforcement of conditions for restoration of admin status after an account compromise that the committee will endorse. - Donald Albury 22:30, 2 October 2022 (UTC)[reply]
  • I am not aware of any changes to the 2FA system, meaning that it is not robust with regards to lost tokens. In those cases, manual intervention by T&S (I think?) and they were not in a position for all admins to flip that bit. Given that not all admins trust WMF either, I believe pushing for 2FA is a non-starter. Regarding strengthening of passwords, that's something I support and have supported for a long time. Yes, password re-use is the biggest problem, but our password requirements are pitiful and should be updated as a technical change. WormTT(talk) 08:31, 3 October 2022 (UTC)[reply]
  • Further background, with Worm and my fingerprints all over it, is at Wikipedia:Security review RfC and Wikipedia:Password strength requirements (which was superseded by meta:Password policy). Beeblebrox (talk) 21:48, 3 November 2022 (UTC)[reply]

Community discussion

Tracked in Phabricator
Task T265726
  • In an ideal world, 2FA would be a requirement for all administrators. I appreciate that many do not agree, and given the current implementation of two-factor authentication perhaps this is for the best. I would however urge ArbCom to make enabling 2FA a requirement for returning sysop permissions to a previously compromised account — I think this would be a fair middle ground. — TheresNoTime (talk • they/them) 18:05, 26 September 2022 (UTC)[reply]
    Agreed. We cannot audit passwords or password manager use - we can check that 2FA is on. For restoring tools to a previously compromised account we absolutely should be doing this. firefly ( t · c ) 18:09, 26 September 2022 (UTC)[reply]
    @Firefly: - I thought that it could only be known if they had a 2FA userright. Actual knowing if 2FA was being utilised/enabled was limited to Steward sight and not able to be shared? Nosebagbear (talk) 18:21, 26 September 2022 (UTC)[reply]
    @Nosebagbear ahhh yes that is I believe true. Whether we want to go there (asking stews to check) is another matter I suppose. firefly ( t · c ) 18:24, 26 September 2022 (UTC)[reply]
    @Firefly - they'd probably have to get a position from WMF Legal to adjudge whether they could hand it over. It would certainly count as private information (although not especially sensitive private data). There might be more to be said for having CUOS rights tied to it, with that information taken and handled purely privately. Nosebagbear (talk) 19:41, 27 September 2022 (UTC)[reply]
    @Firefly: iirc password strength can be audited — T121186 ("Implement results of enwiki Security review RfC") was meant to regularly audit administrator passwords. — TheresNoTime (talk • they/them) 18:56, 26 September 2022 (UTC)[reply]
    phab:T265726 would be required to allow crats to audit if 2FA is on or not, currently only stewards and WMF may do so. — xaosflux Talk 18:58, 26 September 2022 (UTC)[reply]
    @TheresNoTime Ah my apologies I’d forgotten about that task. It seems however that password audits for admins has yet to be implemented(?). firefly ( t · c ) 20:02, 26 September 2022 (UTC)[reply]
    @Izno: agreed — compromises do happen, and given enough time and technical ability no account is entirely secure, but the unfortunate reality is that, for the majority of compromises, WP:SECUREADMIN is not being followed. It seems to be somewhat of an unenforced policy at this point — TheresNoTime (talk • they/them) 18:51, 26 September 2022 (UTC)[reply]
  • While I am confident that I meet the password criteria for admins, I am very reticent in Eek's position. I don't believe that a single failure there is adjudged by community standards to be a failing on an equivalent standard to the other single-failures that would get the admin userright removed even where the admin apologised and acted to correct the issue going forwards. With regards to Tamzin's TNT's proposal, it's not unreasonable, but I would want it generally limited to cases where it is known that either the admin had not been meeting the minimum criteria, or had met them, and was compromised in a way that 2FA would have stopped (certain limited categories of keyloggers, password dumps etc) Nosebagbear (talk) 18:21, 26 September 2022 (UTC)[reply]
    The most common compromise vector we've seen would indeed be stopped by 2FA (though in the most recent case, perhaps not) — it's certainly not the "be all and end all" of account security, and has its own fairly significant drawbacks. It is, however, another layer to the account security best practices. — TheresNoTime (talk • they/them) 18:33, 26 September 2022 (UTC)[reply]
  • The motion seems fine as written. Eek, I'll agree to bite my tongue about 2FA (especially this implementation), but it's going to be difficult to hold steady if others are still lobbying for it. --Floquenbeam (talk) 18:24, 26 September 2022 (UTC)[reply]
  • I agree the motion as written is good. Regarding 2FA, I use it* but I am opposed to requiring it until there are no technical, legal or economic barriers to every admin being able to use it. In the last discussion I was part of extant technical and economic barriers were noted that prevented some admins in wealthy countries in the global north from using 2FA, let alone those from less online parts of the world. I don't recall what the state of play is regarding legality. *Although I have had to temporarily disable it twice in the last few years, first for about 10 days when my second device was away being repaired and then for about a day when I replaced that device earlier this year. Thryduulf (talk) 01:11, 27 September 2022 (UTC)[reply]
  • Having your account be compromised is embarrassing enough (I speak from personal experience on this), I don't see value in doubling down and then punishing the person for their bad luck. Rather, if we're going to enforce password policies (e.g. must be 8 characters or longer), then we should enforce them equally. It would be relatively straightforward to have MediaWiki desysop any admin who logs in with a less-than-eight-character password, if that's what we want. Legoktm (talk) 01:24, 27 September 2022 (UTC)[reply]
  • I do hope that if an admin account was compromised multiple times that they would lose adminship for good. --Rschen7754 01:25, 27 September 2022 (UTC)[reply]
    • I also hope that a higher standard would be applied to users with rights beyond admin, especially those that can access private data. --Rschen7754 02:55, 27 September 2022 (UTC)[reply]
  • In an ideal world (such as the one TNT refers to), the WMF would fully support 2FA software properly, and the software would be up to international standards. Asking an admin to say they have 2FA enabled is security theatre of the worst kind: absent being confirmed by a steward that it is, in fact, turned on, nobody on this project would be able to verify. (Stewards for whom this is the home wiki aren't supposed to carry out tasks related to this wiki.) And even if they verified at that time, it's just a step or two to turn it off. I'd much rather ask for a longer mandatory password that is enforced on all admin accounts, and regularly verified, with mandatory desysop if the account fails the verification, as Legoktm suggests. It's entirely reasonable to ask that an annual verification that admin accounts meet minimal password standards be carried out. But let's not go down the security theatre rabbit hole. Risker (talk) 02:57, 27 September 2022 (UTC)[reply]
  • My point is poorly made without spilling some beans, so here goes — the vast majority of account compromises we see are the result of password reuse. This occurs when you use the same email and password here as you do at some other poorly secured website which then goes and gets hacked. Often, these credentials are leaked/sold/otherwise made available and attackers will just try the lot of them — sometimes they're lucky and get an admin account. 2FA in this case would prevent them from logging in. Something I suggested in the above task was routine auditing of passwords against known leaked credentials (something which https://haveibeenpwned.com offers), which would let us combat some of these common compromise vectors without using 2FA. I don't want to derail this discussion, but this feels like the enwiki security review RfC all over again — deciding to not take reasonable precautions to protect your account is not a valid excuse, yet it's quite clear we've made it one as our policy is unenforceable — TheresNoTime (talk • they/them) 03:27, 27 September 2022 (UTC)[reply]
  • Hard cases make bad law; I would not see a compelling reason to have a blanket policy that you might not find makes sense later. That said, anyone getting compromised twice probably needs to go back to RFA. Stifle (talk) 08:27, 27 September 2022 (UTC)[reply]
  • We'd achieve a lot more security by implementing technical best practices (many suggested above) rather than trying to regulate human behavior: long minimum lengths, checking against password breaches, throttling failed login attempts, disallowing reused passwords and common words/patterns, etc., and of course that includes 2FA. For example, see the NIST standards (summary); there are others, too. We don't need to create rules and then monitor humans for compliance with those rules, we can make compliance a technical requirement: as in, if your password isn't good enough, you can't log in at all. That'll save volunteers a lot of compliance/enforcement work. Whatever our password policies are, I support arbcom in sanctioning admins who repeatedly fail to comply, e.g. by desysop. Levivich (talk) 15:01, 27 September 2022 (UTC)[reply]
  • Without spilling the beans (and tell me if there's no plausible way to answer this question without spilling) - what's the worst case scenario for an admin account compromised by a competent attacker who is hostile or indifferent to Wikipedia's integrity? Feel free to answer vaguely or qualitatively so as to not advertise a method. Tazerdadog (talk) 18:31, 27 September 2022 (UTC)[reply]

    [...] there are plenty of things that +sysop allows that are irreparable, either in a PR sense, or unrepairable without a truly stupefying amount of work, or in a few cases literally so. Most of them we don't talk about. One of the most obvious, and one that we can talk about because it's already happened (before we had cascading protection, so it didn't require being an admin at the time), is to put a shock image on the main page disguised in such a way that it takes a long time to remove. [...]
    — Cryptic 16:20, 14 September 2022 (UTC), Wikipedia talk:Requests for adminship#Accusing someone of being a sock in an RfA?

    I think I know some of the details involved, but don't feel like it would be a good idea to share more. See also mw:User:MZMcBride/Attacks#Privileged account, although that was written years ago so is somewhat outdated. * Pppery * it has begun... 18:35, 27 September 2022 (UTC)[reply]
    @Tazerdadog: I don't really think there is a way of answering that without potentially saying too much — I suppose if you consider what a rogue admin could carefully do without drawing attention to themselves, that's going to put you on the right track. The bottom line is a fair bit of damage to content, reputation, and the community. — TheresNoTime (talk • they/them) 18:38, 27 September 2022 (UTC)[reply]
    @Tazerdadog worst case is probably along the lines of an identify takeover - compromising an admin account of a really-not-here admin, becoming "active" again - and then doing things that drive away readers or editors. The actual account owner might not even know this has occurred. There are certainly some annoying-to-fix technical BEANSy things, but I'm not going to go in to those - they can be fixed and are mostly a time-sink for other admins. — xaosflux Talk 18:40, 27 September 2022 (UTC)[reply]
    (edit conflict) We know from experience that most admin compromisers either use the tools to cause easily-undoable chaos or don't use them at all, so "what's the worst thing a compromised or rouge admin can do" may not be the right thing to think about. * Pppery * it has begun... 18:40, 27 September 2022 (UTC)[reply]
    Imo, the worst case scenario is very bad. We've honestly been quite lucky so far. But luck is no basis for security. CaptainEek Edits Ho Cap'n!⚓ 19:26, 27 September 2022 (UTC)[reply]
  • There is no excuse in 2022 for an administrator having a weak password and not using 2FA and other basic security tools. I would consider a person who does not use proper modern security on an account granted advanced permissions (with access to all kinds of potentially damaging info) to be unworthy of the community's trust. EnPassant♟♙ (talk) 20:00, 28 September 2022 (UTC)[reply]
  • It's not exactly what you are asking, but I would like to ask you to consider amending this clause: If the editor in question requests it, or if the Committee determines that a routine reinstatement of permissions is not appropriate, normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances. This is not what happens in most cases, especially when people are desysopped under level II procedures. It's a case where for a long time the letter of the law has not kept up with current practices. If I had to make a proposal, I'd put forth this one: If the editor in question requests it, or If the Committee determines that a routine reinstatement of permissions is not appropriate normal arbitration proceedings shall be opened to examine the removal of permissions and any surrounding circumstances, provided that the editor in question requests it; failing that, the removal is permanent. Salvio 20:33, 28 September 2022 (UTC)[reply]
  • I like the idea of having the system require various features of strong passwords, a minimum number of characters, mixed case and or special characters. It doesn't directly address the reuse issue, except that someone who has been reusing passwords might now need a stronger one for Wikipedia. If we can set rules that require specific accounts to have 2FA, then I'm OK with doing so as a condition for return of userrights. If your account gets compromised then you have to deploy 2FA to get back the same level of trust. Most of our admins are not active as admins, it would be sensible to add a rule inactive and semi active admins whose accounts are compromised can request return of tools three months after regaining control of their account and returning to a fairly active status (100 edits per month). This removes the need to discuss reinstating tools for compromised semi active accounts until and unless they return to an active status. ϢereSpielChequers 04:28, 3 October 2022 (UTC)[reply]
    I like this idea, but instead of listing the requirements here I'd reference the standard provisions for admin activity so that they are always in sync. Thryduulf (talk) 10:29, 3 October 2022 (UTC)[reply]
  • On one hand, I think admins should be expected to keep their account secure (including using 2FA as mandatory, or at the very least being permanently desysopped if they don't use 2FA and their account gets compromised), and using strong passwords. On the other, even the most conscientious admin could be hit by a zero day attack and compromised, and of course we shouldn't hold that against them. So, require admins to take reasonable measures for account security, but do realize those will never be perfect. Seraphimblade Talk to me 03:35, 13 October 2022 (UTC)[reply]
    While 2FA is fine in concept (and I use it on my important email accounts), I will not support requiring the use of the current implementation of 2FA on English Wikipedia. I do have 2FA enabled where required on Wikimedia accounts, but the first such account I had was bricked within a month. If the current implementation of 2FA is ever required for English Wikipedia admin accounts, I will resign my adminship rather than risk losing access to my 17-year-old account. - Donald Albury 13:16, 17 October 2022 (UTC)[reply]
    I agree the current implementation is lacking — I'd quite like to understand (not just from you, but 'across the board') what the primary concerns are, so that we can get them addressed. — TheresNoTime (talk • they/them) 13:29, 17 October 2022 (UTC)[reply]
    @TheresNoTime from the back of my head - my biggest concern was around the fallback issue. If a user loses access to their token (and scratch codes) they cannot get access to their account without going through T&S and T&S are not set up for a significant volume of these. WormTT(talk) 13:45, 17 October 2022 (UTC)[reply]
    I agree with that, though I would also say that this is the same for a lot of 2FA implementations (i.e., if you forget your scratch codes for your Google account, you're going to have to go through Google support to recover your account — admittedly, Google support is pretty well set up to handle an influx of such requests, but there's a fairly good chance they can't prove your ownership of the account..) — TheresNoTime (talk • they/them) 13:50, 17 October 2022 (UTC)[reply]
    My experience was that my password and/or transmitted code didn't work, nor did the codes from the scratch pad. I have no idea what went wrong, although I suspect I made a mistake somewhere along the way. There was no problem establishing my identity through other channels, but I was issued a new account rather than restoring my access to the original account. Losing access to that original account was not a big issue, but losing access to my primary user/en-admin account on Wikipedia would be. In my experience, I have never had an account hacked, but I have lost one to 2FA, whatever the cause. A very poor sample, but all I have. I do use a unique, complexly constructed password for my WP account, and do change it ocassionally. I also have 2FA implemented on the email account linked from my WP account. Donald Albury 14:31, 17 October 2022 (UTC)[reply]
  • I already said this back in March but I suppose I'll say it again. We can probably assume that those who seek to hack another editor's account are those who're already within the wiki community ("Would anyone else try to track down random stranger's login and password on some random forum?" Probably not). As much as we put in stringent password requirements or making 2FA mandatory, there is no accountability or punishment for any editors to attempt hacking another's account. To repeat my analogy, the current community and ArbCom approach is to punish those who have weak doors (passwords), not the thief that's studying the kind of lock on the door (trawling through haveibeenpwned and other leaked password sites) and picking the locks for these doors. It should be standard practice to run a CU the moment an account is compromised and check if there's any associated accounts. If there is, sure the compromised account is at fault and needs to be desysoped at level 1, but the hacking person revealed through CU should also be banned. Until we see some accountability and actions that punish the hacker, the hacking will continue because there's no consequence for the hacker to stop. OhanaUnitedTalk page 03:48, 17 October 2022 (UTC)[reply]
    @OhanaUnited: it is standard practice to, as you wisely suggest, attempt to determine who compromised an account. Best, KevinL (aka L235 · t · c) 04:27, 17 October 2022 (UTC)[reply]
    Good to hear that it's now standard practice. Cause it didn't seem like it back in 2015 when my account was compromised (or at least the findings weren't communicated to me, even if it's "sorry we don't have any result") OhanaUnitedTalk page 14:00, 17 October 2022 (UTC)[reply]
  • Require 2FA for administrator and above accounts. A prerequisite is that WMF needs to provide technical support to resolve the inevitable lockouts. Having to chase down a developer to recover from a lost authenticator device is far from ideal. Jehochman Talk 19:51, 17 October 2022 (UTC)[reply]
    Even though it wouldn't strictly be necessary, any requirement of 2fa for Admin accounts should probably go through a well-publicized RFC, to address community concerns.Jackattack1597 (talk) 21:17, 18 October 2022 (UTC)[reply]
    That might be a way to show WMF the importance of supporting users who lose their authenticator device (loss, theft, electronic failure). Jehochman Talk 01:40, 19 October 2022 (UTC)[reply]
  • NIST guidelines quoted above by Levivich are, if you look closely, Active Directory specific. More thorough discussion of current best practices is here. While back-end checking the hashed passwords against dictionaries of known compromised and easy to crack passwords is popular and appropriately cinematic, in my experience the best countermeasure against password hacking (once the hashed passwords are secure against observation) is failed login notification and limited login attempts--10 before being locked out per the above link, for example. Secure login methods reduce availability, as comments above have noted, and hard limits on failed logins create an opportunity to disable known accounts, so some automatic unblocking is a necessary relief valve. One novel method recently implemented in one of my university accounts is an image-based "something ELSE you know" that picks one of three user-selected images and shuffles it in amongst ~40 others, requiring no other hardware or communication channel. I cannot emphasize enough how simple a 2FA solution really needs to be in order to be effective. Microsoft and Apple pushing 2FA everywhere clearly provide a help-desk full employment program for organizations following their recommendations. Jclemens (talk) 06:14, 19 October 2022 (UTC)[reply]
    Limited login attempts can cause a denial of service for the account who a bad actor attempted to compromise, which you note. My understanding is that WMF has declined to implement that option accordingly. I suppose it would be possible to implement on some sort of IP basis, but that's easy enough to get around for the motivated bad actor.
    As for images, that is essentially a CAPTCHA, which is already known to be an issue, so I'm not sure it's meaningful to chase that. Izno (talk) 21:36, 2 November 2022 (UTC)[reply]
    It's not really a captcha, because only the editor knows which image is the one they selected. I've used a similar system before, and you get a panel of six images and you select from that panel the image you've already chosen. You then have to identify the image with the label you've provided for it.
    You log in as normal, with your name and password and if successful you see a panel of images, one of which you've chosen and labeled as your 2fa. The panel contains a train, a duck, a walrus, a table, a hat, and a telephone. You select the duck, which is the image you've chosen prior, and enter the label you've signed to it, e.g. Donald. Then you're successfully logged in.
    An attacker would then need your password, knowledge of which image you've selected, and the label you've applied to the image. Locking out an account with multiple failed logins at the image selection avoids the problem of using failed logins as a dos attack, since if they've gotten that far the password is already compromised and the account should be locked. ScottishFinnishRadish (talk) 22:25, 2 November 2022 (UTC)[reply]
    This does not solve almost all of the accessibility issues with captchas for those who are unable to see images for whatever reason, e.g. a disability. Thryduulf (talk) 10:21, 3 November 2022 (UTC)[reply]
    It's an anti-phishing mechanism that works equally well with a pre-selected phrase. Note, though, it's a knowledge-based authentication mechanism, so it can't be combined with a password to implement a two-factor authentication system. isaacl (talk) 15:43, 3 November 2022 (UTC)[reply]
  • Have the potential returning admin clearly and explicitly confirm that their password is at least 10 characters and not used anywhere else and explicitly agree to continue that practice. Maybe add a few more things like it's not on a sticky note on their monitor. Heck, it would be good & needed preventive medicine and very reasonable to have all admins confirm that. I don't think that people are going to lie about that. 2FA schemes have lots that can go wrong or impair things. Sending to RFA sounds like a bad idea....sounds like it would only be deterrence/punishment. RFA is structured for other things, not community judgement on password issues. Sincerely North8000 (talk) 22:01, 2 November 2022 (UTC)[reply]

Temporary checkuser privileges for scrutineers (November 2022)

On recommendation of the Electoral Commission, temporary English Wikipedia checkuser privileges are granted to stewards Sotiale, Martin Urbanec, and Hasley solely for the purpose of their acting as scrutineers in the 2022 Arbitration Committee election.

For this motion there are 12 active arbitrators. With 0 arbitrators abstaining, 7 support or oppose votes are a majority.

Enacted - KevinL (aka L235 · t · c) 20:42, 6 November 2022 (UTC)[reply]
Support
  1. Izno (talk) 00:38, 5 November 2022 (UTC)[reply]
  2. As always, thank you Stewards for your service. CaptainEek Edits Ho Cap'n!⚓ 00:47, 5 November 2022 (UTC)[reply]
  3. KevinL (aka L235 · t · c) 01:00, 5 November 2022 (UTC)[reply]
  4. Maxim(talk) 01:29, 5 November 2022 (UTC)[reply]
  5. Barkeep49 (talk) 01:37, 5 November 2022 (UTC)[reply]
  6. WormTT(talk) 08:16, 5 November 2022 (UTC)[reply]
  7. Thanks to all three for stepping up. Cabayi (talk) 10:59, 5 November 2022 (UTC)[reply]
  8. Donald Albury 13:10, 5 November 2022 (UTC)[reply]
  9. BDD (talk) 16:15, 5 November 2022 (UTC)[reply]
Oppose
Abstain
Recuse
Arbitrator discussion
Community discussion
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Arbitration/Requests/Motions&oldid=1120402564"