CAPTCHA in stateless API

Question

How to use CAPTCHA in a stateless application? If not, what is the alternative to this?

Answer 1

Implementing a CAPTCHA service

Create a CAPTCHA service with the following operations:

• Create a CAPTCHA. Returns a created CAPTCHA id and a CAPTCHA image.
• Answer a CAPTCHA. Receives a CAPTCHA id and text that matches the CAPTCHA text. Responds true or false.

And observe the following restrictions:

• Once created, a CAPTCHA has a short shelf life (ex: 5 minutes). The CAPTCHA response method should only work for CAPTCHAS that are within the expiration date.
• The method of answering CAPTCHA must necessarily destroy it, so that CAPTCHA cannot be answered more than once.
• No method to search CAPTCHAS already created.
• The implementation of CAPTCHA must necessarily be stateful. However, the server-side state is volatile, and can be kept in memory rather than kept in a database, although there are some advantages to putting yourself in the database.

Fully stateless CAPTCHA service is possible?

I believe not. Because that would mean sending the CAPTCHA response along with CAPTCHA itself.

But what if the answer is encrypted inside a token with some strong encryption algorithm that can only be decrypted on the server?

In this case it would still be possible to reuse CAPTCHAS by repeatedly sending the same token. Someone could always reuse the same CAPTCHA already solved.

And if in the encrypted token I also included the expiration date of CAPTCHA?

Still it would be possible to try to answer a CAPTCHA more than once.

And if I have a service nonce maintain a table of objects that can only be used once and I use this nonce service in my CAPTCHA service?

Then you reduce the problem to "developing a stateless nonce service". Your CAPTCHA service alone will not maintain status on the server, it will only change this state to another place that is also server-side (the nonce service). The CAPTCHA service I gave above is simpler, but on the other hand what uses nonce is more modular, since it becomes easier to reuse the component of a nonce for other things that need it and the control of server-side states is reduced and simplified. Also note that the expiry date of the nonce would be more convenient to be controlled by the nonce service itself in this case.

It is possible to have a stateless nonce service?

I don’t think so. If you figure out a way to do this (and I doubt it exists) then you will be able to implement a fully stateless CAPTCHA service.

Answer 2

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

In general, the procedure stateful 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 overdraft.

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 require storage.

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

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

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 (date and time) and the seasoning now received in the request and then validate if the code provided by the user is equal to * secret code* governed by the algorithm.

Set of random challenges

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

For example, some websites adopt a kind of jigsaw puzzle or puzzle like 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 timestamp (current date and time), so that the same user cannot reuse captcha later, nor two users receive the same challenge when 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 check whether the captcha sent by the user is the same captcha previously selected.

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

Considerations on the approaches stateless

Both approaches are based on 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.

The timestamp is important to prevent a malicious user from replicating the challenge result in multiple later requests.

However, within the time window of token, it would still be possible for a user to repurpose the outcome of the challenge. Therefore 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 refer to using a session for the user in memory or not.

However, I don’t know any real application that is 100% stateless, because even if each request is unaware of the above, at some level information will be uploaded from somewhere and persisted in some database or cache.

An alternative solution that is stateless in the sense that it has no sitting, but statefull in the sense that it stores the captcha, would create a data structure (table or cache in memory) that has entries for the generated Captchas.

A table of Captchas, just stick with an example, it would be a great output. When a page was opened, the system would add a new entry with information from captcha and a hash identifier. The user would receive this hash and, by sending the challenge, the system would be able to verify whether the captcha exists, if not used and is still valid.