Allow functionaries to reset second factor on low-risk accounts
Open, Stalled, Needs TriagePublic

Description

One of the major concerns with introducing OATHAuth to large wikis like English Wikipedia is that users will frequently misplace their key (buy a new phone etc) and mismanage their scratch tokens, and developers will be bogged down by the stream of account reset requests. It would be nice to have a web interface where select functionaries (stewards?) could reset 2FA for low-risk accounts (while admins, staff etc. would still require a developer reset).

Tgr created this task.Nov 19 2017, 6:20 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 19 2017, 6:20 AM

People should be told that they should not store the scratch codes in the same device that generates the token. Nearly all requests for 2FA resets I've witnessed are because of this.

As steward I'd say that there are no low-risk accounts per se, as all of them can be granted advanced permissions in the future or already have them. I'm not sure I want the responsability and liability to unlock an account in a process for now too much prone for social engineering.

Tgr added a comment.Nov 19 2017, 9:22 PM

Presumably the reset interface would send an email to the user, which would tell them to make noise if they did not actually ask for a reset. Also resetting would mean they are not able to log in anymore. So "sleeper attacks" (where the attacker convinces a steward to do the reset, obtains a 2FA key, then waits until the account gets promoted to an admin) are not possible.

In any case, hard to see how allowing users to to set up a second security check, and then occasionally botching it due to social engineering, would be less secure than not allowing them to set it up in the first case.

Customary note that "functionary" is not a defined term on 99 % of the wikis.

Tgr added a comment.Nov 19 2017, 9:32 PM

I didn't want to get bogged down in detail. Could be stewards and local bureaucrats, or whatever.

Zppix added a subscriber: Zppix.Nov 20 2017, 4:14 PM

If this is done imo reset should require that 2 seperate stewards/'crat/global admin/whatever should approve of said reset to reduce the risk of said social engineering.

Zppix added a comment.Nov 21 2017, 5:34 PM
This comment was removed by Zppix.

I suggest we push the conversation about who gets given this right on Wikimedia sites to a separate Wikimedia-Site-requests ticket created only after the OATHAuth extension is modified to allow for this to happen.

TheDJ added a subscriber: TheDJ.EditedNov 30 2017, 2:10 AM

We have had several instances where

  • people were still logged in, but knew that AFTER becoming logged out, they would loose access and were asking for password reset options.
  • other trusted users were vouching for the identity of people

My idea was:

  • Give people an interface to request a reset
  • User needs to enter his name and password to initiate request
    • Check if user knows his password
    • Check if user has a verified email address
    • Check if verified email address and password were not changed recently (last 30 days?)
    • Log if user was still logged in when making the request
    • Log if request was initiated from 'known device'
  • Now send the user an email with a reset token
  • User needs to click the link+token in the received email
  • Manual review by 'global' functionary
    • Functionary is provided with information on last log in, last edit, last activity, last email reset, date of request, if the user was logged in when he made request, and if that happened from a "known device"
    • Would do manual review of recent edit behavior
    • Possibly ask a checkuser to sign off on a reset request
  • Functionary approves or declines
  • Action of course noted in the logs

That to me would give a reasonable amount of certainty. while increasing overall security (having more people use 2FA). In my opinion, we need to recognize that people mess up sometimes. Most websites do.

jrbs moved this task from Backlog to Support on the Trust-and-Safety board.Jan 4 2018, 7:29 PM
jrbs added a subscriber: jrbs.Feb 1 2018, 6:37 PM
Huji added a subscriber: Huji.Mar 9 2018, 7:59 PM

IMHO even this is feature introducing some risk to users this should be as local as possible. For example I, as Czech Wikipedia administrator (medium wiki in size), I know quite a lot of very active (100+ edits/month) editors and can verify their request in various ways, including using chapter wiki, phone confirmation and of course, e-mail confirmation without using the Wikipedia interface. On the other hand, the stewards, althrough they are trusted at all wikis, do not know all the editors as well as the local editors.

As soon as login attempts (successful and unsuccessful) are logged in CheckUser, this should be the one responsible for reseting 2FA. I think that we can allow them to reset privileged accounts as well. For example, on Czech Wikipedia there are only a few of tech users who knows how to perform this kind of thing. Also, the developer with prod shell access may know the tech user but not the locked user themself. They can use some basic verifying method (mail) that is relatively easibly spoofable (sending an email from whatever address is easy technically) and trust the confirmation from the tech user. If this confirmation do for developer reset, why not move the responsibility too?

Of course, there are project without checkusers. Then, a steward should promote themself to this group, check recent login activity via CheckUser and require confirmation from bureaucrat or sysop policy-wise who will know the user more than the steward.

If we want, we can require at least two sign-offs, but I think that just one can do.

This is the problem with 2FA it supposed to be a system where the user needs something not digital to login a email account can be a hacked so if they manage to get a reset token mailed to them the physical aspect is away because there is now a digital access code in a email account which can be hacked. However it not viable to send a physical letter to every user who lost their 2FA. However for low-profile users without any additional permissions this is a option but its something you need to consider because its bound to in some way take away the physical aspect in my opinion we explicate state that if your lose your codes somehow your account is gone this of course would not apply to people who can physically ID themselves I.E an admin

