diff --git a/docs/USER_RECORD.md b/docs/USER_RECORD.md index 960a82d894..6cba02aa0c 100644 --- a/docs/USER_RECORD.md +++ b/docs/USER_RECORD.md @@ -553,6 +553,11 @@ credential ID that shell be used for authentication with FIDO2 devices that implement the `hmac-secret` extension. The salt to pass to the FIDO2 device is found in `fido2HmacSalt`. +`recoveryKeyType` → An array of strings, each indicating the type of one +recovery key. The only supported recovery key type at the moment is `modhex64`, +for details see the description of `recoveryKey` below. An account may have any +number of recovery keys defined, and the array should have one entry for each. + `privileged` → An object, which contains the fields of the `privileged` section of the user record, see below. @@ -632,6 +637,25 @@ matching one in `fido2HmacCredential`, and vice versa, with the same credential ID, appearing in the same order, but this should not be required by applications processing user records. +`recoveryKey`→ An array of objects, each defining a recovery key. The object +has two mandatory fields: `type` indicates the type of recovery key. The only +currently permitted value is the string `modhex64`. The `hashedPassword` field +contains a UNIX password hash of the normalized recovery key. Recovery keys are +in most ways similar to regular passwords, except that they are generated by +the computer, not chosen by the user, and are longer. Currently, the only +supported recovery key format is `modhex64`, which consists of 64 +[modhex](https://developers.yubico.com/yubico-c/Manuals/modhex.1.html) +characters (i.e. 256bit of information), in groups of 8 chars separated by +dashes, +e.g. `lhkbicdj-trbuftjv-tviijfck-dfvbknrh-uiulbhui-higltier-kecfhkbk-egrirkui`. Recovery +keys should be accepted wherever regular passwords are. The `recoveryKey` field +should always be accompanied by a `recoveryKeyType` field (see above), and each +entry in either should map 1:1 to an entry in the other, in the same order and +matching the type. When accepting a recovery key it should be brought +automatically into normalized form, i.e. the dashes inserted when missing, and +converted into lowercase before tested against the UNIX password hash, so that +recovery keys are effectively case-insensitive. + ## Fields in the `perMachine` section As mentioned, the `perMachine` section contains settings that shall apply to