Wondering why Altcha is a killer captcha solution? Read about my captcha journey here!

Why use a captcha solution?

The purpose of a captcha solution is to make it difficult or costly for bots to perform a task, while keeping it easy for humans to perform the same task.

Choosing Altcha

In a project, I first looked at Friendly Captcha since a colleague was familiar with it. However, it comes with some drawbacks:

• I initially was told that Friendly Captcha would cost only €9 per month. But if you want your requests to stay within the EU, you actually need to pay for the Advanced tier, which is €200 per month. While not a huge expense, it’s still a difference. In this project, keeping the data within the EU was something I valued.
• Because Friendly Captcha isn’t free, using it would require a company approval. It would be much simpler to use a free alternative and avoid all that headache and administration.
• Friendly Captcha is only available as a cloud service. Ideally, in this project, I’d prefer a solution that can run on-premises, so neither the browser nor our server needs to communicate with an external service. That way, no data at all is sent to a third party. Even though Friendly Captcha says they are “privacy-friendly,” you still have to trust them to handle your data properly.

Instead, I found Altcha. It’s free, open source (MIT license), and can be self-hosted. I actually like the technology behind Friendly Captcha, which is proof-of-work, and Altcha uses the same approach.

Advantages of Altcha

• Uses proof-of-work instead of visual puzzles, making it simple and user-friendly.
• Built with accessibility in mind and meets WCAG 2.2.
• No tracking or cookies, making it a strong choice from a GDPR perspective.
• Technically lightweight and easy to understand.
• Built-in support for 48 different languages.
• Free, so I don’t need to go through procurement.
• Open source, so I can review the code myself.

The technology behind Altcha: proof-of-work

Proof-of-work is a technology where users “pay” with computing power by solving a computationally expensive problem and sending the answer along with their message. The idea is that solving the problem is hard, but verifying the solution is easy. An early application of proof-of-work was Hashcash, which was invented to reduce email spam. The sender solves a computationally difficult problem and includes the solution with their email; the receiver can easily check that work was done. For ordinary users, this takes almost no time, but for someone sending mass spam, the computing cost quickly adds up. Proof-of-work is also used in blockchains, such as Bitcoin.

With Altcha, the server generates a problem and sends it to the user’s browser. When the user clicks the “I am not a robot” checkbox, the browser starts working to find the correct solution. When the user submits the form, the answer is sent to the server, which verifies the solution. This proves that the user has performed the required work, making it expensive to submit a large number of forms automatically.

Technically, Altcha works like this: The server generates a random number and a salt. The number and salt are added together and hashed with SHA256. The user receives the hash, the salt, and the range the random number lies within. The user’s browser then searches for the number that, when added to the salt, produces the same SHA256 hash. The larger the range, the longer it takes on average to find the solution. Additionally, the server signs the problem with HMAC to ensure that it can later verify that the solution is to a problem it generated, and a timestamp is added to the salt to make sure solutions can’t be kept and used at a later time. You can read more about the technology in their documentation.

My implementation of Altcha

In the implementation I did, I chose to increase the difficulty if a user requests a new problem multiple times in quick succession. Increasing the difficulty means that the random number is selected from a larger range, making the problem take longer on average to solve.

• The first time, the random number is between 25,000 and 50,000. The Altcha browser widget always starts searching from 0, so at most it needs to check 50,000 numbers to find the right one.
• If the user clicks “I am not a robot” a second time within 30 seconds, the difficulty doubles: the range becomes 50,000 - 100,000.
• A third time within 30 seconds, it doubles again: 100,000 - 200,000.
• This doubling can happen up to 8 times, giving a maximum multiplier of 2^8 = 256, so the range reaches at max 6,400,000 to 12,800,000.
• If the user waits more than 30 seconds, the difficulty level is maintained.
• If the user waits more than 2 minutes, the difficulty resets to the original level.

In my implementation of Altcha, I utilized the following two parts:

• The frontend widget shown to the user in the browser, available on GitHub at altcha-org/altcha, which is very popular.
• The backend of the application I’m working with is built with C#/.NET, so for generating problems and verifying solutions I found a NuGet package, on GitHub it’s available at ixnas/altcha-dotnet. It’s not as widely used though, but I read through the code and it looks solid. Overall, Altcha is technically simple, so it’s not hard to understand how it works.

Considerations for the future

Altcha is technically a quite simple solution, so I’ll try it out in this project and see if it provides sufficient protection. Until I know, I don’t think it makes sense to spend time setting up something more advanced if it’s not needed.

Altcha also offers a more advanced service called Altcha Sentinel. It’s a commercial product that can be run on-premises. It uses machine learning and pattern recognition to detect bots. Suspicious users are flagged and required to solve a visual challenge:

However, Altcha Sentinel is closed source, costs money, and is more difficult to install. But it’s good to know this option exists if I find that I need it.

If Altcha isn’t enough, I may also revisit Friendly Captcha or other cloud-based solutions. However, I would like to not send any data to a third party. But if there is no reliable on-premises solution, I may have to consider cloud options. However, for this project, my preference is to first evaluate solutions that can be run on-premises.

It’s also worth remembering that no captcha solution is 100% reliable. It’s a constant game of cat and mouse, as bad actors are always trying to bypass captchas. Furthermore, there’s no way to prevent real people from submitting spam or abusing the service; in that case, it’s probably better to use electronic identification as protection and/or develop better internal tools to delete junk.