picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

docs: document new recovery key user record fields

This commit is contained in:
Lennart Poettering 2020-08-18 09:28:54 +02:00
parent 80c41552a8
commit 64abd37a60
1 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/USER_RECORD.md
View File

@ -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