I think this is worth reconsidering. It is definitely less safe than OTP or U2F, but also easier to access (can be used with a non-smart phone) and easier to understand and set up (you just need to enter your phone number). Also somewhat harder to get locked out of (if the phone breaks, you can transfer the SIM card, and even if it is lost there are usually ways to transfer the number to a new SIM card) and still safe enough to protect against the script kiddie level attacks that we see regularly occurring.

In T150902#2816768, @Reedy wrote:

https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ advises against this...

That blog post raises three issues:

malware that can redirect text messages

I don't think this is a realistic threat model for wiki admins. (Btw, is it much harder to install malware that hijacks your 2FA app data than malware that hijacks your SMS messages? I imagine there is a standard permission for getting SMS access and no standard permission for getting the data of another app, but I have no idea how hard is it for an Android/iOS malware to get root.)

attacks against the mobile phone network (such as the so-called SS7 hack)

The link is about professional hackers breaking into the network connecting phone companies. Again, unless you are a bank or something this is not a realistic threat model.

and mobile phone number portability.

Phone ports, also known as SIM swaps, are where your mobile provider issues you a new SIM card to replace one that’s been lost, damaged, stolen or that is the wrong size for your new phone.

In many countries it is unfortunately far too easy for criminals to convince a mobile phone store to transfer someone’s phone number to a new SIM and therefore hijacking all their text messages.

This is slightly concerning; it can be pulled of by a dedicated amateur but can't be pulled off en masse the way password bruteforcing can (you need to walk into a mobile store or at least phone up the provider, and impersonate the owner). Also the attacker needs to know the real name of the user at the very least, and typically something like the last few digits of their SSN, which is typically not easy to guess for a wiki account. So maybe a realistic threat model for attacking someone with advanced privileges (like a steward or interface admin), but not for the low-effort, large-scale attacks against admin accounts that we see a lot of lately.

The blog post also claims implies that NIST recommends against SMS-based 2FA. I can find no proof of that. The relevant parts of the report are:

[5.1.3 Out-of-Band Devices] The out-of-band device SHOULD be uniquely addressable and communication over the secondary channel SHALL be encrypted unless sent via the public switched telephone network (PSTN). For additional authenticator requirements specific to the PSTN, see Section 5.1.3.3.
...
The out-of-band authenticator SHALL uniquely authenticate itself in one of the following ways when communicating with the verifier:
...

• Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device. This method SHALL only be used if a secret is being sent from the verifier to the out-of-band device via the PSTN (SMS or voice).

If a secret is sent by the verifier to the out-of-band device, the device SHOULD NOT display the authentication secret while it is locked by the owner (i.e., requires an entry of a PIN, passcode, or biometric to view). However, authenticators SHOULD indicate the receipt of an authentication secret on a locked device.
...
Depending on the type of out-of-band authenticator, one of the following SHALL take place:

• Transfer of secret to primary channel: The verifier MAY signal the device containing the subscriber’s authenticator to indicate readiness to authenticate. It SHALL then transmit a random secret to the out-of-band authenticator. The verifier SHALL then wait for the secret to be returned on the primary communication channel.

[5.1.3.3 Authentication using the Public Switched Telephone Network]
Use of the PSTN for out-of-band verification is RESTRICTED as described in this section and in Section 5.2.10. If out-of-band verification is to be made using the PSTN, the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device. Changing the pre-registered telephone number is considered to be the binding of a new authenticator and SHALL only occur as described in Section 6.1.2.
Verifiers SHOULD consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.

[5.2.10 Restricted Authenticators]
The use of a RESTRICTED authenticator requires that the implementing organization assess, understand, and accept the risks associated with that RESTRICTED authenticator and acknowledge that risk will likely increase over time. It is the responsibility of the organization to determine the level of acceptable risk for their system(s) and associated data and to define any methods for mitigating excessive risks.
...
Because the subscriber may be exposed to additional risk when an organization accepts a RESTRICTED authenticator and that the subscriber may have a limited understanding of and ability to control that risk, the CSP SHALL:

1. Offer subscribers at least one alternate authenticator that is not RESTRICTED and can be used to authenticate at the required AAL.
2. Provide meaningful notice to subscribers regarding the security risks of the RESTRICTED authenticator and availability of alternative(s) that are not RESTRICTED.
3. Address any additional risk to subscribers in its risk assessment.
4. Develop a migration plan for the possibility that the RESTRICTED authenticator is no longer acceptable at some point in the future and include this migration plan in its digital identity acceptance statement.

So, reading all that together, NIST seems to explicitly allow SMS authentication, while noting that it is more risky. If we want to use it in a compliant way, we need to provide some kind of warning to users that this is a weaker option and should be a last resort, and have a migration plan (I guess that means something like T172079 but switching to a different 2FA type). I'm not really sure what the verifier SHALL verify that the pre-registered telephone number being used is associated with a specific physical device means, probably just doing a 2FA check when setting 2FA up?

the device SHOULD NOT display the authentication secret while it is locked by the owner is not something we can control (you can probably configure your phone so that SMS messages can be read from the lock screen) but again phone theft is not a reasonable threat model for us.