-
Notifications
You must be signed in to change notification settings - Fork 1
Open
Description
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
- Security audit finding M6
- PR feat: challenge-response providers with KEK multi-device support #75 KEK multi-device support
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels