Background
Device metadata (type, label, device_id) is stored in the unencrypted header's public_custom_data. An attacker with file access can enumerate enrolled devices without knowing the password.
Required in header (for protocol negotiation):
- Device type - to know which protocol (HMAC-SHA1 vs FIDO2 vs TPM)
- Device identifier - credential_id for FIDO2, slot for YubiKey
- wrapped_kek
Not required in header:
- Labels ("Primary YubiKey", "Backup") - purely for user convenience
Proposed Enhancement
Move device labels to the encrypted XML payload:
Header (unencrypted):
KDBXTOOL_CR_DEVICE_0: {"type":"yubikey_hmac","slot":2}\x00<wrapped_kek>
KDBXTOOL_CR_DEVICE_1: {"type":"fido2","credential_id":"..."}\x00<wrapped_kek>
Encrypted payload (Meta/CustomData):
<CustomData>
<Item><Key>KDBXTOOL_DEVICE_0_LABEL</Key><Value>Primary YubiKey</Value></Item>
<Item><Key>KDBXTOOL_DEVICE_1_LABEL</Key><Value>Backup FIDO2</Value></Item>
</CustomData>
Trade-offs
- (+) Labels hidden from file inspection
- (-) More complex implementation
- (-) Device management display shows "Device 0" until unlocked
- (-) Minor - device type/ID still visible (required for protocol)
References
Background
Device metadata (type, label, device_id) is stored in the unencrypted header's
public_custom_data. An attacker with file access can enumerate enrolled devices without knowing the password.Required in header (for protocol negotiation):
Not required in header:
Proposed Enhancement
Move device labels to the encrypted XML payload:
Header (unencrypted):
Encrypted payload (Meta/CustomData):
Trade-offs
References