Qu’est-ce que le Proof-of-Work (PoW) qui rend les attaques et le spam coûteux ?

Comparatif des meilleurs CAPTCHA pour WordPress en 2026

WordPress7 minassistouest.fr

Protégez votre site WordPress des spams et bots malveillants grâce à notre sélection des meilleurs CAPTCHA gratuits, respectueux de la vie privée et simples à intégrer.

Pour un visiteur qui envoie occasionnellement un formulaire, le calcul est imperceptible. Pour un bot qui cherche à reproduire la même opération plusieurs dizaines de milliers de fois, chaque nouvelle tentative exige un nouveau travail et le coût cumulé augmente avec le volume d’attaque.

Le Proof-of-Work ne cherche pas à déterminer si la personne devant l’écran est humaine. Un programme peut parfaitement résoudre le calcul demandé. Le mécanisme cherche plutôt à rendre l’automatisation massive moins avantageuse en faisant en sorte que chaque action possède un coût énergétique et donc économique.

Un CAPTCHA traditionnel essaie de distinguer un utilisateur humain d’un logiciel automatisé. Un Proof-of-Work accepte qu’un logiciel puisse résoudre le challenge mais lui impose le même coût de calcul à chaque nouvelle tentative.

Cette approche fonctionne sans demander aucune interaction supplémentaire au visiteur. Le calcul peut être effectué silencieusement dans le navigateur pendant que l’utilisateur consulte ou remplit une page. Certains systèmes anti-spam et certaines extensions WordPress anti-bot utilisent déjà ce principe pour protéger des commentaires, des connexions ou des formulaires.

Le PoW permet de vérifier une preuve sans connaître l’identité de son auteur

L’une des propriétés les plus intéressantes du Proof of Work est qu’il permet de vérifier qu’un travail a été effectué sans avoir besoin de connaître l’identité de celui qui l’a produit. Le système n’a pas besoin de savoir qui se trouve derrière un ordinateur, une requête ou un mineur pour décider si la preuve est valide. Il lui suffit de vérifier que le résultat respecte les règles imposées et qu’il aurait bien nécessité l’effort attendu pour être obtenu.

Cette manière de fonctionner est particulièrement utile dans les systèmes ouverts où les participants ne se connaissent pas et où il serait difficile de construire la sécurité autour de leur identité. Un serveur peut recevoir une preuve provenant d’un visiteur totalement inconnu et la contrôler immédiatement, tandis qu’un nœud Bitcoin peut vérifier le travail réalisé par un mineur sans savoir qui il est. La confiance ne repose pas sur un compte utilisateur, une adresse IP ou une autorité chargée d’identifier chaque participant, mais sur une preuve que n’importe quel autre participant peut vérifier de la même manière.

Le Proof of Work ne prouve pas pour autant qu’une personne est honnête, humaine ou autorisée à effectuer n’importe quelle action. Il prouve qu’un certain travail a bien été fourni. Un bot peut donc parfaitement produire une preuve valide sans révéler son identité, mais il ne peut pas simplement contourner le coût nécessaire pour l’obtenir. C’est ce qui rend ce mécanisme intéressant face aux automatisations massives puisqu’il n’est pas nécessaire de reconnaître l’attaquant pour lui imposer un coût.

Le Proof-of-Work existait bien avant le Bitcoin

La preuve de travail n’a pas été inventée pour Bitcoin. Son histoire remonte au début des années 1990 lorsque Cynthia Dwork et Moni Naor étudièrent l’idée de demander un travail computationnel pour résoudre le problème des mails indésirables. Envoyer un seul message devait être suffisamment peu coûteux pour un utilisateur, mais l’expédition de centaines de milliers ou de millions de messages devait demander une quantité beaucoup plus importante de ressources informatiques.

Adam Back développa ensuite Hashcash dans les années 1990. Le système demandait à l’expéditeur d’effectuer un calcul avant de produire un jeton pouvant être rapidement vérifié par son destinataire. Hashcash avait été pensé pour limiter le spam et l’abus de ressources Internet.

Bitcoin reprendra ensuite cette famille de mécanismes pour construire son propre système de Proof-of-Work. L’histoire du PoW est assez différente de l’image qu’en donnent aujourd’hui les cryptomonnaies. Les systèmes imposant un coût computationnel pour limiter les abus existaient avant Bitcoin et le minage en représente une application particulière devenue connue.

Les dénominateurs communs de tous les Proof-of-Work

