Passkey Reference Implementation

[authcompanion]

Hi SimpleWebAuthn community,

Sharing here my reference implementation for the passwordless registration/login flow - hope this gives you good ideas and makes the adoption of SimpleWebAuthn easier for you.

• APIs for webauthn
• UIs for webauthn (specifically login and registration.html)

main project link: https://github.com/authcompanion/authcompanion2

[MasterKale]

A very interesting submission! Thank you! The UI looks great, I like the simple "Passkey" button with recognizable iconography.

There's something that immediately stood out to me, though, as functionality that you should consider tweaking for better security:

When you generate your login options you don't persist the challenge anywhere on the back end:

https://github.com/authcompanion/authcompanion2/blob/main/services/webAuthn/loginOptions.js#L20

Then, when you verify the response, you use the challenge set in the header by the front end:

https://github.com/authcompanion/authcompanion2/blob/main/services/webAuthn/loginVerification.js#L16

This goes against the spec's recommendation that an RP generate and store the challenge on the back end and only allow challenges to be used once, even if the verification fails:

https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges

As a cryptographic protocol, Web Authentication is dependent upon randomized challenges to avoid replay attacks. Therefore, the values of both PublicKeyCredentialCreationOptions.challenge and PublicKeyCredentialRequestOptions.challenge MUST be randomly generated by Relying Parties in an environment they trust (e.g., on the server-side), and the returned challenge value in the client’s response MUST match what was generated. This SHOULD be done in a fashion that does not rely upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily until the operation is complete. Tolerating a mismatch will compromise the security of the protocol.

I'd recommend tweaking your implementation to, for example, set a session ID in an HTTP-only cookie on page load and use that to track which challenge should be used for verification when the authenticator response is passed back. Right now an attacker can simply spam responses at you with a challenge of their creation and your server would naively verify with the attacker-provided challenge. You want the auth logic to get to the point where only a challenge you know about can be signed over.

[authcompanion]

@MasterKale thank you for taking the time out of your schedule to look over the implementation and for providing this feedback; it means a lot to have your review.

This is an obvious security improvement that was neglected and I've taken steps to improve the implementation based on your suggestion in 3.0.0-beta.2, specifically this commit.