Credential ID Generation
Hoang Tran
William
Emil Lundberg
I can see 2 concerns with this approach:
1. Knowing the RP ID (public information) and User ID (not entirely public, but not very secret) is enough to derive the credential ID.
Along with the new credProtect extension, the term "resident key" is getting decoupled from the implementation detail of how the private key is stored, and will instead refer to whether the credential can be used with an empty `allowCredentials` argument. This means that a private key stored in the authenticator can still be marked a non-resident key, which means it should _not_ be usable with empty `allowCredentials`.
With the formula `Credential ID = SHA-256(RP ID || User ID)`, anyone who has direct access to the authenticator and knows just the user ID can invoke authenticatorGetAssertion and get an assertion for a non-resident credential. This isn't exactly a violation of any protocol, but it is a bit undesirable since only the RP is expected to know the credential ID.
2. Creating a new credential for the same RP and user will result in the same credential ID.
Imagine that, for whatever reason, you register a credential with your account, then delete it and some point register a new one with the same authenticator. This shouldn't cause any problems in theory, but it's not unthinkable that some RPs would not completely delete the "deleted" credential but instead keep it for their records and mark it as revoked and unusable. Credential IDs are expected to be (probabilistically) unique, so this could trigger subtle bugs in the RP's key management code.
To address both concerns, I would suggest just making the credential ID (for stored keys) completely random and store it in the authenticator along with the key. This also means you know that the credential ID was indeed created by this same authenticator and not made up by someone trying to hack it.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/686fb928-e185-4026-811a-d8b3282bbd8f%40fidoalliance.org.
hatam
2019年10月1日火曜日 20時41分30秒 UTC+9 Emil Lundberg:
To unsubscribe from this group and stop receiving emails from it, send an email to fido...@fidoalliance.org.
Emil Lundberg
Hi Max,
Yes, how to implement credential ID is subject to each vendor's
implementation. There's no explicit guidance in either the
WebAuthn spec or the CTAP spec as far as I can tell.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/265183ed-34d4-44af-b7c5-d253eac1969d%40fidoalliance.org.
hatam
2019年10月7日月曜日 18時17分07秒 UTC+9 Emil Lundberg:
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/265183ed-34d4-44af-b7c5-d253eac1969d%40fidoalliance.org.
Hoang Tran
To unsubscribe from this group and stop receiving emails from it, send an email to fido...@fidoalliance.org.