Me/Security: Current 2FA flow lets users to file unverified phone number

[hoverduck]

To reproduce

• Click two step Get started
• Enter a valid phone number that you don’t have access to
• Click Verify via App

This flow will let users to have unverified phone number in file. We should either

• Verfiy phone number before allow to use the app
• Don’t require phone number for users who use the app

[ebinnion]

@westi @catrymer @kevko - I thought I'd ping y'all on this to get some input.

[catscheer]

Interesting bug. It's definitely not desirable to let users enter phone numbers that don't belong to them. It's the account recovery problem with unverified emails all over again. You have a typo at signup and don't notice it and now you can never fix it because that requires access to something you've never owned. We should definitely verify phone numbers before letting users add them to their account.

I don't love the option of not requiring phone numbers for app users. The phone number is a safety in case the app has to be reinstalled, has a bug after update that prevents it from working, is lost because of a replacement phone, etc. If users have a valid phone number they can always fall back to getting the code by SMS. We don't want them to be 100% dependent on the app.

[kevko]

This flow will have the unverified phone number in file, but will it let them actually authenticate with the unverified number? If it's the former, we have a usability issue -- we're just going to confuse users and Happiness Engineers alike. But if it's the latter, we have a security vulnerability which needs to be patched. And we should consider going back to see if any account may have been compromised, or is open to compromise, via this method.

I agree with Cat that having both methods is way stronger and less vulnerable to many failures via users forgetting, phone damage, SMS failure, etc. But they should be independently verified.

[ebinnion]

@rickybanister @alternatekev - It looks like we may need to add a step to the current 3-step 2fa activation process. What are y'all's thoughts? If we need to make significant changes, would one of y'all mind doing a mock?

For what it's worth, I enabled 2fa on DigitalOcean the other day, and their 2fa activation flow seems to be in line with the above recommendations:

Enter and verify SMS

Setup 2fa via app

Finished

[rickybanister]

I think this is a good way to go. My SO's phone broke this weekend and in order to set up her 2fa on her new phone she was able to use Google's SMS as a backup feature to get into her account and switch 2fa devices. Her backup codes were missing in a box somewhere and would otherwise have been shut out of her account. I imagine most people don't really keep backup codes around in a reliable way.

[kevko]

It used to be possible to have both SMS and app in place. Under the current design it appears impossible or at least very obscure.

My phone died last week so I had to switch quickly, and soon had to go through the 2fa dialogue. I did not have my backup codes on me at the time, but luckily I had both methods verified and could regain access with SMS. Otherwise, I would have been locked out, and very frustrated for a while.

If it was annoying for me, imagine the experience of those who do not work on this for a living.

tl;dr A thousand times yes to a process more like DigitalOceans. Or Google's.

[ebinnion]

Perhaps one possible solution is that we force SMS 2fa before allowing 2fa via app. With minor modification to the existing UI, we could make that happen:

1. Enter phone number

2. Verify phone number

3. Print backup codes

4. Optionally enable 2fa via app. Between the intro section and "Backup Codes" section, we could add a 2fa via app section perhaps?

cc @rickybanister @alternatekev for thoughts on the above.

[rickybanister]

I wouldn't mind if we refactored the three-step horizontal progress indicator to be a three step vertical grouping of compact-cards.

1. SMS (enter your phone number and then enter the code you receive, if verified move on to the next box below)
2. App set up (maybe this is optional, but this would come next)
3. Back up codes (once you verify a code you are complete)

[alternatekev]

@rickybanister what about auto-opened FoldableCards? We don't really have a great way of handling multiple-step processes, and my horizontal implementation here isn't great.

[kevko]

I'd be wary of requiring SMS to set up 2fa. In a number of countries the reliability of our SMS delivery is questionable and some people do not have a stable or permanent phone number.

IMO we should give a clear option to do either or both, independently verified.

[ebinnion]

@kevko So, allow 2fa either by app or by SMS. But, if the user chooses 2fa via app, don't require the user to enter in a cell? In this case, perhaps we could modify the security checkup to allow the user to enter/change their SMS number.

Going to go ahead and cc @mjangda as he worked on much of the checkup functionality.

[rickybanister]

I'd be wary of requiring SMS to set up 2fa. In a number of countries the reliability of our SMS delivery is questionable and some people do not have a stable or permanent phone number.

I agree with that, but perhaps we position it more as 'back up phone number' or something.

Google's implementation is great because you can recover your account via several paths if you lose your device that contains your 2fa app.

[kevko]

@ebinnion I would strongly encourage users to add both in the flow (or really as many backups as reasonable) but allow them to skip one if a method isn't possible for them.

[alternatekev]

