== Secrets ==
Each Service Node has a unique Master Secret per Node it serves, that it shares with the Login Server. A Master Secret ,which is a timestamp rounded used to the second, followed by a column, sign and validate authentication tokens. Multiple secrets can be active at any one time to support graceful rolling over to a pseudo-random hex string of 256 chars from [a-f0-9]new secret.
Example To simplify management of generating such stringthese secrets, the tokenserver maintains a single list of master secrets and derives a secret specific to each node using HKDF:
>>> import binascii* node-info = "services.mozilla.com/mozsvc/v1/node_secret/" + node-name* node-master-secret = HKDF(master-secret, ossalt=None, time >>> print '%d:%s' % (int(time.time())info=node-info, binascii.b2a_hex(os.urandom(256))[:256]size=digest-length) 1326322983:646dc48...4ad86dca82d
(XXX crypto review required, not sure if this The node-specific Master Secret is the best/correct way used to use HKDF derive keys for this purpose)various cryptographic routines. At startup time, the Login Server and Node should pre-calculate and cache the signing key as follows:
The Master Secret is used to derive keys for various cryptographic routines. At startup time, the Login Server and Node should pre-calculate and cache the signing key as follows: * sig-secret: HKDF(node-master-secret, salt=None, info="SIGNING", size=digest-length)
By using a no salt (or a fixed salt) these secrets can be calculated once and then used for each request.
When issuing or checking an Auth Token, the corresponding Token Secret is calculated as:
* token-secret: b64encode(HKDF(node-master-secret, salt=token-salt, info=auth-token, size=digest-length))
Note that the token-secret is base64-encoded for ease of transmission back to the client.
=== Shared Configuring Secrets File === The tokenserver should be configured to use the DerivedSecrets class with the list of master secrets:
Ops create [tokenserver] secrets for each Node, and maintain for each cluster a file containing all .backend = mozsvc.secrets. The file is deployed on the Login Server and on each Service Node. The Login Server has all clusters filesDerivedSecrets secrets.master_secrets = master-secret-one master-secret-two
Each file is a CSV file called '''/var/moz/shared_secrets/CLUSTER''', where CLUSTER is node should be configured to use the name of the cluster,FixedSecrets class and its corresponding derived secret:
Example: [hawkauth] secrets.backend = mozsvc.secrets.FixedSecrets secrets.secrets = node-master-secret-one, node-master-secret-two
phx1,1326322983:secret phx2,1326322990:secret ..This prevents a compromise on one service node from leaking the secrets on all nodes.
=== Secret Update Process ===
When an existing To revoke the secrets for a specific node, simply rename it so that its derived secret needs to will be different. To update the master secrets, the following procedure should be changed used: 1) Generate the new master secret, but keep the old one as well for whatever reasonnow 2) For each storage node, Ops can add derive both the new and old node-specific secretsand push them out, so that its config file looks like this: [hawkauth] secrets.backend = mozsvc.secrets.FixedSecrets secrets.secrets = <old-derived-node-secret-as-hex> <new-derived-node-secret-as-hex> Restart it. It is now able to the fileaccept tokens signed with either secret.
The 3) For each tokenserver webhead, update it with the new master secret is appended to , removingthe Node's line on each old one. Its config file will look like:
phx1,1326322983:secret,1326324523:secret [tokenserver] phx2,1326322990:secret secrets.backend = mozsvc.secrets.DerivedSecrets secrets.master_secrets = <new-master-secret-as-hex>
The Service Nodes are the first ones to be updated, then the Login Server is updated in turn, so Restart it. It now generates tokens signed with the new tokens are immediatly recognized by the Nodesderived secrets.
The Service Node sorts 4) Discard the old master secret by timestamp and tries the newest one, then fallback to the next one in case the token could not be validated.
The Login Server always works with the newest secret5) Wait for one token expiration period, so ignores older secrets when it creates tokense. Old secret are pruned eventuallyg. five minutes.
The Login Server and Service Node applications should watch 6) For each storage node, derive just the files new node-specific secret and reload them in case they change.pushit out, so that its config file looks like this:
=== Pulling a secret ===
