WebAuthn Challenge Token Flow for Stateless Login Flood Protection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The WebAuthn/FIDO2 Username-less authentication protocol is vulnerable to denial-of-service attacks and storage overload due to excessive login requests, which can exhaust server resources and prevent legitimate requests from being processed.
Innovation Solution
A revised protocol message format that uses a Challenge JWE Token encapsulating the Challenge and its contextual data, with an expiry period, eliminating the need for temporary storage during the Start Login phase, and includes anti-replay and rate-limiting mechanisms to manage authentication requests effectively.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the server stores challenges temporarily during the Start Login phase, then the authentication protocol can verify challenge responses, but the server storage becomes overloaded and vulnerable to DoS attacks
Solution Approach 1:
The patent extracts the challenge storage function from the server by moving challenges to the client-side storage. The server no longer stores challenges temporarily, instead receiving them from the client and verifying responses without retaining the challenge data itself, thus eliminating the storage overload vulnerability.
Solution Approach 2:
The patent introduces the client as an intermediary that handles challenge storage and management. The client receives challenges from the server, stores them locally, and returns them during the authentication process, allowing the server to remain stateless and avoid storage-related DoS attacks.
2Reliability
If the server stores challenge contextual data, then the server can verify authentication responses, but the server resources are over-burdened and legitimate requests cannot be processed
Solution Approach 1:
The patent extracts challenge contextual data storage from the server and places it in the client. The server receives only the challenge response from the client, not the contextual data, allowing the server to verify authentication responses without maintaining storage-intensive contextual information.
Solution Approach 2:
The client performs self-service by storing and managing its own challenge contextual data. The client autonomously handles challenge reception, storage, and response verification, freeing the server from the burden of maintaining and processing challenge contextual data.
3Reliability
If the server temporarily stores challenges during Start Login phase, then the server can match challenges with responses, but the server becomes vulnerable to replay attacks and storage exhaustion
Solution Approach 1:
The patent extracts challenge storage from the server environment and places it in the client environment. The server receives challenges from the client and verifies responses without storing the challenges itself, thereby eliminating the storage persistence that enables replay attacks.
Solution Approach 2:
The patent implements a stateless challenge-response mechanism where the server rapidly processes authentication requests without retaining challenge data. The server receives a challenge from the client, verifies the response immediately, and discards the challenge without storage, preventing replay attacks by not persisting the challenge for later reuse.
Data Source
Figure 1~2A
Figure 2B~2C
Figure 2D
AI summary
Provided is a system and method to mitigate the risk of flooding and overburdening of resources associated with passwordless authentication login requests, and more specifically, prevent storage overload from excessive usernameless login requests. In a first section, emphasis is on the Challenge and its contextual data, which are no longer stored in Data Storage during the Start Login phase. In a second section, the Challenge state is recovered from the client response in the Verify Credential phase. In a third section, the Challenge will be checked whether it has been consumed to mitigate anti-replay attacks. In a fourth section, steps are taken to guard against a flood of legitimate authentications, more specifically, to protect against an unusual number of good authentication requests from a single user. Other embodiments disclosed.