[don't require SMS for app auth]I agree with that, but perhaps we position it more as 'back up phone number' or something.

I'm pretty sure the first version of this had that within the flow.

[rralian]

@ebinnion is this still active? Is there a quick way we can address this without changing the whole flow? And can we get this into an active milestone?

[ebinnion]

@rralian – This is a current issue. Frankly, I'm not sure if there's a quick way. I think the best solution is to change the flow so that we only allow 2fa via app once 2fa via SMS has been enabled.

[designsimply]

bug-scrub

Tested and confirmed using the steps provided.

^{Seen at https://wordpress.com/me/security/two-step using Safari 9.1.1 on Mac OS X 10.11.5}

I think the best solution is to change the flow so that we only allow 2fa via app once 2fa via SMS has been enabled.

I noticed you're forced to enter a code from the app to continue in the flow:

^{Seen at https://wordpress.com/me/security/two-step using Safari 9.1.1 on Mac OS X 10.11.5}

You could force an SMS verification as a step before that, but one potential gotcha I can think of is if you are traveling internationally and using a SIM card—possibly too edge case, but in that scenario it'd be nice to be able to use the app and skip the SMS temporarily in a pinch.

An alternate solution could be to keep the current flow but not allow the number to be used for recovery until it has been confirmed by SMS. If it has not been confirmed by SMS yet, you could show a dashboard notice asking them to verify by SMS on all Calypso screens until it's done.

[lancewillett]

Relooking at this during a bug scrub: this flow still needs review and possible tweaks, but it's not as high priority as I previously thought.

[designsimply]

bug-scrub

Re-tested and confirmed using the steps provided. Here is a video: 2m1s.

To resolve this issue short-term, I think hoverduck's suggestions are solid: either require an SMS verification up front or make the "Verify via App" flow separate from the "Verify via SMS" flow. I vote for adding a quick SMS step even if verifying via app is selected (maybe even change to one button that says "Verify").

[rickybanister]

cc @ashleighaxios to see if you have any thoughts as we look into sign-in and the auth flows.

[rachelmcr]

Bug scrub: I tested and confirmed that we still allow users to enter an unverified phone number when setting up 2FA with an app.

However, we now have a separate backup phone number in the Account Recovery section at https://wordpress.com/me/security/account-recovery that does require confirmation, so users who rely on an app for 2FA can also set up a verified backup number (separate from their 2FA settings) there.

[kwight]

Looking into this, I think we need some flow adjustments. We're trying to insert an SMS verification step into the App verification flow; we can use the SMS verification step for both flows, but will need to add some clarifying content when in the App flow. This all feels complicated also by the user having to enter their phone number on the first screen, then choose the type of 2FA verification.

I'd suggest the following:

• The user selects their preferred 2FA type from the first screen (rather than "get started").
• Both flows go to the SMS verification screens, but will have different explanations depending on the flow chosen.
• In the App flow, the user also goes to the App verification screen after entering their SMS code (via a "Next" button, versus an "Enable" button for SMS flows).
• Both flows then end up on same final backup codes screen.

It will involve some refactoring of Security2faEnable and the buttons, but mostly reuses what we have. Does this sound like a good idea for moving this forward?

There's an InVision mockup demonstrating both flows here: https://automattic.invisionapp.com/share/T9GS9VFX7SQ

The new App flow would look more like this:

[scruffian]

Since they need to set up with SMS in either case, does it make sense to give them the option? What about just going through the SMS setup flow first and then adding auth App as optional step once they have done the SMS setup?

One thing to bear in mind is this p58i-32i-p2.

[kwight]

Since they need to set up with SMS in either case, does it make sense to give them the option? What about just going through the SMS setup flow first and then adding auth App as optional step once they have done the SMS setup?

I like the idea that the user knows up front that we offer app-based 2FA, rather than having to discover it (although nothing stops us from informing them they'll have the choice down the road – it feels like basically the same thing at that point?).

One thing to bear in mind is this p58i-32i-p2.

Hm, yeah, that's interesting! It could be looked at again separately, for sure.

[rachelmcr]

I tested and confirmed the original issue — I am still able to enter an unverified phone number for 2FA and use that to receive 2FA SMS codes.

Noting that this issue is marked high priority; is that still accurate?

[darnelldibbles-zz]

Related: We have a user who, due to privacy concerns, is questioning why there is a requirement for a phone number for users who use the app. https://wordpress.com/forums/topic/two-setp-authentication-by-app-codes-and-user-privacy-violation/

[rootkea]

Asking user mobile number to set up 2FA SMS method makes sense but why to demand user's mobile number to set up 2FA authentication app codes method?

This feels like a user privacy violation.

As someone who values privacy and security deeply, why can’t I have 2FA authentication app codes method set up without having to give my phone number to WordPress.com like all other companies e.g. Twitter, Facebook, Reddit, LinkedIn, Discord, Dropbox, Github, Gitlab, Cloudflare, etc.?

Besides Wordpress.com I am yet to come across a company which requires user's mobile number to set up 2FA authentication app codes method.

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.