SKFS 4.15.1

Fixes and Changes in SKFS 4.15.1

#	Explanation
RFE-263	Support for Related Origin Requests (ROR) added for registration. With the release of SKFS 4.14, support for Related Origins Request (ROR) was introduced (RFE-245) but the support was restricted to only authentication/assertion operations. With SKFS 4.15.1 the support for ROR has been extended for registration operations as well. The same configurations will work for both operations and if ROR has been enabled for authentication then no changes will be required on the SKFS. Read more about ROR here.
BUG-124	Fix bug where SKFS treats non-discoverable credential authentication flows (where a username must be specified as part of the login process) as an anonymous, discoverable credential authentication flow. Consequently, if the calling application ignores the username in the SKFS response after a successful authentication, it allows unauthorized users to take-over an account of another registered user in SKFS Discoverable Credentials are a convenient feature of the W3C WebAuthn API that enables the relying party (RP) web application to allow users to authenticate without specifying a username – you can see a demonstration of this capability at https://demo.strongkey.com. This requires that the web application be designed to support the feature, and request a challenge from SKFS without specifying a username. When SKFS returns an “anonymous” challenge, and if a matching FIDO credential is “discovered” on the user’s device, the device processes the challenge to generate a FIDO/WebAuthn assertion. The assertion with its digital signature is returned to SKFS, where it is parsed and searched within the SKFS database to identify the credential that signed the challenge, and the public key to verify the assertion’s digital signature. If successfully verified, SKFS returns a response with the authenticated user’s username within the body of the response. Support for discoverable credential authentication flows was introduced in SKFS in version 4.10. Since SKFS responds to an anonymous preauthenticate web service request in a discoverable credential authentication flow, it has to rely on the returned assertion to identify the user, locate and use their public key from the SKFS database, verify the assertion and finally, return a response identifying the authenticated user to the application. This is in contrast to a “named credential” authentication flow where the application specifies the username to SKFS, and SKFS scopes (restricts) the challenge to only the public keys registered by that user for verification. Bug 124 failed to distinguish between these two flows during the authenticate phase. As a result, it enabled “Bob” to request a challenge from SKFS for “Alice”, replace Alice’s credential ID for Bob’s in the challenge, and use the challenge with his own device/authenticator to generate an assertion and return it to SKFS. Since the bug did not distinguish between non-discoverable credential authentication flows from named credential authentication flows, SKFS processed Bob’s assertion successfully and returned an HTTP 200 OK to the calling application albeit with Bob’s username in the JSON body of the response. An application not paying attention to the authenticated username in the response will allow Bob to login with Alice’s account privileges. This bug has been fixed in SKFS 4.15.1 to make the authentication distinction. Additionally, two (2) new error codes have been added to make the distinction: SKFS-ERR-7003 will indicate a failure to verify a discoverable credential authentication flow, while SKFS-ERR-7004 will indicate a failure to verify a named credential authentication flow. During successful authentications, in both cases, SKFS returns the authenticated user’s username in the JSON body of the response. Applications are recommended to pay attention to the fact that they should match the username in the response to the authenticate web service with the username they specified in the preauthenticate request for that user, to ensure they are the same value. All releases between 4.10 and 4.15 are affected by this bug. Relying party companies using SKFS are strongly recommended to version 4.15.1 as soon as possible. Please contact StrongKey Support if you have any questions. NOTE: StrongKey acknowledges and thanks Natalia Trojanowska-Korepta of Securing in Krakow, Poland, for bringing this vulnerability to our attention on January 24, 2025. Her/Securing’s efforts to responsibly disclose this vulnerability to us so we may address the problem before public disclosure is sincerely appreciated. Thank you, Natalia and Securing!

Explanation

RFE-263

Support for Related Origin Requests (ROR) added for registration.

With the release of SKFS 4.14, support for Related Origins Request (ROR) was introduced (RFE-245) but the support was restricted to only authentication/assertion operations. With SKFS 4.15.1 the support for ROR has been extended for registration operations as well. The same configurations will work for both operations and if ROR has been enabled for authentication then no changes will be required on the SKFS. Read more about ROR here.

BUG-124

Fix bug where SKFS treats non-discoverable credential authentication flows (where a username must be specified as part of the login process) as an anonymous, discoverable credential authentication flow. Consequently, if the calling application ignores the username in the SKFS response after a successful authentication, it allows unauthorized users to take-over an account of another registered user in SKFS

Discoverable Credentials are a convenient feature of the W3C WebAuthn API that enables the relying party (RP) web application to allow users to authenticate without specifying a username – you can see a demonstration of this capability at https://demo.strongkey.com.

This requires that the web application be designed to support the feature, and request a challenge from SKFS without specifying a username. When SKFS returns an “anonymous” challenge, and if a matching FIDO credential is “discovered” on the user’s device, the device processes the challenge to generate a FIDO/WebAuthn assertion. The assertion with its digital signature is returned to SKFS, where it is parsed and searched within the SKFS database to identify the credential that signed the challenge, and the public key to verify the assertion’s digital signature. If successfully verified, SKFS returns a response with the authenticated user’s username within the body of the response. Support for discoverable credential authentication flows was introduced in SKFS in version 4.10.

Since SKFS responds to an anonymous preauthenticate web service request in a discoverable credential authentication flow, it has to rely on the returned assertion to identify the user, locate and use their public key from the SKFS database, verify the assertion and finally, return a response identifying the authenticated user to the application. This is in contrast to a “named credential” authentication flow where the application specifies the username to SKFS, and SKFS scopes (restricts) the challenge to only the public keys registered by that user for verification.

Bug 124 failed to distinguish between these two flows during the authenticate phase. As a result, it enabled “Bob” to request a challenge from SKFS for “Alice”, replace Alice’s credential ID for Bob’s in the challenge, and use the challenge with his own device/authenticator to generate an assertion and return it to SKFS. Since the bug did not distinguish between non-discoverable credential authentication flows from named credential authentication flows, SKFS processed Bob’s assertion successfully and returned an HTTP 200 OK to the calling application albeit with Bob’s username in the JSON body of the response. An application not paying attention to the authenticated username in the response will allow Bob to login with Alice’s account privileges.

This bug has been fixed in SKFS 4.15.1 to make the authentication distinction. Additionally, two (2) new error codes have been added to make the distinction: SKFS-ERR-7003 will indicate a failure to verify a discoverable credential authentication flow, while SKFS-ERR-7004 will indicate a failure to verify a named credential authentication flow. During successful authentications, in both cases, SKFS returns the authenticated user’s username in the JSON body of the response. Applications are recommended to pay attention to the fact that they should match the username in the response to the authenticate web service with the username they specified in the preauthenticate request for that user, to ensure they are the same value.

All releases between 4.10 and 4.15 are affected by this bug. Relying party companies using SKFS are strongly recommended to version 4.15.1 as soon as possible. Please contact StrongKey Support if you have any questions.

NOTE: StrongKey acknowledges and thanks Natalia Trojanowska-Korepta of Securing in Krakow, Poland, for bringing this vulnerability to our attention on January 24, 2025. Her/Securing’s efforts to responsibly disclose this vulnerability to us so we may address the problem before public disclosure is sincerely appreciated. Thank you, Natalia and Securing!