1419552 - Changing FxA password from desktop disconnects iOS

Status: RESOLVED FIXED

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

Description

[Ryan Feeley [:rfeeley]]

STEPS TO REPRODUCE
- Register for Sync from Firefox desktop
- Sign in from an iOS device
- Return to desktop and change the account password
- View synced tabs on iOS

EXPECTED RESULTS
- Synced tabs are shown

ACTUAL RESULTS
- User is disconnected and taken to a force auth screen
- Desktop still may show as connected in synced tabs
- Can still appear to send tabs (but they never arrive)
- Changed password eventually makes its way over

Comment 1

[Lina Butler (ex-Mozilla)]

I think this is intentional, no? If you change your password on another device, your other devices can't sync until you sign in again. For example, if you change your password after losing your phone, my impression is we want to kick your phone out, instead of continuing to sync.

Ryan, would you prefer we show the cached list of synced tabs here, or go all the way and fully disconnect the iOS device?

Comment 2

[Mark Hammond [:markh] [:mhammond]]

I agree this is intentional - I know there's some magic so when the user changes their password on accounts.firefox.com the device they used is auto-updated, but IIUC that's as far as the magic goes.

> - User is disconnected and taken to a force auth screen
> - Desktop still may show as connected in synced tabs
> - Can still appear to send tabs (but they never arrive)

These states sounds like bugs.

> - Changed password eventually makes its way over

And this isn't expected - the user should explicitly enter their new password on each device.

Comment 3

[Ryan Feeley [:rfeeley]]

We struggle to retain multi-device syncers, and I think we'd like to make it as easy as possible.

For security, we offer device management on the web, and let users know about new devices signing in.

To me the default behaviour should be that even during a reset or change of password that devices remain syncing, but with the option to disconnect other devices until they re-enter their new password.

I think this would help with our multi-device retention a lot.

Seeing as we're syncing passwords, is this possible wihtout a lot of work?

Comment 4

[Lina Butler (ex-Mozilla)]

