A captcha is a challenge in order to prove that there is a human behind an action (requisition) within the system.

In general, the stateful procedure of a captcha is to generate and store a secret on the server and provide the user with a means by which only humans could discover the secret. When the user performs an action, the system checks whether the secret has been properly discovered.

Captcha based on token

If the idea is not to store anything on the server, then it might be possible to get a secret value based on variables that do not need storage.

The most common method is using tokens, that is, a secret number based on the current date and time. To differentiate between the various users of a system, an algorithm can temper the number with some other random value that is unique per user or per user, thus generating a secret code . If there is no user registration, seasoning can be randomly generated and written to a cookie or hidden field on the form.

The secret code would be presented to the user as a conventional captcha image.

Finally, when the user submits the form, the server will receive the code entered by the user and the seasoning via cookie or hidden field. Your code should recalculate the secret code based on the token and the seasoning now received in the request and then validate if the code provided by the user is equal to the * secret code * regenerated by the algorithm.

Random challenges set

Another way to challenge the user without maintaining a state is to define a set of challenges and select one among them.

For example, some sites adopt a puzzle or puzzle as captcha . The user needs to assemble an image composed of several pieces.

In this case, the server could select which challenge will be applied based on some feature of the user and perhaps the current timestamp (date and time), so that the same user can not reuse the captcha later, not two users receive the same challenge while accessing the form simultaneously.

A selected challenge identifier can be stored encrypted in a = cookie or else the selection algorithm can be run again on the next request to verify that captcha sent by user is the same as captcha previously selected.

After all these phases, just check if the result of the challenge (for example, the positions of the pieces of the image) are in place.

Considerations on approaches stateless

Both approaches are based on the current date and time, so they will have limited validity for all users.

The algorithm must be smart not to check the exact time, that is, considering minutes and seconds, but consider that a token is valid within a given time window.

Timestamp is important to prevent a malicious user from replicating the challenge result to multiple subsequent requests.

However, within the token time window, it would still be possible for a user to reuse the challenge result. So this solution is not totally fail-safe.

How about being stateful on some level?

Let's review the concepts of statefull and stateless . When we use these terms, we usually mean using a session for the user in memory or not.

However, I do not know of any real application that is 100% stateless , because even if each request is not aware of the previous ones, at some level information will be loaded from somewhere and persisted in some database or cache.

A workaround that is stateless in the sense that it does not have session, but statefull in the sense that it stores captcha , would create a data structure (table or cache in memory) that has entries for the captchas generated.

A captchas table, just stick with an example would be a great way out. When a page was opened, the system would add a new entry with captcha information and a hash identifier. The user would receive this hash and, when submitting the challenge, the system would be able to check if captcha exists, if it was not used and is still valid.