Huji added a comment.Mar 11 2018, 9:08 PM

I think we should consider a non-email, non-physical alternative too. Such as a security question. Or verification via text message.

Note that we don't need to keep their phone number in original form, we can encrypt it using a one-way hash; if they ever decide to disable 2FA via text message, they would have to provide their phone number again and we would be able to use the same one-way hash to verify it. Indeed, the answer to the security questions can (and should) also be stored using a one-way hash. The idea is to give the users a way to verify their identity, without us retaining any personal information on them, and without relying on email.

Do not use security questions. Finding my mother's maiden name, birth year or my dog's name is very easy novadays. Also, do not use phone itself, as it is used as 2FA device frequently. When I lost my phone, I usually lost SIM card too. Without SIM it is impossible to read the message.

I think we should reuse existing things from user commited identity over community relationships to locking account to ensure the account owner will notice.

We can also store copies of ID card for limited time for cases the request will be found as spoofed - then we can fill a lawsuit against the spoofer.

I think we should consider a non-email, non-physical alternative too. Such as a security question. Or verification via text message.

Note that we don't need to keep their phone number in original form, we can encrypt it using a one-way hash; if they ever decide to disable 2FA via text message, they would have to provide their phone number again and we would be able to use the same one-way hash to verify it. Indeed, the answer to the security questions can (and should) also be stored using a one-way hash. The idea is to give the users a way to verify their identity, without us retaining any personal information on them, and without relying on email.

There's been lots of cases of people hijacking phone numbers in order to get around SMS based 2fa. Using phone numbers is probably not the most secure thing.

Tgr added a comment.Mar 12 2018, 7:46 AM

Let's not go overboard and invent systems that no one will actually use. Reset requests are already happening. The goal of this task is to make them happen without taking up WMF staff time, not to come up with a new system.

IMHO even this is feature introducing some risk to users this should be as local as possible.

There is no such thing as "local" when it comes to logins. Stewards should of course verify with the community of the user's home wiki that the request is legitimate (just like SuSa verifies it now).

The goal of this task is to make them happen without taking up WMF staff time

Well that should not happen. SuSa should continue to get involved. We cannot put this burden on volunteers and let them assume the liability of social engineering. I don't get paid, I'm not assuming the responsability here. There's also no such a thing "low-risk" accounts. Any account has the potential to become "high risk" by being promoted to higher user groups locally or globally. We've already got instances of socks waiting patiently and working hard to get elected to later cause as much havoc as they want. So no. This is a security feature. This is not the job of volunteers to assess if an account is compromised or not.

Tgr added a comment.Mar 12 2018, 10:36 PM

SuSa should continue to get involved.

SuSa is already not necessarily involved; all the relevant documentation requires is to notify them after the fact (which could be automated if this was a software feature). But someone with shell access has to be involved currently, which is not the best use of shell user time (not a big deal right now, probably would get worse if 2FA became more widely available).

We cannot put this burden on volunteers and let them assume the liability of social engineering. I don't get paid, I'm not assuming the responsability here.

Do you mean some kind of legal liability? Otherwise, I cannot make any sense of it. The status quo is that low-risk accounts are not allowed to use 2FA at all, (in part) due to WMF staff support being unable to scale to that. Surely being able to use 2FA, with some tiny theoretical chance of of someone social-engineering through it, is better than not being able to use 2FA at all?

Also, 2FA reset is far less dangerous than other responsibilities that volunteers already routinely assume (such as vetting JS changes, or granting someone write access to site JS via the sysop bit).

Also, I doubt there is much difference in what a staff member and a volunteer can do in terms of assessing reset requests. There are roles where training and experience make a big difference, like dealing with harassment, but I don't think this is one of them. Whoever does the review would have to rely largely on the local community's judgement as to the reliability of the requester's identity, and beyond that just go through a simple checklist (make sure to send an email, make sure to wait X days etc). The local community would be the one that has to deal with social engineering attempts.

Any account has the potential to become "high risk" by being promoted to higher user groups locally or globally.

I don't think there is any credible threat scenario where someone uses a socially engineered 2FA reset to get access to an account and then waits until the account gets promoted to exploit it. Even if the legitimate owner does not read their emails, the credentials reset will log them out and they won't be able to log back again.

Tgr added a comment.Mar 12 2018, 10:42 PM

Even if the legitimate owner does not read their emails, the credentials reset will log them out and they won't be able to log back again.

That's not actually the case, filed T189537: 2FA reset should log the user out.

revi added a subscriber: revi.Mar 13 2018, 6:48 AM

Do you mean some kind of legal liability?

Yes I do. When I promote an user to sysop, the user account is the only responsible for their actions. I am just applying the community consensus. What the user does with their access is not my (legal) problem. If I am resetting a 2FA, I am being responsible of giving somebody access to an account that can be or cannot be theirs, unless I am misinterpretting how the process is going to be.

Tgr changed the task status from Open to Stalled.Mar 13 2018, 6:29 PM

Blocked on legal review.