Tous les Proof-of-Work ne reposent pas sur le même algorithme, mais ils suivent le même principe : le système impose une condition, puis la machine doit trouver une réponse qui respecte cette condition.

Prenons un exemple, le système demande :

Trouver un résultat de 8 caractères qui commence par 000.

Le résultat attendu doit donc avoir cette forme : 000.....

Par exemple :

0007F2A9 ✅ valide

00012ABC ✅ valide

00A7F2A9 ❌ invalide parce qu’il ne commence que par deux zéros

8F39A7C2 ❌ invalide parce qu’il ne commence pas par 000.

La machine doit donc trouver une valeur capable de produire un résultat valide, cette valeur est appelée nonce.

Chaque échec oblige à recommencer le calcul

La machine essaie une première valeur.

nonce = 1

Résultat : 8F42A9D1 ❌ invalide parce que le résultat ne commence pas par 000.

Elle essaie donc une autre valeur.

nonce = 2

Résultat :31BC07F4 ❌ Toujours incorrect.

Puis elle continue :

La machine ne sait pas à l’avance que le nonce 4287 donnera une réponse valide.

Elle doit donc essayer, vérifier le résultat puis recommencer en cas d’échec.

Plus la condition est difficile, plus le nombre d’essais nécessaires augmente.

Avec 000....., il faut donc en moyenne environ 4 096 essais avant de trouver une réponse valide. La machine peut trouver une réponse dès les premiers essais ou devoir en effectuer beaucoup plus.

Une fois la bonne réponse trouvée, la vérification est beaucoup plus simple.

Le client transmet le nonce trouvé et le serveur refait le calcul une seule fois.

Si le résultat commence bien par 000, la preuve est valide.

Le client peut donc avoir effectué des milliers de calculs pour trouver la réponse, alors que le serveur n’en effectue qu’un seul pour la vérifier.

Le PoW augmente le coût tout en gardant la vérification rapide

Le Proof of Work est particulièrement intéressant lorsqu’une attaque coûte très peu à lancer mais oblige le serveur à effectuer beaucoup plus de travail en retour. Une requête peut consommer bien plus de ressources que la requête pour l’envoyer. Tant que cette différence est à l’avantage de l’attaquant, il peut multiplier les tentatives à grande échelle pour un coût relativement faible.

Le Proof of Work permet de rééquilibrer cette situation en obligeant le client à fournir lui aussi une certaine quantité de calcul avant que le serveur n’accepte sa demande. Le serveur reçoit ensuite la preuve et peut la vérifier très rapidement avant de poursuivre le traitement. Le coût principal se retrouve ainsi du côté de celui qui envoie la requête, alors que la vérification reste légère du côté du serveur.

La difficulté peut également évoluer selon la situation. Lorsque le volume de requêtes augmente fortement ou qu’un comportement automatisé est détecté, le calcul demandé est alors plus important. Le coût augmente pour celui qui multiplie les tentatives, tandis que le serveur conserve une vérification aussi rapide.

Limiter les attaques DDoS en imposant un coût à chaque requête

Lors d’une attaque par déni de service, l’objectif est de multiplier les requêtes jusqu’à épuiser les ressources disponibles. Le Proof of Work permet de compliquer ce type d’attaque en obligeant chaque client à effectuer un calcul avant que le serveur n’accepte de consacrer davantage de ressources à sa demande.

Cette protection est particulièrement intéressante lorsque quelques octets envoyés par un attaquant suffisent à déclencher un traitement beaucoup plus lourd côté serveur. En imposant un travail préalable, chaque nouvelle requête demande également des ressources à celui qui l’envoie. Multiplier les connexions ou les opérations devient alors progressivement plus coûteux au lieu de reposer presque entièrement sur les ressources du serveur ciblé.

Le réseau Tor utilise ce principe pour renforcer certains services onion face aux attaques par déni de service. Lorsque la charge augmente fortement, les clients peuvent être amenés à fournir davantage de travail avant que leur demande soit prise en compte. Un utilisateur qui effectue quelques connexions est peu affecté, tandis qu’une infrastructure qui cherche à en générer massivement doit répéter le calcul pour chacune d’elles.

Cette protection est surtout adaptée aux attaques qui cherchent à épuiser les ressources applicatives d’un service. Elle ne peut pas empêcher à elle seule une attaque volumétrique qui tente de saturer la connexion réseau puisque le trafic peut alors bloquer l’accès au serveur avant même que celui-ci puisse vérifier la preuve. Le Proof of Work vient compléter les protections DDoS classiques plutôt que les remplacer.