Comments (2)
To add to this, the limited verification algorithm doesn't even rely on UTF-8 decode or any other decoding. This means the whole BOM stripping isn't even applicable to it. Either steps need to be added to both the serialization and limited verification algorithms or UTF-8 decode should not be required. If BOM stripping is necessary, then in order for the limited verification algorithm to be consistent, step 2 should be added to the serialization section:
- Let result be an empty byte string.
- Optionally append 0xefbbbf (i.e., U+FEFF) to result.
- Append 0x7b2274797065223a (
{"type":
) to result.
Similarly steps 3–5 should be added to the limited verification algorithm:
- Let expected be an empty byte string.
- If clientDataJSON is not at least 3 bytes long, fail.
- Let bom be the first three bytes of clientDataJSON.
- If bom is 0xefbbbf (i.e., U+FEFF), then append 0xefbbbf to expected.
- Append 0x7b2274797065223a (
{"type":
) to expected.
from webauthn.
I hope this is not misconstrued as a "rant", but I think the real problem is the serialization algorithm itself. It is far too strict. The fact this algorithm is technically required means many clients or user agents will likely accidentally not conform to the spec since they likely use an actual JSON library which will likely not guarantee the order of fields, not guarantee unnecessary whitespace is not used, etc. The spec should be written such that clients and user agents have an easier time to conform to the spec and not a harder time so long as there is not a reduction in security.
The existence of the serialization algorithm seems to violate two big goals of WebAuthn: consistency among RPs in order to mitigate risks related to a fragmented ecosystem that causes users to turn away from WebAuthn altogether and the spec as a web standard.
Personally, I'm sympathetic to libraries that don't kowtow to non-conforming clients/usage; and as an RP writer, I find it hard to "forgive" these non-conforming clients. It is obvious that allowing any conforming JSON, even if it violates the spec, is not a "security issue"; but that creates a slippery slope. While Postel's law is still common, this can cause issues if one is not careful. The purpose of a spec should be to state what is necessary and not rely on implementors to use their best judgment when the spec can, and in this case seemingly should, be violated.
The existence of the serialization algorithm and the related limited verification algorithm is a not-so-subtle way to help non-web platforms—as confirmed by #2102 (comment). When questions come up about native applications and other non-web platforms, the usual (and appropriate) response is something to the effect of "WebAuthn is only a web standard, so concerns with native applications are not applicable"; yet here we have a required algorithm that is designed for non-web platforms.
Ideally the solution would be to state that clients/user agents can send any payload that conforms to RFC 8259 (or whatever formal standard you wish to cite), and they MAY optionally begin the payload with U+FEFF. Then at most a commentary note stating that they SHOULD conform to the serialization algorithm.
With above, an RP writer that relies on the limited verification algorithm cannot claim to be "WebAuthn-conforming" since conforming clients/user agents are allowed to send any JSON (and optional BOM).
Until then, the spec should at least be consistent and ensure the required serialization algorithm and the limited verification algorithm align with other areas of the standard that state BOM stripping MUST occur; because as of now, it's a bizarre requirement to allow payloads that strictly speaking should not be possible.
from webauthn.
Related Issues (20)
- CredentialCreationOptions/mediation not yet defined in CredMan HOT 1
- Authenticator Attestation Response's [[transports]] should be an attribute rather than an internal slot. HOT 4
- Align the order of fields in PublicKeyCredentialDescriptorJSON with PublicKeyCredentialDescriptor HOT 2
- Dictionary members should be ordered lexicographically per Web IDL Standard HOT 3
- Allow conditional mediation flow without username or password field, I.E. from button press HOT 4
- Add support for hinting at verbiage other than "sign in" during authentication HOT 5
- Add support for IDNs and display domain names in Unicode for a more user friendly UX HOT 4
- Add examples for PRF extension HOT 3
- Passkey - Disable authentication with another device HOT 3
- Proposal for password-only authentication using ES256 HOT 10
- [[Create]] should not access the global object directly HOT 1
- Define `TypeError` behavior during `.get()` HOT 2
- Return more nuanced errors HOT 3
- Does Related Origins introduce a need for "Related RP IDs" support in `.get()`? HOT 1
- CollectedClientData fields are not ordered correctly and crossOrigin should be required
- Add `topOrigin` to the limited verification algorithm HOT 2
- Use URI instead of URL for related origins HOT 2
- Add `publicKey` and `publicKeyAlgorithm` to `AuthenticatorAssertionResponseJSON` HOT 3
- Make `AuthenticatorAttestationResponseJSON.publicKeyAlgorithm` optional HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webauthn.