824188 - Store salts on the Sync server

Status: NEW

(Cloud Services :: General, defect)

Description

[Richard Newman [:rnewman]]

Some Sync datatypes have a natural primary key: e.g., the favicon URL for favicons, or the add-on ID for add-ons.

We can't use it directly, because we have a strong requirement to not leak user data through identifiers (which appear in logs).

That is, a user's browsing history, known favicons, installed add-ons, etc., should not be determinable from some GUID.

Until now we've used generated GUIDs for these entities. This requires storage on every client, which is redundant.

An alternative is to provide encrypted salt storage on the Sync server. Clients can use the salt to hash the primary key to get an identifier for upload, and look at the contents (which includes the raw primary key) for inbound processing.

We might store salts in the crypto collection, a collection of their own, or in meta. Doesn't matter too much.

Comment 1

[Nick Alexander :nalexander [he/him]]

The current plans for key-wrapping authenticate the client via SRP, which includes choosing a salt.  This salt must be public, which if I understand correctly, is not suitable for your proposal.

Presumably the salt must be constant for the lifetime of the Sync account.  Some good news: the current key-wrapping proposal is a general "secret wrapping" proposal.  The bad news: the current key-wrapping proposal is designed so that "wrapped secrets" are stored by each service.  That means keeping it on the Sync storage server, which in the current atmosphere of node migration, is not sufficient when we factor in the new atmosphere of maintaining the user's account even when all clients are disconnected.

So we need to think carefully about storing the salt elsewhere, and we either factor this requirement into the key-wrapping proposal, or we raise questions about how much unprotected information we are willing to store, and how durably.  Tricky.

Comment 2

[Richard Newman [:rnewman]]

(In reply to Nick Alexander :nalexander from comment #1)
> The current plans for key-wrapping authenticate the client via SRP, which
> includes choosing a salt.  This salt must be public, which if I understand
> correctly, is not suitable for your proposal.

Correct.


> Presumably the salt must be constant for the lifetime of the Sync account. 

Nope; same lifespan as the collection.

> Some good news: the current key-wrapping proposal is a general "secret
> wrapping" proposal.  The bad news: the current key-wrapping proposal is
> designed so that "wrapped secrets" are stored by each service.  That means
> keeping it on the Sync storage server, which in the current atmosphere of
> node migration, is not sufficient when we factor in the new atmosphere of
> maintaining the user's account even when all clients are disconnected.

The salt(s) don't have any meaning except during upload; they're just part of a function f(record, salt) => ID.

After a node migration or wipe, data reupload is necessary (or migration would already have been performed by the storage service; either way, the salt lives as long as the data). If the salt is gone because data is gone, a new salt can be produced without worry. If the salt is gone and the data is present, we need to wipe and reupload (possibly after expensive local reconciling to avoid data loss).

Salts are intrinsically linked to the data on the storage server, so I don't see a problem with storing them in the same place.

I'm happy with salts living in the same place as bulk keys and meta/global: they're all storage-specific metadata that allows clients to interpret the contents of storage.