Page MenuHomePhabricator

SMS based 2FA
Open, LowPublic


Explore the feasibility, and potential cost implications of implementing SMS as a way to receive login tokens

Event Timeline

Reedy created this task.Nov 16 2016, 10:32 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 16 2016, 10:32 PM
Reedy closed this task as Declined.Nov 23 2016, 12:43 AM
Tgr reopened this task as Open.Dec 7 2018, 6:52 PM
Tgr added a subscriber: Tgr.

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.

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
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.

[ 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.

Reedy added a comment.Dec 7 2018, 7:02 PM "NIST Softens Guidance on SMS Authentication" (about a year later)

I know the problems that SRE have getting Icinga notifications via SMS... Do we really want to open ourselves upto trying to support/debug texts working (or not working) to all parts of the world, probably via a third party provider doing the delivery?

Tgr added a comment.Dec 7 2018, 7:06 PM

I imagine technical troubleshooting would be done by the third-party provider, as long as we can verify that we initiated the request.

I don't want to downplay the potential problems with this (I imagine it's also more complex legally), OTOH if we want all admins to use 2FA (do we? I personally don't see the point but I think I saw it mentioned somewhere) it might be the only realistic opion.

Reedy added a comment.Dec 7 2018, 7:09 PM

I don't want to downplay the potential problems with this (I imagine it's also more complex legally), OTOH if we want all admins to use 2FA (do we? I personally don't see the point but I think I saw it mentioned somewhere) it might be the only realistic opion.

Do they all have a (smart)phone? :)

I'd suspect most have a phone, but I imagine we will have some without

T100373: WebAuthn (U2F) integration for Extension:OATHAuth is the other option, potentially with WMF providing devices, potentially, maybe? I dunno...

Reedy added a comment.Dec 7 2018, 7:13 PM

I imagine it's also more complex legally

GDPR related to storing peoples mobile numbers sounds fun :)

Tgr added a comment.Dec 7 2018, 7:22 PM

Fair point, U2F is actually both more user-friendly and more accessible than OTP (assuming we can support people in obtaining a 2FA device) since it can be used on an untrusted or somewhat restricted computer.

The one use case I can think of is someone using a severely restricted machine (military was mentioned as an example elsewhere) that does not allow installing USB drivers, and not having access to a smartphone, but having access to a feature phone... that does seem like a very fringe scenario.

Also SIM cards tend to not work when you travel abroad (OTOH a 2FA token is a lot easier to lose or accidentally leave at home than your phone), but I guess that's what scratch tokens are for.

Reedy added a comment.Dec 7 2018, 7:32 PM

There are "desktop" 2FA apps... I wonder if we should do a bit more research into them. Stuff that's desktop apps, browser extensions... that can also do 2FA code generations

Tgr added a comment.Dec 7 2018, 7:44 PM

If a computer is restricted enough that you can't install USB drivers chances are you can't install arbitrary software either.

Wikipedia lists a couple 2FA apps. There are a couple web-based tools (1Password is probably the highest-profile amongst them) although if you use those it's not really a second factor anymore.

Reedy added a comment.Dec 7 2018, 7:55 PM

I guess it's very much a "no silver bullet" thing. Why Facebook, Google et al offer so many different options

Jcross triaged this task as Low priority.Oct 4 2019, 4:42 PM
Jcross moved this task from Incoming to Watching on the Security-Team board.
awight added a subscriber: awight.Jun 22 2020, 1:01 PM