This repository has been archived by the owner on Dec 5, 2022. It is now read-only.
Challenge: urlsafe vs standard base64 #128
Comments
30 tasks
matoous
added a commit
to matoous/webauthn
that referenced
this issue
Dec 6, 2022
This fixes issue with wrong encoding being used for the challenge. According to the specs[^1] the challenge should be base64 url-safe encoded. Until now, the package used std encoding which uses slightly different set of characters. This was reported in the linked issue and we also encountered the same issue when testing our implementation of webauthn e2e using github.com/descope/virtualwebauthn. The commit removes the custom type for challenge and instead passes around the challenge url-safe base64 encoded right from the point of creation. Because the string is fully valid it can be safely used in json as well as stored in redis or other possible storage implementations that might be used by the clients of the library. I tried to keep the tests as close to the original as possible. In some cases that required transforming the challenge back to bytes considering the previously used padding to be part of the bytes and then re-encoding into url-safe base64 string. [^1]: https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-challenge Fix: duo-labs/webauthn#128
james-d-elliott
pushed a commit
to go-webauthn/webauthn
that referenced
this issue
Dec 17, 2022
This fixes issue with wrong encoding being used for the challenge. According to the specs[^1] the challenge should be base64 url-safe encoded. Until now, the package used std encoding which uses slightly different set of characters. This was reported in the linked issue and we also encountered the same issue when testing our implementation of webauthn e2e using github.com/descope/virtualwebauthn. The commit removes the custom type for challenge and instead passes around the challenge url-safe base64 encoded right from the point of creation. Because the string is fully valid it can be safely used in json as well as stored in redis or other possible storage implementations that might be used by the clients of the library. I tried to keep the tests as close to the original as possible. In some cases that required transforming the challenge back to bytes considering the previously used padding to be part of the bytes and then re-encoding into url-safe base64 string. [^1]: https://www.w3.org/TR/webauthn-2/#dom-collectedclientdata-challenge Fix: duo-labs/webauthn#128
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While working with this library and the Webauth.io Source I noticed a discrepancy in encoding type of the challenges.
On the one hand the
Challengeis defined as a urfsafe base64:in challenge.go.
The urfsafe encoding is used for session object.
On the other hand when send as a JSONResponse, the challenge is encoded to a standard base64 string, by the go json encoder.
(This can easily be checked by inspecting the server response on https://webauthn.io)
Is this discrepancy known and intended?
The text was updated successfully, but these errors were encountered: