1466843 - Consider re-auth when adding/removing two-step auth and primary email changes on an FxA account

Status: RESOLVED MOVED

(Cloud Services :: Server: Firefox Accounts, enhancement)

Description

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

I was poking around the two-step auth capability in FxA and I was thinking it might be an added benefit to re-auth (either with password and/or TOTP) as a mechanism to prevent an attacker from taking over a logged in FxA session and then permanently taking it over without knowing the users password or demonstrating they have control over the users TOTP device.

Reproduction:

1.) Login to FxA settings panel
2.) Enabled 2-step auth (notice additional credentials did not need to be proven)
3.) Disable 2-step auth (noticed additional credentials did not need to be proven)

I believe the threat scenario could be:

- I leave my computer unlocked, someone goes to accounts.firefox.com and either enables 2-step auth and logs me out (effectively locking me out of my FxA account) or disables 2-step auth and logs me out (effectively making my 2nd factor null and void)

If we compare this to a service like GitHub, they require a second factor verification step if the user is making changes to critical aspects of the account, such as password change, 2FA change, GPG registration, etc.  To me, doing so adds a little bit of user friction, but I think it adds more of a barrier to prevent an account from being orphaned or degraded security just by visiting a URL for a logged in user.

Comment 1

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

This also appears to be the case for secondary email and then make primary feature, which would allow a session which has been compromised (either via vulnerability where session was exposed -OR- via walk up unlocked screen mentioned above) and the end result would be that I could follow the following steps to compromise the account permanently...

Reproduction:

1.) Obtain access to a logged in FxA session (yes, this assumes a user compromise of sorts)
2.) Add a secondary email ([e-mail])
3.) Verify secondary email
4.) Make secondary email primary
5.) Remove original email
6.) Sign into browser with new email and sync all users sync data (possibly lockbox content?)

And to be clear, this would suppose a pre-existing session compromise of any FxA user (they could be 2-step enabled or not) and this procedure would allow an attacker to persistently takeover an account.  Additionally, the original primary email would get notified via email that these steps happened, but I'm quite certain they would have no recourse other than to contact use and state their case, meanwhile there data would be exposed.

Comment 2

[Ryan Kelly [:rfkelly]]

Thanks for the report, I agree this would be a good protective measure.

> 6.) Sign into browser with new email and sync all users sync data (possibly lockbox content?)

This step presumes that that attacker either knows the account password, or has reset it.  Doing a password reset destroys the account encryption keys and would prevent the attacker from accessing data previously stored in sync.

They could do other things with the account though, like sign in to AMO and publish malicious versions of addons, or sign in to NDA'd internal mozilla services via IAM.  But all of those things could also be done directly from the compromised session in step (1).

Comment 3

[Ryan Kelly [:rfkelly]]

Implementation-wise, I think we have established a decent UX pattern for this, where we have an "unlock" button that prompts the use for the appropriate verification before showing security-sensitive settings screen panels.  We could implement this by having the backend require a certain threshold of "freshness" on the verification actions, such as only allowing 2FA to be disabled if the session was 2FA-verified within the last 5 minutes.

Comment 4

[Ryan Kelly [:rfkelly]]

I also think it'd be OK for us to work on implementing the above in public issues, but would be happy to be convinced otherwise if it feels too security-sensitive for that.

Comment 5

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

(In reply to Ryan Kelly [:rfkelly] from comment #4)
> I also think it'd be OK for us to work on implementing the above in public
> issues, but would be happy to be convinced otherwise if it feels too
> security-sensitive for that.

That seems appropriate to me, mainly because the working assumption is this would be additional security control that would only apply in circumstances where a session is already compromised and we're trying to contain the blast radius.

Comment 6

[Jonathan Claudius [:claudijd] (use NEEDINFO)]

Checked-in with g-k for a second opinion, we're both cool with opening this up to the public.

Comment 8

[Wil Clouser [:clouserw]]

The inverse of this (confirming via 2FA before resetting password) is tracked at https://mozilla-hub.atlassian.net/browse/FXA-9352

I'm assigning to Vesta to decide if she wants to do more or close this.

Comment 9

[vzare]

@wil I have created 2 related tickets:

• We should prompt for password when removing 2FA: https://mozilla-hub.atlassian.net/browse/FXA-9638
• We should require additional verification when changing primary email: https://mozilla-hub.atlassian.net/browse/FXA-9639

Comment 10

[Wil Clouser [:clouserw]]

thanks!