Utiliser les Proof of Work pour régler les problèmes des captchas modernes

Historique et Définitions

Définissons les Captchas

Tout d'abord, regardons CAPTCHA, qui est un acronyme, et définissons les lettres qui nous intéressent :

• Le T est pour Turing, pour rappeler que ces tests sont des tests de Turing
• Le CA est pour Completely Automated, qui représente le fait qu'il n'y ait pas d'action humaine dans la validation d'un CAPTCHA

Rappel : Les Tests de Turing - Les tests de Turing sont une classe de tests qui visent à déterminer si un interlocuteur (dans un sens large), est un ordinateur ou un humain. Ces tests prennent de l'ampleur en ce moment avec le développement des LLMs.

Découvrir les captchas à résolution manuelle

La méthode la plus simple pour développer un Captcha est de demander à l'utilisateur de résoudre un problème qu'il peut résoudre facilement, mais qu'un ordinateur aurait du mal à résoudre en un temps raisonnable. Au début des années 2000, le moment ou cette technologie s'est développée, le problème en vogue était l'OCR (Optical Caracter Recognition)

L'aspect important à noter, dans tous les systèmes de sécurité en général, est qu'il existe une course entre les attaquants et les défenseurs. Les défenseurs ont des moyens techniques qui s'améliorent, ainsi qu'une connaissance du système de sécurité qu'ils affrontent qui s'améliore au fur et à mesure du temps. Ainsi, dans le domaine des captchas, il faut régulièrement augmenter la difficulté de ses captchas pour se prémunir des avancées technologiques des attaquants (ou alors changer les méthodes, en passant de l'OCR à la reconnaissance d'objets par exemple, afin que les progrès des attaquants sur l'OCR ne puissent pas être utilisés).

Le problème est que l'emploi de ces deux stratégies entraine deux problèmes distincts:

• Augmenter la difficulté nous conduit à une notion simple : la limite des capacités de l'humain, dont le cerveau et la capacité de compréhension sont loin d'être infinies.
• Changer les problèmes nous conduit tout droit dans des problèmes d'Affordance : L'affordance est un concept en théorie de l'ergonomie qui implique qu'un utilisateur sache interagir avec certains contenus (et qu'ils aient une façon standard d'être utilisés), c'est le cas avec une porte dans la vie réelle, dont tout le monde sait qu'il faut pousser la clanche vers le bas.

Découvrir les captchas à résolution automatique

Nous introduisons une nouvelle variable dans les possibilités afin de déterminer si un système est humain.

Porté par la mode du Big Data, plusieurs entreprises, Google en tête, ont développé des algorithmes de Machine Learning permettant de déterminer si un système est humain ou non. Ces systèmes se basent sur un ensemble de données collectées pendant la session de l'utilisateur, dont principalement :

• Les frappes au clavier du système, avec les timings entre les appuis de touches
• Les mouvements de souris
• Les chargements de scripts

Ces systèmes retournent une prédiction, donc un score, situé entre 0 et 100% de chance que le système soit humain. Dans les situations ou le score est faible, ces captchas sont souvent combinés à des captchas à résolution manuelle afin de lever les doutes, ce qui les rends très efficaces.

Des considérations éthiques et juridiques sont cependant le plus grand problème qui existe avec ces technologies. La plupart (pour ne pas dire toutes) de ces solutions sont développées par de grands groupes américains, ce qui pose des questions autant sur la création de monopoles en dehors du territoire que dans les questions RGPDLa RGPD est une loi européenne sur la sécurité des données., des arrêts de la CJUE comme Schrems I et Schrems II ayant déjà interdit les transferts de données vers les Etats-Unis, ce qui obligerait les développeurs à changer de solutions en cas de nouvelle arrêt de la CJUE, entrainant des surcôuts.

Proof of Work

Pourquoi vouloir utiliser des Proof of Work?

Si les attaquants ne peuvent pas être rentables dans leurs attaques, ils arrêteront celles-ci. Pour bloquer la rentabilité des attaquants, nous pouvons les forcer (comme tous ceux qui veulent envoyer une requête) à fournir du temps de calcul avec leur requête. Une manière de faire ceci est d'implémenter un mécanisme de preuve de travail (ou Proof of Work).

Fonctionnement des Proof of Work

L'idée centrale derrière les preuves de travail est l'asymétrie: il existe deux rôles, le chercheur, et le vérificateur. Nous pouvons prendre l'analogie de l'aiguille dans la botte de foin, le travail de chercher l'aiguille prendra des heures au chercheur, mais le vérificateur n'aura besoin que d'un coup d'œil pour se rendre compte du fait que l'aiguille trouvée en est bien une.

En informatique, on appellera la botte de foin un challenge, nos challenges se baseront sur des hashes. Un challenge définit trois variables :

• Un début de string dans laquelle chercher
• Un algorithme à utiliser pour hasher le résultat
• Une propriété à valider sur le hash

Exemple: On fixe comme début de string "toto", on cherche ensuite une valeur concaténée à "toto", tel que le hash de l'ensemble valide la propriété définie. On fixe la propriété comme étant "le hash commence par 5 zéros". On fixe l'algorithme de hash comme étant SHA256. On itére ensuite sur des valeurs possibles jusqu'à en trouver une qui marche

• sha256("totoa") = 27acd31f6acac3f4... => Ne valide pas, on continue
• sha256("totoabcd") = 74cb86362e91b973... => Ne valide pas, on continue
• ...
• sha256("toto571267") = 00000aa5c7dcdf6e... => Valide la propriété, on s'arrête

Architecture

L'architecture proposée pour ce système est assez simple, le serveur définit un endpoint qui permet de récupérer un challenge, qui est résolu par le calculateur côté client.

Plusieurs points importants sont à noter :

• la base de données Redis peut être remplacée par n'importe quelle technologie de SGBDR, l'important étant de stocker les challenges pour éviter que les attaquants ne trouvent une valeur qui valide la propriété, mais qui ne commence pas par le début de string fixé
• il devrait être possible de remplacer la base de données par un payload signé (façon JWT) afin de passer l'ensemble de l'architecture en (stateless)
• Le calculateur est une tâche calcul-intensive à paralléliser fortement, par l'usage de WebAssembly ou de WebWorkers, l'important étant de s'assurer que les différents threads ne calculent pas plusieurs fois les mêmes valeurs.

Quels avantages et inconvénients tirer des Captchas en preuves de travail?

Nous avons pu voir que les Captchas à résolution manuelles présentent des inconvénients liés au plafond atteint en terme de complexité possible des problèmes. Dans le cadre des captchas à résolution automatique par machine learning, les problèmes sont principalement juridiques et éthiques autour de la question de la gestion des données.

Dans le cadre des Captchas en Proof of Work, nous voyons que les problèmes issus des méthodes précédemment présentées sont réglés, mais que de nouveaux problèmes émergent :

• La technologie peut être considérée comme inutilement coûteuse en énergie, posant des problèmes d'écoconception
• L'application des Proof of Works au domaine des Captchas est jeune et peut manquer de recul
• Il n'existe pas d'implémentation commercialement intéressante à date de cet article : il est plus intéressant de développer sa propre solution en interne