Store Webauthn Attestation on registration

[coelho]

Description

Zitadel should store the Webauthn Attestation for future audits. Follow up on: https://github.com/zitadel/zitadel/discussions/4429

Acceptance criteria

• [ ] Attestation Conveyance Preference should be configurable or be by default "direct". Currently it is "none". https://github.com/zitadel/zitadel/blob/main/internal/webauthn/webauthn.go#L78 This appears to cause Yubikey hardware tokens to produce an empty aaguid.

• [ ] Raw Credential Data from registration should be stored. https://github.com/zitadel/zitadel/blob/main/internal/webauthn/webauthn.go#L100 credentialData can serialize into JSON and store as-is. This is for future proofing. Currently, the credential var contains a very small submit of the data in credentialData.

Future Work

• Allow this information to be viewed in the console.
• Allow the administrator to whitelist tokens by aaguid. The database for all hardware token aaguids is also publicly available, so there could also be a directory?

[hifabienne]

Hi @coelho Thanks for creating the issue, we will have a look at it in our next planning and prioritize it.

[udf2457]

@hifabienne I was doing some research on ZITADEL and using the Yubikey attestation is on my checklist. Has there been any movement on this feature since 2022 ?

[hifabienne]

Hei @udf2457 At the moment there is not progress on this issue. If there is a significant demand from customers/community, we will carefully consider implementing the feature. Currently, the issue is added to our product backlog to collect feedback.

[coelho]

@hifabienne

Hei @udf2457 At the moment there is not progress on this issue. If there is a significant demand from customers/community, we will carefully consider implementing the feature. Currently, the issue is added to our product backlog to collect feedback.

FYI this feature is 2-fold:

1. Collect the data (tiny scope) (<- this issue)
2. Use the data (larger scope, but users can already utilize via SQL audits)

When 1. is complete, a customer would have to remove every security key, and have users re-enroll, to collect the data. It is not clear why Zitadel is not already collecting this data, even though it receives it.

We decided to not consider a migration to Zitadel without this feature due to: a. security posture requiring us to use and audit security keys. b. migrating our users, enrolling security keys manually, and then having to do it all over again (when/if this is implemented) to collect and input the data into the ledger.

[hifabienne]

@livio-a @muhlemmer what is your take on this?

[udf2457]

@hifabienne @coelho Thank you for your detailed reply.

However I should perhaps point out that whilst you may see Passkeys as a suitable alternative, they really are not for security conscious environments.

This is because there is no attestation available with Passkeys, this is (sadly !) by design. This means that:

1. You have no way of knowing if a Passkey was generated insecurely in software emulation or securely in an enclave
2. You have no attestation validation options to validate the devices the Passkeys are being used on

This is why Yubikey attestation has a place in the world, because:

1. Through attestation, you can validate it was securely generated on a Yubikey in non-exfilterable form
2. If you wish, you can go one level further and verify it was on a specific Yubikey hardware family, or indeed a user-specific Yubikey.

None of that can be done on Passkeys.

Passkeys have their place, but only in low assurance environments. They are not suitable for high assurance environments where you need a high degree of certainty that the user authenticating is the owner of the authenticator and the credential is hardware-bound to prevent impersonation.

[coelho]

@hifabienne By "Security key" in my reply, I mean "YubiKey"/"HSM".

• I agree, Passkeys are an unfortunate mistake.
• I agree, Webauthn attestation is the only way to ensure the use of hardware keys / secure enclaves. Otherwise, there is no way to audit or guarantee that 2FA/Passwordless is setup securely.