Stanko K.R.
1983014be6
The cookie approach seems like the more secure aproach because it ties the authentication or registration attempt to the user's browser session, but it doesn't work reliably on Chrome for Windows. Also, a simila problem pops up on Chrome for Linux if the session is used instead of a separate cookie. It looks like the browser doesn't propagate the state change through fast enough which results in some requests contaiining the new/updated cookie, and others don't, which results in sporadic failures. Since we use a signed and expiring challange we still get protection from replay attacks and tampering which enables us to omit the cookie entierly and rely on the challange's signature to prove expiration and authenticity. The only thing we lose is the ability to tie and attemp to a single browser session. See: https://github.com/w3c/webauthn/wiki/Explainer:-WebAuthn-challengeURL which proposes to add the same challange fetching logic as part of the standard See: https://github.com/w3c/webauthn/issues/1856 which discusses issues that arise from having expiring challanges (which the spec recommends) See: https://github.com/OneUptime/oneuptime/security/advisories/GHSA-gjjc-pcwp-c74m which is an explot that can happen if the server isn't able to verify the authenticity of challanges that are sent outside of a cookie
25 lines
629 B
Ruby
25 lines
629 B
Ruby
require "test_helper"
|
|
|
|
class My::PasskeyChallengesControllerTest < ActionDispatch::IntegrationTest
|
|
test "returns a fresh challenge" do
|
|
untenanted do
|
|
post my_passkey_challenge_url
|
|
|
|
assert_response :success
|
|
assert_not_nil response.parsed_body["challenge"]
|
|
end
|
|
end
|
|
|
|
test "returns a different challenge each time" do
|
|
untenanted do
|
|
post my_passkey_challenge_url
|
|
first_challenge = response.parsed_body["challenge"]
|
|
|
|
post my_passkey_challenge_url
|
|
second_challenge = response.parsed_body["challenge"]
|
|
|
|
assert_not_equal first_challenge, second_challenge
|
|
end
|
|
end
|
|
end
|