I'm thinking whether the following way is a good way to completely and totally prevent ddos on my server. My idea is to use the same mechanism of cryptocurrency mining (bitcoin, with sha256 or any other hash) to prevent DDOS.

Note: I'm not suggesting to mine cryptocurrency per se. I'm suggesting to use the same mechanism to avoid Sybil attacks.

Why does idea look appealing to me? Because creating a mined hash is expensive, but verifying it is super-cheap. it costs only calculating a hash once.

What does mining mean, in a nutshell? It means that there's a specific chunk of data (say a session id, or a JWT token, that can be stored in the server in a performant NoSQL server), and the user (or the miner in cryptocurrency) has to create a hash that matches certain criteria. For example, if we use SHA256, we can define the difficulty as the required number of the leading zeros in the 256-bit resulting number from the hash. More zeros make the probability of finding that hash more difficult.

How does it work?: A user would take the session token (which is created by the server), and combine it with a nonce (number used once), and calculate the hash in their frontend (through WASM, or otherwise with javascript). Since the user cannot reverse-engineer SHA256, all he can do is keep changing the nonce again, and again and again, until he finds a nonce that creates a hash that satisfies the required difficulty.

enter image description here

The graph shows the probability of finding a block (finding the correct nonce) in Bitcoin, where the difficulty is chosen to make it 10 minutes. Changing the difficulty will shift this curve and change its width proportionally.

How long does it take the server to verify? Practically zero. Just calculate the hash once and ensure that it matches the given difficulty, and that authorizes the user to make any anonymous request. Notice that none of this requires authentication with usernames and password. This is all anonymous. Authenticated users don't need to do this as their credentials can be banned from the system. This is all for anonymous users (and possibly attackers).

The result: The user will have to calculate this hash with this difficulty before making any request to the server. Once the user succeeds, the mined authentication token can be stored in a cookie to be reused by the user. If the user fails to provide the requested hash, his connection request will be abruptly reject, and thus preventing a DDOS attack with sock-puppets.

ASIC resistance: Using SHA256 is not recommended because there's specialized hardware that can calculate it very fast, leading to a possible coordinated attack. There are hashes that are hard to print on hardware, such as Scrypt and Argon2.

Choosing the difficulty: The difficulty can be static (which I wouldn't recommend), or can be dynamic to change with the load on the network. When a high network load exists, the required difficulty is increased. This basically will act as a filter and protect the network during DDOS attack times, and never affect the users, as users normally wouldn't care to wait 10 seconds to create a session. In case of really high load, the users can either choose to compute the expensive nonce, or come back later. The hosting company also can decide whether an expansion of the infrastructure is required based on the difficulty chart over time.

Is this a sound plan to protect against DDOS on websocket and similar public protocols? I would like to implement this on my server.

EDIT: Just to be clear, this is not a silver bullet to all kinds of DDOS. But this prevents the users from manipulating the internal functionality of the server + makes it difficult to use the server functionality to exhaust bandwidth. I would be interested in knowing why this may or may not work, more than a summary on whether this is new or old.

  • 4
    It is not clear what kind of DDOS this should prevent. Given that the clients needs to get first a session token by the server you need to have already a working communication between client and server, i.e. the server needs to accept a request from the client first before your DDOS protection could even start. This means it cannot prevent a typical bandwidth DDOS. I've therefore marked the question as unclear. May 30, 2018 at 4:07
  • Sort of a CAPTHA for robots? Interesting idea for some uses, but I don't think it would stop a DOS.
    – dandavis
    May 30, 2018 at 4:49
  • Do you mean "Websocket" or "Web socket"? Those two concepts are quite different from each other, and it's not quite obvious from your question which exactly is interesting for you.
    – ximaera
    Jun 7, 2018 at 14:47
  • Yes, "your" algorithm might come in handy to prevent some types of DDoS. This algorithm is not "mining", the original bitcoin paper even references it, its called "hashcash", which originally wasn't listed as a source. So, are you talking about "hashcash"?
    – Souza
    Oct 26, 2021 at 22:28

2 Answers 2


TL;DR: This is not a solution against typical DDOS. It might be a protection against some very application-specific DOS.

Taking away all the mining stuff your idea essentially means that the client connects to a server to get some hard-to-solve task and later comes back to present the easy-to-verify solution for this task.

The problem with this approach is that the client needs to connect to the server first and that the server needs to be able to reply with a task to the client. This means your idea cannot protect against the most common bandwidth oriented DDOS attacks which simply send more traffic than upstream systems or the server can deal with. Neither will it help against simple DDOS attacks which try to exhaust resources of the server itself, i.e. things like SYN flooding or Slowloris.

It can actually help against attacks which are targeted at later stages of the processing, i.e. attacks specific to the application. But it isn't actually a new idea in this area, it is essentially just another Proof of Work System as they have been known for many years.

  • 1
    Correct. I don't think my solution will be a silver bullet, but it could help against exhausting internal resources (and bandwidth in some cases). Please check the edit. May 30, 2018 at 10:23
  • 1
    @TheQuantumPhysicist: it could help to protect some compute-intensiv resources inside your application, i.e. require some work by the client so that the server is actually willing to do some work too. But I would not consider it a protection against general DDOS, only a protection against some very application specific DOS (no distributed needed for this). May 30, 2018 at 10:36
  • But a single bad actor can have their IP address banned temporarily after a few attempts, right? And hence the "distributed" (and hence also the Sybil attack). May 30, 2018 at 10:39
  • @TheQuantumPhysicist: normally compute-expensive processes are performed on authenticated users, so you would limit the max concurrent logins and on bad behavior ban the account, not the IP. ddos typically does something like grabbing a huge download or performing a complex search on naive backends.
    – dandavis
    May 30, 2018 at 19:52
  • @TheQuantumPhysicist banning an IP from your server doesn't stop them asking to log in, it just stops your server from processing their request. If they are asking to log in a hundred million times per second, ignoring them won't free up your Internet connection. Oct 26, 2021 at 8:46

So, we're speaking now of application layer DDoS attacks only.

What you propose is known for long as proof of work. Numerous attempts were made to put this general approach in against application layer DDoS attacks, with little success though.

Basically, either the challenge that you introduce for a suspected bot would be simple and short enough to be finished in a-couple-to-a-dozen of seconds, or it will take a really long time.

  1. In the first case, a typical botnet is believed to have thousands of machines under control, and the attacker gets all the computational resources on those machines, more or less, for free. Forcing all those machines into computing something just once for about 10 seconds isn't going to prevent an attack.

  2. In the other scenario, you'd probably still lose almost all the customers of a, say, Web site because a legitimate user will rarely wait for minutes for your pages to load. Actually, popular Web sites are now fighting for milliseconds of page load times, introducing numerous techniques (CDN, 0-RTT and others) exactly for that purpose. So though formally your server won't be flooded with malicious requests, the end result would be virtually the same.

For some specific applications, in theory, there could be some reason to implement a technique similar to what you're thinking of. But for an arbitrary Web site, unfortunately, it's not going to work well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .