Signed Challenge use case

[Morotai]

All,

Noob question here. I have a use case where I want to validate a user via WebAuthn and in my mind, I wanted to persist the signed challenge for User1 client side so I can later trigger a verification process from User2 machine where I would send the signed challenge to the webauthn server and use User1's public key to verify the signature. This will attest that the challenge came indeed from User1. Reading some of the stuff on the docs, tells me this is a terrible idea. If that is the case, is there a way for me to sign some random string with the same process so I can safely store both on the server and client side? I know there are some stuff in the works with PRF but wanted to make sure before I keep going down this path. Much appreciated.

[Firstyear]

The problem here is that the Webauthn model doesn't sign only the challenge, it signs an entire statement of collected client data including the site origin, extension outputs and more.

So for you to proxy the signed CCD from user 1 to user 2, effectively would mean you just gave user 2 a legitimate, signed way to impersonate user 1.

Now, in theory this isn't such a big deal. Because the challenges are always unique per ceremony, the leak of the signed data to user 2 shouldn't compromise user 1.

The problem with the model you are suggesting is that the signed challenge and public key are both on the server, meaning that someone could just swap out both the challenge + public key on the server to impersonate user 1. So the only way you'd actully be able to do this "securely" would be to have the server provide the public key to user 2, but user 1 directly communicate it's signed data to user 2.

But then how would that UI/UX look? How would that work? There are likely easier ways to achieve this.

PRF won't really help here, that's a HMAC secret generator rather than asymmetric key cryptography.

In Kanidm we have something similar for out of band user verification. User 1 and 2 both have logged into Kanidm, possibly even on different kanidm servers. Since the user verified to Kanidm as the trusted third party, we need a way to relay this trust between the users.

To achieve this, the two kanidm servers take an internal secret only the servers know, and then use this plus the user id's of user 1 and 2 concatenated in a HMAC. This is then passed to TOTP which generates a TOTP that is displayed to user 1. User 1 reads this to user 2, who enters it. The kanidm server user 2 is connected to does the same process to verify the TOTP provided was legitimate. At this point User 2 now has assurance that User 1 must be authenticated correctly to a valid Kanidm server.

Now user 2 reads out their TOTP (derived by swapping the order of user id's in the HMAC process) to User 1. User 1 enters the code, and now has authenticated that User 2 must be authenticated correctly to a valid Kanidm server.

The nice part about this is that it's easy to do out of band (instant messenger, phone call, email). and because it's TOTP the codes change frequently enough. Finally, by deriving each code between the pair of accounts, it means that each combination of users always has unique TOTPs (so user 3 can't impersonate user 1 or 2 because their codes would be different).

So I'd ask "what you want to achieve" and then see if there is an easier way.

[witwaycorp]

Thank you very much for your time and thoughtfulness on this reply. Sending you an email instead if you don't mind and we can update this later.