(In reply to Ryan Feeley [:rfeeley] from comment #3)
> For security, we offer device management on the web, and let users know
> about new devices signing in.

Sorry, I still have some security concerns about this. If we default to remain syncing, a person who stole your phone can easily log in to FxA, change your password, check the box, and lock you out of your own devices for good measure. Or they might keep it connected, and see if you start changing your passwords for your other services. Our security model very much depends on the FxA passwords, so I'm a bit wary of introducing chinks into that armor.

Also, I suspect you're most likely to remember your new password after you changed it. If we automatically propagate password changes, you're more likely to forget it when you need to sign back in, or sign in to a new device. I think requiring you to sign back in gives you a chance to practice using your new password.

That said, changing your password doesn't prevent you from accessing data that's already on that device; it just prevents that device from syncing new data. If you don't have master password our Touch ID set up, an attacker can still steal all your existing passwords.

Maybe we can run this as an experiment for a subset of FxA users? Do we have data showing that password changes (where you remember your old password) cause churn? How common are password changes today (compared to, say, password resets)?

> Seeing as we're syncing passwords, is this possible wihtout a lot of work?

We don't sync FxA credentials as part of password sync. I think this would need some work on the FxA side, to not invalidate sessions after a password change.

Ryan, do you have thoughts on this?

Comment 5

[Ryan Kelly [:rfkelly]]

> ACTUAL RESULTS
> - Changed password eventually makes its way over

I don't understand this point - Ryan, are you saying that the iOS device eventually got itself reconnected to sync despite you never re-entering the password on that device?  Or, do you mean that the new FxA password was synced over into the password manager on iOS, despite the device being (supposedly) disconnected from sync?

> For security, we offer device management on the web, and let users know about new devices signing in.

Yes, and one of the things we tell users to do if they see a suspicious device signing in is to change their password, because it disconnects the other devices.

> Do we have data showing that password changes (where you remember your old password) cause churn?
> How common are password changes today (compared to, say, password resets)?

These are great questions that we should get an answer to before we consider any change here.

> To me the default behaviour should be that even during a reset or change of password that devices remain syncing,
> but with the option to disconnect other devices until they re-enter their new password.

FWIW it's fundamentally impossible for a device to continue syncing after a password reset, because it won't be able to get the new encryption keys until you enter the new password on the device.

I feel pretty strongly that would be a bad idea even for password change.  It's not uncommon to have to re-enter your password on all your various devices after a password change, and I'd expect some set of users to consider the contrary behaviour a bug ("I changed my password but other devices kept syncing, what's going on??").

I'd go so far as to say, if our metrics tell us that there could be a significant win to be had here, we should loop in the platform security folks like :dveditz and :paultjt for an opinion on the tradeoffs involved.


All that said, I agree that the "disconnected after a password change" is currently quite janky.  There are issues with the timeliness of the disconnection (see e.g. Bug 1369116) and the appearance of still being connected in e.g. send-tab and synced tabs UI.  But I'd be a lot more comfortable with making that experience cleaner, than with trying to stay syncing in the face of a password change.

Comment 6

[Mark Hammond [:markh] [:mhammond]]

(In reply to Ryan Kelly [:rfkelly] from comment #5)
> > Do we have data showing that password changes (where you remember your old password) cause churn?
> > How common are password changes today (compared to, say, password resets)?
> 
> These are great questions that we should get an answer to before we consider
> any change here.

Leif, are you able to answer these questions relatively easily?

Comment 7

[Leif Oines [:loines]]

Based on the count of emails we send out after completion of a pw change / reset, there are around 8-10x more resets than PW changes. (see https://sql.telemetry.mozilla.org/queries/49639/source#133602 for raw numbers)

I'm working on figuring out churn due to pw changes. this is more difficult to do because both pw resets and pw changes generate the same `account.changedPassword` and `events.passwordChange` events. Furthermore, flow_id is null in emails sent after password changes so I can't tie those events back to a user id for purposes of churn estimation.

Comment 8

[Leif Oines [:loines]]

Edit: Here's an amplitude dashboard comparing retention for changes / resets. Not sure I trust the password change numbers though:
https://analytics.amplitude.com/org/31251/dashboard/k61q5qk

Password change volume seems to be low (compare to the password change email send numbers above), and retention for password changes seem to go up slightly on some days which doesn't make any sense. But if its correct-ish then retention after pw changes via prefs is not good.

Comment 9

[Mark Hammond [:markh] [:mhammond]]

(In reply to Leif Oines [:loines] from comment #7)
> Based on the count of emails we send out after completion of a pw change /
> reset, there are around 8-10x more resets than PW changes.

That makes sense to me - people aren't likely to change their password unless they believe it may be compromised in some way. However, people who want to add a new device but can't remember their password have no other option.

(In reply to Leif Oines [:loines] from comment #8)
> But if its correct-ish then retention after pw changes via prefs is not good.

hrm - that sounds odd - I wonder why someone would drop off as a user after a successful change? (Dropping off after a reset makes more sense as they are relatively likely to find their data lost in that scenario)

Comment 10

[Justin D'Arcangelo [:justindarc]]

Ryan, we're triaging this. What would you like us to do with this?

Comment 11

[Ryan Feeley [:rfeeley]]

Kit is right. I did not think the security through properly, although IIUC the threat to consider is not stolen unlocked phone, but rather remote attacks.

At Sync Fest today we did not have time to run this scenario, but it did really appear to Sync the changed password over into iOS.

We do force email reverification for secondary email for the same security reason. We could consider expanding that to change password as well?

Meaning we could:

1. force the user to upgrade their session before they can change their password
2. allow any user to change the password, but provide the ability to verified sessions to leave other devices connected


If neither of these are safe to do, I suppose we need to better communicate that password re-entry is required on all connected devices.

Comment 12

[Mark Hammond [:markh] [:mhammond]]

ni :rfkelly to comment on the above

Comment 13

[Ryan Kelly [:rfkelly]]

> Here's an amplitude dashboard comparing retention for changes / resets.
> Not sure I trust the password change numbers though:
>
> https://analytics.amplitude.com/org/31251/dashboard/k61q5qk
>
> Password change volume seems to be low (compare to the password change email send numbers above)

The amplitude event "fxa_pref - password" used here corresponds to the "settings.change-password.success" event from fxa-content-server.  Phil, as those events sampled in a way that might explain the discrepancy between the number of "fxa_pref - password" events and the number of password-changed emails we send out?

I also see that the password-change retention graph seems to contain a large number of anonymous users - users for whom amplitude has assigned a random numberic userid, because we didn't tell it the actual FxA user id.  See attached screenshot for an example.  This suggests to me that:

  a) There's a problem with export of "fxa_pref - password" events, because we should always know the FxA uid for that event
  b) The terrible retention rate is likely an artifact of incorrect userid tracking

I randomly clicked through to five non-anonymous users in that password-change cohort, and every single one of them was retained after the password reset.

Comment 14

[Ryan Kelly [:rfkelly]]

Attachment: lots_of_anonymous_users.png

Comment 15

[Ryan Kelly [:rfkelly]]

By the way, I'm moving this bug into the general FxA component, since I don't think there's anything iOS-specific about this behavior.  Changing your password anywhere will disconnect all devices, regardless of platform.

> We could consider expanding that to change password as well?  Meaning we could:
>
> 1. force the user to upgrade their session before they can change their password
> 2. allow any user to change the password, but provide the ability to verified sessions to leave other devices connected

These seem related to a different question than the one in this bug, along the lines of "can we prevent an attacker you knows your account password from locking you out of your account?".  That may be a worthwhile discussion but I think we should visit it more holistically than just for the "change password" feature, since it feeds into other security features like 2FA.

What I'm concerned about here is making our "change password" feature match user expectations, which can go wrong in a number of ways:

* The user expects that 'change password' will revoke any existing login sessions, but it doesn't.  This is bad because it "fails open" and might leave a compromised session unexpectedly attached to the account.  But on the plus side, the user will keep syncing.

* The user expects that 'change password' will leave existing sessions intact, but it doesn't.  The hypothesis is that this will cause the user to churn.  But on the plus side it "fails closed" in the sense that there's no possibility of security implications.

* We ask the user to choose.  It's not obvious to me whether this is something users want to do, or are properly informed/empowered to do.  I think we'd have to see a hypothetical UX treatment to get a sense for how this would work.

For comparison, I just tried a password change on twitter via the web interface.  It let me change the account password, and then it took me to a dedicated screen asking me to "review connected apps".  I had a bunch of stuff connected to my twitter that I'd forgotten about, and it was a good opportunity to purge!

I wonder if we could do a similar treatment in a way that defaults to the current disconnect-everything behaviour, but helps the user through a review of the connected devices if they choose to keep some connected.

> I suppose we need to better communicate that password re-entry is required on all connected devices.

TBH I feel like this is going to be the most bang-for-buck in the short term.

Comment 16

[Phil Booth [:pb]]

> Phil, as those events sampled in a way that might explain the discrepancy between the number of "fxa_pref - password"
> events and the number of password-changed emails we send out?

There's definitely no sampling.

> I also see that the password-change retention graph seems to contain a large number of anonymous users

Happily, I can reproduce this problem locally. Only 50% of the time at the moment, so I still need to zero in on the cause but it seems fixable. Digging into it now.

> The terrible retention rate is likely an artifact of incorrect userid tracking

Yep, it definitely is.

Comment 17

[Phil Booth [:pb]]

> Digging into it now.

https://github.com/mozilla/fxa-content-server/issues/5762

Comment 18

[Vijay Budhram]

from mtg: we will improve the messaging to the user after they changed password

Comment 19

[Vlad Filippov (:vladikoff)]

> from mtg: we will improve the messaging to the user after they changed password

Ryan, What messaging do we want to change for this?

Comment 20

[Ryan Feeley [:rfeeley]]

Follow here: https://github.com/mozilla/fxa-content-server/issues/5776

Comment 21

[Vlad Filippov (:vladikoff)]

Fixed in https://github.com/mozilla/fxa-content-server/pull/5896