1206325 - Changing Firefox Account password in other browser does not deauthorize Sync

Status: RESOLVED DUPLICATE of bug 1262272

(Firefox :: Sync, defect, P1)

Description

[Ryan Feeley [:rfeeley]]

Attachment: sync-log-and-screenshots.zip

* I signed up for Sync in a new profile
* I opened another new profile and logged into the respective Firefox Account
* I changed the password
* Hours later, the original profile still has not entered the re-authorize state, but Sign In To Sync does appear in Tools menu.

Attached are screenshots and sync log.

Comment 1

[Ryan Feeley [:rfeeley]]

And what do you know. Finally it triggered. I'd have to check th sync logs, but I'm going to say it was 5 hours? The UI looks right too.

1442629845255	FirefoxAccounts	ERROR	error POSTing /certificate/sign: {"code":401,"errno":110,"error":"Unauthorized","message":"Invalid authentication token in request signature","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format"}
1442629845256	FirefoxAccounts	ERROR	HAWK.signCertificate error: {"code":401,"errno":110,"error":"Unauthorized","message":"Invalid authentication token in request signature","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format"}
1442629845256	Sync.BrowserIDManager	ERROR	Authentication error in _fetchTokenForUser: {"details":{"code":401,"errno":110,"error":"Unauthorized","message":"Invalid authentication token in request signature","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format"}}
1442629845256	Sync.Status	DEBUG	Status.login: success.login => error.login.reason.account
1442629845257	Sync.Status	DEBUG	Status.service: success.status_ok => error.login.failed
1442629845257	Sync.BrowserIDManager	ERROR	Background fetch for key bundle failed: {"details":{"code":401,"errno":110,"error":"Unauthorized","message":"Invalid authentication token in request signature","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format"}}
1442629845345	Hawk	DEBUG	(Response) /account/status?uid=b1ec132eb8b2436fa0e00296f7a21efc: code: 200 - Status text: OK
1442629845345	Sync.RESTResponse	TRACE	Processing response headers.
1442629845346	Hawk	DEBUG	Clock offset vs https://api.accounts.firefox.com/v1: -346
1442629845346	Sync.BrowserIDManager	ERROR	Could not authenticate: {"details":{"code":401,"errno":110,"error":"Unauthorized","message":"Invalid authentication token in request signature","info":"https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format"}}
1442629845348	browserwindow.syncui	DEBUG	observed: weave:service:login:error
1442629845348	browserwindow.syncui	DEBUG	observed: weave:service:login:error
1442629845349	browserwindow.syncui	DEBUG	onActivityStop with numActive: 1
1442629845349	browserwindow.syncui	DEBUG	_loginFailed has sync state=error.login.reason.account
1442629845349	browserwindow.syncui	DEBUG	_loginFailed has sync state=error.login.reason.account
1442629845352	Sync.SyncScheduler	DEBUG	Clearing sync triggers and the global score.
1442629845352	Sync.ErrorHandler	ERROR	Sync encountered a login error

Comment 2

[Ryan Kelly [:rfkelly]]

> I'd have to check th sync logs, but I'm going to say it was 5 hours?

Sounds right, certificates expire after six hours, and the device is capable of syncing until its certificate expires.  We can make this more timely by:

1) reducing certificate duration, at the expense of more network traffic
2) sending notifications to all connected devices, which blocks on building the device registration API

Doing (2) is probably the best option and is a good driving use-case for the device push API stuff.

:rfeeley, did you allow the second profile to sync after changing your password?  IIRC there's supposed to be a code path that propagates password changes more aggressively than the 6-hour cert timeout window, but it is only triggered if a device with an updated password syncs successfully.

Comment 3

[Ryan Kelly [:rfkelly]]

> there's supposed to be a code path that propagates password changes more aggressively
> than the 6-hour cert timeout window

:markh asked for more explanation of this in IRC, so here we go:

When you change or reset your password, FxA sets an internal timestamp called the "generation number".  This number is included in the FxA identity assertion.  The tokenserver tracks the max vaue of generation-number that it has ever seen for a user, and rejects auth attempts with lower generation numbers.  So the flow should work like this:

* Device A starts syncing, gets a certificate with generation number X
* Tokenserver records current generation number as X
* Device B does a password change, increasing generation number to Y
* Device B starts syncing, gets a certificate with generation number Y
* Tokenserver records current generation number as Y
* Device A goes to sync again, using its not-yet-expired certificate
* Tokenserver sees cert has generation number X < Y, and rejects it with "invalid-generation" error
* Device A tries to refresh its certificate, fails because its session as been revoked enters reconnect state

Comment 4

[Ryan Kelly [:rfkelly]]

When we get [1] we can send an explicit message to the device to say "yo, your sessions has been revoked, get a new one".

Comment 5

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

(In reply to Ryan Kelly [:rfkelly] from comment #3)
> > there's supposed to be a code path that propagates password changes more aggressively
> > than the 6-hour cert timeout window
> 
> :markh asked for more explanation of this in IRC, so here we go:

Thanks - but I was a little confused and thought you meant the "token expiry". It appears the tokens have an expiry of 1 hour, so the mechanism you describe should leave us with 1 hour (the token expiry) rather than 6 hours (the cert expiry).  So yeah, it sounds like that's broken (and would certainly be better than 6 hours).

(In reply to Ryan Kelly [:rfkelly] from comment #4)
> When we get [1] we can send an explicit message to the device to say "yo,
> your sessions has been revoked, get a new one".

I assume [1] was going to be a reference to push? Yeah, that would help reduce the 1 hour down and would be a much better UX.

Comment 6

[Ryan Kelly [:rfkelly]]

> I assume [1] was going to be a reference to push?

Yes, specifically https://github.com/mozilla/fxa-auth-server/issues/1061

Comment 7

[Ryan Kelly [:rfkelly]]

This will be fixed by Bug 1226094

Comment 8

[Ryan Kelly [:rfkelly]]

We shipped some improvements to this Bug 1226094, which should bring the time-to-disconnection down to the lifetime of a tokenserver token.  That's still not great (1 hour as mentioned above) but much better than 5 or 6.  Should we keep the bug open to explore additional improvements, or close it out?

Comment 9

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

(In reply to Ryan Kelly [:rfkelly] from comment #8)
> We shipped some improvements to this Bug 1226094, which should bring the
> time-to-disconnection down to the lifetime of a tokenserver token.  That's
> still not great (1 hour as mentioned above) but much better than 5 or 6. 
> Should we keep the bug open to explore additional improvements, or close it
> out?

Seeing as nothing landed in this patch and that the 1 hour is still going to cause confusion, I'll "push" to keep it open (you see what I did there?? ;)

Comment 10

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

I'm confident bug 1262272 is the final piece of this puzzle (and sadly, I opened that bug recently forgetting this one existed, but that bug has the patch, so it wins the dupe-war)

Comment 11

[Lina Butler [:lina]]

(In reply to Mark Hammond [:markh] from comment #9)
> Seeing as nothing landed in this patch and that the 1 hour is still going to
> cause confusion, I'll "push" to keep it open (you see what I did there?? ;)

But bug 1262272 doesn't have this witty pun, so I think we're even. :-P