Maybe Release-Engineering-Team has some input / thoughts?

@mseckington Any recommendations? TIA

@Bmueller mentioned that this might also be in the realm of Security-Team. Comments welcome.
I know that nobody is happy about more on their list, but I'd like to reduce single points of failure, and this isn't needed too often.

@Aklapper - Will plan to review with Security-Team leadership this week.

@sbassett: Thanks. Any updates? This is a bottleneck, e.g. I missed T330073 (and nobody else picked it up either)...

In T306708#8657402, @Aklapper wrote:

@sbassett: Thanks. Any updates? This is a bottleneck, e.g. I missed T330073 (and nobody else picked it up either)...

The update is an unfortunate one, in that we do not feel we are currently resourced to take on this additional service/workload.

@sbassett: Thanks for the update! @Bmueller: Please share how to best proceed here. Thanks!

Not sure what the process is now but I created a ticket T334480

https://www.mediawiki.org/wiki/Topic:Xi3nbbjzvuavtbu4 is the most recent example that things do not work currently.

Paraphrasing/quoting a conversation with @acooper so we have thoughts in one place:

• Staff 2FA resets are easier, could streamline and have an official policy.
  • Ideally, verification could be performed by someone (the verifier) who knows the affected person and who is able to identify
  • Ideally the staff member performs the verification over a video call, due to concerns about other potential auth systems having (too) long lived tokens
  • The verifier then updates the ticket (if the request was actually brought up in a ticket (see "Define a place where 2FA reset requests can be brought up when user cannot log into Phab anymore" above)
• For scalability issues with the actual act of enacting the 2FA reset requests, that requires shell/admin permissions (see "That action requires being listed" above)

performs the verification over a video call

To verify someone over video call the verifier would have to know how each given user looks and who they are (and who they report to). I am not sure this is the case (anymore) unless the verifier has Namely access and Namely always has current data and profile photos uploaded by HR?

Namely goes away anyway. :)
It would mean finding a person who both the requestor and the resetter know how they look like, and other way round (latest example).
And that negotiation does not sound like a great use of time for anyone (but sure... security).

In T306708#9318592, @Aklapper wrote:

Namely goes away anyway. :)

I would hope that Dayforce has similar directory searching capabilities. If it does not, that would be very unfortunate, for a number of reasons.

It would mean finding a person who both the requestor and the resetter know how they look like, and other way round (latest example).
And that negotiation does not sound like a great use of time for anyone (but sure... security).

I'd agree that this isn't a very sustainable option, on its face (no pun intended). I think pairing it with asking a live individual certain questions that might only be available from data on officewiki or within Dayforce might be ok though, and would rely less upon verifying someone based upon their current physical appearance.

I was assuming finding the person would be easy - it would be maybe their manager? Which is easily available from the address book.

Oh and all that is required is for the verifier to also post a message authenticated to their accounted confirming they have verified the identity. The verifier in this case is someone from the persons team or management chain. So its not a fixed identity.

The admin would then only need to verify that the verifier posted an authenticated message (e.g. to a phab ticket comment) confirming they verified the user in question.

You could also require messages of acknowledgement to be sent across at least two authentication domains to increase the security. So say a slack message (linked in a phab comment) and a phab comment.

In T306708#9323224, @acooper wrote:

I was assuming finding the person would be easy - it would be maybe their manager? Which is easily available from the address book.

Are you referring to Namely or another address book?

posted an authenticated message (e.g. to a phab ticket comment)

I think part of the problem is that you don't know who actually created the Phab account in the first place, unless it's linked to a wiki user and that wiki user was created by office IT and you follow the whole chain. I could be wrong though.

Namely or just the gmail synced address book.

I think the problem you referred to about unknown usernames to employee mapping, can also be fixed quite easily and without any significant changes to the proposed process. Say a unknown employee user called PACMAN (I'm just making up a name this doesn't refer to anyone specifically). PACMAN knows who they are. They reach out to their manager for video verification. Once that's been done their manager writes a message confirming that they have validated PACMAN's identity and confirming which employee they are.

I have also been thinking about volunteers who are not employees. This is quite a difficult problem as we don't have many trusted means to verify. I have a few ideas I am thinking about:

• Have a WMF staff member who knows the volunteer verify them over a video call. HOWEVER, there seems quite a high likelihood they either don't know a WMF staff member, or even if they do, they wouldn't know what they look like.
• Have 1 or more other community members of good standing (admins?) verify the identity and vouch that it was done.
• Prove access to the email address associated with the account, combined with waiting for a period of time before performing the reset (maybe 30 days) which allows time for a possible account takeover scenario to be detected and remediated.
• Prove access to a wikipedia account with the same username by writing a talk message. I am not sure how common it is that the usernames match though?

Also could require some combination of the above. Has anyone got any other ideas?