-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
explain challenge's security importance and use in both registration and authentication operations #404
Comments
#88 (comment) proposes a way to write these MUSTs, which constrain the behavior of the server rather than the browser or authenticator. |
wrt the examples (aka "sample scenarios"):
perhaps ought to be:
this is applicable to all the examples in this section. |
Uint8Array.from(window.atob("PGifxAoBwCkWkm4b1CiIl5otCphiIh6MijdjbWFjomA="), c=>c.charCodeAt(0)) would work. |
cool, thx @jyasskin -- hm, I am gonna have to dig around and figger out the details on how this "mapFn" gizmothingee works: |
Did y'all consider requiring the value to be a base64-encoded |
no, we did not think of that -- yes, I'm thinking your suggestion is the way to go -- thanks! |
@equalsJeffH @mikewest Are you proposing we change the challenge to be a DOMString? @vijaybh @leshi I remembered the reason why challenge is base64url encoding is partially because of CTAP, correct? |
I'm suggesting that, yes. Coupled with changes to the algorithms which would throw a
For clarity, the |
The challenge was originally a base64 encoded DOMString. We changed it to BufferSource in response to TAG feedback. See #61. |
@slightlyoff: How do you feel about the |
Assigning this to @equalsJeffH because he proposed the issue. |
I'm fine with working on this issue. we still would like some input from @slightlyoff it seems. |
Re: #404 (comment) and #404 (comment), let's not hold their hands about how to get the octets from their back-end to WebAuthn. I suggest this compromise:
And in the Security Considerations section, add:
|
LGTM - thanks!! |
"and the client's responses' challenge fields" - bit of a mouthful. "and the challenge in the client's response MUST..." ? |
Fix #404 - Add a Security Consideration for Cryptographic Challenges
need to expand the explanation of "challenge" in the spec -- challenge is used in both regstn and authn protocol runs and has security implications. It MUST NOT be created on the client-side -- rather, it MUST be randomly created on the server-side with very low probability of collisions, and verified upon receipt back from the client and end of protocol run in order to provide protocol-run round-trip integrity. this needs to be explained in the spec and the code in the examples altered to reflect this -- especially since developers will simply cut'n'paste our examples! :-P
The text was updated successfully, but these errors were encountered: