Login: 2FA via SMS: using same terminology to refer to SMS code and recovery code

[fabianapsimoes]

Steps to reproduce:

• choose an account that has 2FA via SMS enabled
• log in to that account in the WordPress mobile app
• visit /login, enter your credentials and click Log In
• you'll be redirected to /login/sms (should be /login/push, reported in Login: failing to default to push notification when 2FA via SMS is enabled #14152)
• click the link "The WordPress mobile app"
• you'll be redirected to /login/push where your alternative for log in is "Code via text message"

In the case of 2FA enabled by an authenticator app, in /login/push you'll see "An Authenticator app" and "Code via text message". For 2FA via SMS, we only have "Code via text message" (so no way to return to SMS auth).

As mentioned in #14158, "Code via text message" refers to recovery codes. In practice, the end result of that and of authenticating via SMS two-factor is the same (the user received an SMS with a code) but those are different things.

For example: use one phone number to enable 2FA and a different number under Me > Security > Account Recovery > Recovery SMS Number.

In the case above, when the user clicks "Code via text message", we'll send a code to the number they used to set up 2FA instead of to the number set for recovery. I guess alternatives are: a) having both options displayed; b) change the copy of that alternative so it's clear we're referring to a 2FA code, not a recovery one; and c) get rid of the idea of recovery codes in the context of 2FA via SMS (though that's still useful in the lost phone case, if you set the recover number as a friend's).

[michelleweber]

I'm not totally sure I agree that it's an issue? "Code via text message" just means we'll send you a code; there happen to be multiple situations where we might need to send you a code, but they're not options you access in the same place. I.e., you only get to this option after either going into 2FA or recovery settings. (I get the 2-phone issue, but that seems like an edgy edge case? I might be wrong.) But in the interest of being super-clear, we could do:

• Authentication code via text message
• Recovery code via text message

[fabianapsimoes]

It probably is an edge case, though it'd probably be the best way to use the Recovery SMS Number. That's how it works with my Google account for example, I have a number for 2FA via SMS and they force to choose another number as what they call a "backup number". It's probably a disservice to users to let them use the same number for different recovery methods, since losing access to that number will render both methods useless.

[michelleweber]

Makes sense. In that case, I'd just specify for each type of code, as above.

[fabianapsimoes]

Considering Michelle's input, this probably means we need to add both options in /login/push, since now we only display the recovery code option when the user as 2FA via SMS enabled.

Just thinking out loud: would maybe make sense to move the recovery code options to under the lost phone flow (currently dedicated only to backup codes)?

[fabianapsimoes]

Just thinking out loud: would maybe make sense to move the recovery code options to under the lost phone flow (currently dedicated only to backup codes)?

Actually, a user should be able to receive a recovery code even if they don't have 2FA enabled (just by having it set under Me > Security > Account Recovery > Recovery SMS Number), unlike backup codes. IIRC, we're only providing access to that option under the 2FA screens.

cc @danhauk

[danhauk]

@fabianapsimoes I would rather see the recovery code SMS option moved to the lost phone flow. I'm not crazy about adding even more option links to /login/push. It adds complexity as well as potential confusion (i.e. "what's the difference between these two text message options?"). If the user is trying to authenticate, we shouldn't show them an option that relates to account recovery.

Actually, a user should be able to receive a recovery code even if they don't have 2FA enabled

Yes! For example, if I forget both my username and the email address I used for my account, being able to verify my identity using the recovery SMS number would be a huge help.

We could add it to the Lost Password screen (which is currently outside of Calypso AFAIK).

[fabianapsimoes]

cc @yurynix who's working on a related issue.

[gziolo]

We could add it to the Lost Password screen (which is currently outside of Calypso AFAIK).

It's almost ported to Calypso, but still behind the flag.

I have a feeling that we make it all too complicated. I like the idea of hiding all recovery options behind one link :)

[scruffian]

When users set up 2FA we ask for their number "in cases where the 2FA Authenticator app isn't available". Given this, I think it is good for us to keep sending SMS to users for the purpose for 2FA, even if they selected an auth app when setting up 2FA.

The issue is that currently we're using the recovery SMS code endpoint instead of the 2FA one. We need to make sure the recovery endpoint is never used in the 2FA flow.

We shouldn't be offering recovery numbers in the 2FA flow. They should be presented only in the account recovery screens. cc @dllh

[ranh]

I'm not sure I quite understand the issue here, so I agree with @michelleweber.

Making a distinction between all these different types of codes and delivery mediums is not really important for users, unless there's a chance that users enter the wrong code.

As suggested in #14158, I think we can refer to this as just a "code", and only add any qualifications and clarifications as required by the flow. For example, re. the scenario you mentioned in the issue, it sounds like it would be enough to indicate what number we sent the code to.

Also +1 for @danhauk's suggestion to use the dedicated "lost phone" flow.

[fabianapsimoes]

Fixed in #14659.