638905 - Provide server with proof of the client's possession of the user's Sync key (two factor auth for sync)

Status: RESOLVED INACTIVE

(Firefox :: Sync, enhancement)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Every client that accesses/modifies records for a given sync account has the user's password and their sync key. Right now, only the password is used to authenticate the user. The sync key could be used to additionally authenticate the user. That way, an attacker that knows the user's username/password would still not be able to add/modifiy/delete records for that user's account, without also stealing the sync key. Also, this might help in detecting sync key related errors (e.g. typos in entering a sync key manually).

One possible approach (not thoroughly analyzed):

From the Sync key, derive (using HKDF) an additional "proof of identity" (PID) HMAC key (in addition to the master encryption and HMAC keys). This key must be shared with the server whenever the sync key changes. Each request that adds/modifies/deletes records on the sync server must signed with the POD key. The server will verify the signature using its copy of the HMAC key. If the signature doesn't match, then the request fails.

Comment 1

[Mike Connor [:mconnor]]

So, offhand, this would break the account portal, which allows users to purge their sync data (which is useful in a future world where Sync is just one of many services using this user/pass).  Also, this would make "reset sync key" impossible, if _all_ delete requests much have this PID.

I don't really think this really adds security, though some of the ancilliary benefits are nice.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I think it is OK to handle deletion of data differently than a regular delete and/or require the PID only for add/modify operations. Clients already must operate under the assumption that they might not have received all the records that other clients have uploaded because the server can lose/delete any records it wants without any client noticing.

Comment 3

[Mike Connor [:mconnor]]

So, I don't know if I'd require this on GETs and the like, which makes this not really an "auth" solution.

However, I think this would be a really useful feature, because it would be pretty good for eliminating race conditions around key changes/storage version changes.  Basically, as soon as the key changes, all other clients are locked out from writing to the server (I'd do this even before we did deletes) until they have the new key.

Basically:
* prevents cases of content from different keys being present on the server
* not a security feature, but a data integrity feature (all data on the server should be obtainable from the same key)
* doesn't prevent "dataloss" from an attacker trying to nuke your stuff, but as Sync isn't considered a backup, that's ok.

Comment 4

[Richard Newman [:rnewman]]

I think we're going to end up in a place where even clients don't have your raw password, and we'll be doing something a little more complex with keys. nalexander, take a look.

Comment 5

[Nick Alexander :nalexander [he/him]]

(In reply to Richard Newman [:rnewman] from comment #4)
> I think we're going to end up in a place where even clients don't have your
> raw password, and we'll be doing something a little more complex with keys.
> nalexander, take a look.

Yes, that's correct.  The scheme we're pondering would have clients not have your PW except for a short set up window.

Clients would use your PW to get long-term tokens to access different services (like Sync).  (This is very much work in progress, but maybe something like http://people.mozilla.com/~nalexander/fxa/fxa-tokenflows1.pdf).

Clients would also use your PW to decrypt a full-strength "User key" stored on remote (Mozilla) servers; see https://wiki.mozilla.org/BrowserID_Key_Wrapping.  The Sync key itself would be stored on the Sync server, wrapped in this User key.

Coming to two-factor auth: an attacker that knows your password has access to all your sync data -- this is the scenario we are designing for.  We think it will be possible to support strong two factor auth by giving advanced users tools to manage their full-strength "User key" themselves, without ever storing them remotely or wrapping them in less than full-strength keys.  With a user managed "User key", an attacker needs your password to authenticate to the server, and then your "User key" to access your data.  We are still considering whether password alone is enough to delete your data and the multitude of lost password/lost user key/lost sync key possibilities.

Feedback welcome; this is hardly a full account of things we've been thinking about!

Comment 6

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

bulk closing old sync bugs with "closeme" in the whiteboard.