-2

We are looking to run cryptographic challenge as a required form field to slow down brute force (we cannot filter by source IP or any other common element).

Every time the client send the form, a CPU intensive challenge will have to be solved (it should take no more than 2 seconds to solve it) would be acceptable for clients (Captcha are not a valid option unfortunately as the challenge need to be completely passive/automated).

Do you know any kind of algorithm that would fit this use-case ? The challenge need to be unique and should not be reusable to make sure every single sent form will have to solve its own challenge.

Would asking the browser to brute force a sha+salt hash and send the original string to the server an option ? ( I would give the client the length of the string with the payload )

Kedare
  • 1,289
  • 16
  • 31

1 Answers1

1

You are looking for a JS Challenge like CloudFlare JavaScript anti-bot challenges.

I personally experimented that technique as it looked a candidate good way to slow down brute force attacks.

Remember that there are solutions like this https://github.com/evyatarmeged/Humanoid to bypass challenges such as the Cloudflare JS challenge above mentioned.

One issue I ran into is that a decent challenge for a Desktop PC is often a pretty hard challenge for a mobile device of 4 yrs ago. This means that what for a desktop PC can be a 2 sec challenge, for an old mobile device can be a 10 seconds challenge. For this reason we gave up on this solution.

Why asking them to solve a cryptographic challenge? Maybe serve a value and ask back for that value after 3 seconds, to consider the form valid.

There are already solutions. In the project I mentioned above, we used AntiBot Cloud (https://antibot.cloud/en.html).

With a quick search I came across also to:

70ny
  • 748
  • 1
  • 7
  • 22
  • *...Maybe serve a value and ask back for that value after 3 seconds, to consider the form valid...* That won't work. Pipelining and parallelism can overcome that. – President James K. Polk Nov 04 '20 at 21:42
  • 1
    okay, cause you cannot filter by IP address. So yes, memory intensive challenges it's the only one way. Why not asking for a bcrypt challenge? Maybe using this package https://www.npmjs.com/package/bcryptjs – 70ny Nov 04 '20 at 22:12
  • I though also about giving the client a sha hash, the salt and the response length, and having to bruteforce the hash on the client side and send the original string back to the server to be able to validate the form. – Kedare Nov 05 '20 at 08:45
  • 1
    it can be an option. bcrypt, therefore, is not bruteforce, but gives you more control over the set of operations required to obtained the final hash, being it a combination of memory needed and CPU power. I though about other alternatives to request a client-side challenge, but so far I was not able to find a better one than this – 70ny Nov 06 '20 at 08:22
  • How would you integrate bcrypt in this workflow ? Beause if I need to compute it also on tbe backend for every request (so as much as the frontend) it will take too much CPU for us. – Kedare Nov 06 '20 at 13:15
  • good question @Kedare , I'm enjoying this talk. If you would like to avoid that, you should pre-populate your DB with a good amount of pre-evalutaed hashes. Let's say 100k? Depends on the trade-off you'd like to reach. Store them the cheapest way you can think of. You can then plan to update the oldest one, or keep a count and update those that have been served more than X times. The idea is that you use little amount of your CPU power units every day to store what you will need to block a big attack. – 70ny Nov 06 '20 at 22:48