Pertinence d'un captcha "maison" en 2023

Bonjour,

Je suis actuellement en réflexion pour l'élaboration de pages de template. En me penchant sur les pages d'inscription et de contact je me dis que je ferais bien l'impasse sur l'intégration d'un service tiers (de type reCAPTCHA).

J'imaginerais bien une question aléatoire avec un slider multi-thumb un peu comme ceci :


Voici une page concept (donc non opérationnelle) pour un exemple contextualisé : Register

J'aimerais avoir votre avis sur la question, sachant que le site pour lequel est destiné cette solution n'est en rien un Facebook.
Modifié par Olivier C (16 Oct 2023 - 01:03)

Salut,
la proposition que tu lances me plaît, alors que je suis justement sur l'élaboration d'un captcha maison, celui de Google ne me plaisant pas du tout
C'est tout frais chez moi, quelques jours, mais j'ai déjà regardé et testé quelques captcha en php ou JS. Ce que je voudrais, c'est mettre mes propres images dans un captcha.
J'ai aussi lu que certains captcha pouvaient être contournés par les robots si des précautions ne sont pas prises.
À suivre, et ton idée de curseur est originale.
J'ajoute que les captcha ne font pas bon ménage avec l'accessibilité et que les programmes d'intelligence artificielle seraient capable de déchiffrer près de 90 % des textes complexes proposés. D'où ton idée de curseur intéressante, mais si elle doit faire appel à trop de prise de tête de la part de l'utilisateur, c'est pas gagné.
Pour ma part, j'ai choisi pour le moment un champ caché pour mes formulaires. Allié à un petit peu de php et de JS, c'est assez satisfaisant, mais pas sûr à 100 %.
Modifié par Bongota (16 Oct 2023 - 09:40)

Salut,

Faire l'impasse sur Recaptcha est selon moi une bonne chose. Tu te dédouanes de google et tu restes indépendant. Pour un projet que je suis en train de développer en ce moment, j'utilise mon captcha. Je l'ai développé il y a très longtemps.

Là où je veux en venir est qu'il y a un hic dans tout ça. Bien qu'il me sert bien en ce moment et que "le peu de code en backend" qu'il y a sur le projet, je dois impérativement être en PHP. L'hébergement que j'utilise me propose seulement php.

Ce qui veut dire qu'une personne développant en Java ou Ruby ou Python ou C# ou .... et voulant utiliser mon captcha, il ne sera pas le mettre en place.

Bonjour à vous,

@Bongota : le champ caché, ou "pot de miel", n'est plus assez efficace chez moi. Ça a fonctionné un temps mais depuis un an ou deux je suis envahi de spams avec cette seule protection.

@Niuxe : effectivement, pour ma part je suis sous Node.js ; mais coder une solution ne me fait pas peur, je trouve ça plutôt stimulant au contraire. Ce qui m'intéresse est d'échanger avec vous sur des solutions un minimum efficaces que vous avez pu expérimenter, mais pas trop complexes à coder quand-même.
Modifié par Olivier C (16 Oct 2023 - 14:26)

Olivier C a écrit :
Bonjour à vous,

@Bongota : le champ caché, ou "pot de miel", n'est plus assez efficace chez moi. Ça a fonctionné un temps mais depuis un an ou deux je suis envahi de spam avec cette seule protection.

@Niuxe : effectivement, pour ma part je suis sous Node.js ; mais coder une solution ne me fait pas peur, je trouve ça plutôt stimulant au contraire. Ce qui m'intéresse est d'échanger avec vous sur des solutions un minimum efficaces que vous avez pu expérimenter, mais pas trop complexes à coder quand-même.

La marche à suivre pour un captcha maison classique (chiffre et/ou lettre) :
- génération des caractères
- génération d'un jeton (sha256 du salt + combinaison des caractères à soumettre)
- En session, il y aura : le jeton et l'image des caractères
- tu envoies à la vue, l'image et le token dans un input:hidden
- lorsque l'utilisateur soumet le form, tu vérifies la véracité de sa saisie :
** sha256 du salt + sa saisie == token initial
** sa saisie des caractères avec ceux que tu as en session

En mp, je t'ai partagé deux libs que j'ai faites il y a pas mal de temps. Je t'invite à me lire. Si tu as besoin, n'hésite pas à me contacter. Je me ferai un plaisir de t'aider et de répondre à tes questions complémentaires.

@Olivier.
Pour le moment, le champ caché rempli son rôle chez moi, mais mon formulaire a moins de six mois d'âge. Peut-être vais-je déchanter un jour, et c'est pour ça que je me penche sur les capcha.
D'ailleurs une question, que se passe-t-il si on rend le champ caché obligatoire ? Est-ce que les robots devront obligatoirement le remplir ?

@Bongota : un champ caché obligatoire, là, tout de suite, je vois deux problèmes potentiels :

1. Si l'obligation est définie de base avec l'attribut "required" (ce qui est une bonne pratique), les robots seront de facto en mesure de le détecter et donc de remplir le champ.

2. Mais surtout, ce sont tes vrais utilisateurs qui seront bloqués, incapables de comprendre qu'il y a un champ caché à remplir obligatoirement. Le comble.

2.1. Par contre il y aurait peut-être la possibilité de créer un champ (toujours caché) en Javascript et de le préremplir de la même manière. Du coup il faudrait avoir nécessairement recours au Javascript, mais en 2023 pourquoi pas ? C'est juste qu'il doit y avoir un pourcentage non négligeable de robots qui lisent aussi la page en Javascript, ils passeraient alors le barrage comme de vrais utilisateurs. Donc retour à la case départ.
Modifié par Olivier C (16 Oct 2023 - 23:43)

Salut,
je ne comprends pas, ou j'ai zapé quelque chose.

a écrit :
1. Si l'obligation est définie de base avec l'attribut "required" (ce qui est une bonne pratique), les robots seront de facto en mesure de le détecter et donc de remplir le champ.

Justement, les robots doivent détecter qu'il y a un champ (caché pour les utilisateurs humains) et le remplir. C'est cette détection qui fait dire que c'est un robot. Si en plus on l'oblige à le remplir, il est se dévoile encore plus. Non ?

a écrit :
2. Mais surtout, ce sont tes vrais utilisateurs qui seront bloqués, incapables de comprendre qu'il y a un champ caché à remplir obligatoirement. Le comble.

Le faux champ est caché grâce à un display:none dans le css. Ce champ n'apparaissant pas sur le formulaire, les visiteurs n'y sont pas contraints. Ou je me trompe ?

J'ai effectivement dans mon filtre du JavaScript qui ajoute dynamiquement le champ "caché" anti spam dans le formulaire après le chargement de la page.
On peut même aller plus loin et utiliser IntersectionObserver (valable seulement pour les formulaires situés en bas de page). L'astuce consiste à n'afficher le formulaire que quand la fenêtre croise ce formulaire. Le formulaire est chargé dans le DOM, mais il est vide, jusqu'à que IntersectionObserver prenne la main et affiche les champs.

Je n'ai pas testé cette dernière astuce, ça devient lourd, mais c'est à garder au chaud.

Bongota a écrit :
Le faux champ est caché grâce à un display:none dans le css. Ce champ n'apparaissant pas sur le formulaire, les visiteurs n'y sont pas contraints. Ou je me trompe ?

Effectivement tu te trompes : le fait de cacher le champ en CSS n'empêche aucunement l'obligation de remplir le champ s'il est configuré ainsi en HTML, le formulaire refuserait alors l'envoi à la soumission.

Je ne peux pas dire si mon anti-spam fonctionne ou pas, je n'ai pas mis en place de log (je viens de le faire).
Par contre, j'ai bien un champ dans le formulaire, en html, il est en display none dans le css et il n'apparaît pas sur le formulaire. Ce faux champs est en input, avec une class pour le css et avec un label.

Le fait que le champ apparaisse visuellement ou nom ne compte pas pour le formulaire. Si un champ - caché ou non - est présent dans le formulaire, ce dernier le prendra en compte lors de sa validation.

Maintenant, si le champ est injecté en JavaScript au sein du formulaire, le formulaire le prendra en compte seulement si JS est activé, il l'ignorera dans le cas contraire.

Dans tous les cas CSS n'a rien à voir là-dedans.
Modifié par Olivier C (17 Oct 2023 - 21:47)

En effet, un input required, caché en display:none; ou display:contents; ou simplement hors de la fenêtre ne permettra pas d'envoyé le formulaire.

Si l'on ajoute l'attribut disabled sur un champ avec l'attribut required, disabled semble prévaloir et le formulaire peut-être soumis en cachant et laissant ce champ vide. Astuce ou bidouille?

L'option JS d'ajouter cet attribut disabled ou plus simplement de retirer l'attribut required est une piste supplémentaire pour inciter un robot à remplir ce champ et pouvoir le laisser invisible au vrai visiteur. exemple pour jouer avec https://codepen.io/gc-nomade/pen/ExGqwPb

Il y a aussi d'autre façon de réduire les faux visiteurs, réduisant ainsi aussi les spams, en filtrant: IP, user agent , nombre de page sollicitée en un temps donné, ...
Il peut-être intéressant d'enregistrer quelques données concernant le visiteur qui envoi un formulaire lorsque des spams se font sentir. (origine,plage horaire, ip, ... ) de façon à determiner quel types de visiteurs n'en sont pas.

Si l'on a un serveur Apache, avec un fichier .htaccess il est aisé de trouver des ressources et règles de filtrages faciles à mettre en place et a compléter soi même au besoin pour virer et rediriger en amont les connexions toxiques. Il y a surement des ressources similaires pour les autres type de serveur.

Cdt

@qcyrillus : les remarques que tu fais sont pertinentes bien sûr, elles rejoignent celles de QuentinC dans l'un de ses messages que j'ai trouvé sur Zest de savoir. Disons que ce serait un plus, mais j'aimerais bien tout de même avoir comme base un captcha, reste à savoir son type et son efficacité.

Bonjour,
Pour le "required", merci de la précision, j'aurais dû y penser
Voici ce que j'ai mis en place. Je ne l'ai évidemment pas codé moi-même mais j'ai pris du temps pour le comprendre dans sa totalité. Le lien est en bas de page. J'avoue que je ne sais pas ce que ça vaut, comme je le disais, mon formulaire est récent.

Dans le formulaire html, un champ est ajouté.

<form id="formcontact" method="post">

/... autres champs du formulaire/

<label class="remarque">Remarque</label>
<input class="remarque" name="remarque"
          pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$"
          placeholder="nom@domaine.com">

Dans le css, il est en display none.

#formcontact > .remarque { display:none; }

Le php :

f ($_POST['remarque'] != "") {
    $msg  = strftime('%Y-%m-%d %H:%M:%S')."\n";
    $msg .= var_export($_POST,true)."\n";
    file_put_contents('logs/mailspams.log', $msg, FILE_APPEND | LOCK_EX);
    die();
}

Enfin, le JavaScript ajoute dynamiquement le champ caché dans le formulaire, après le chargement de la page. Je n'ai pas mis le JS ici, trop long. Le lien où j'ai trouvé ce code :
https://www.sqlpac.com/fr/documents/conception-html-formulaires-anti-spam-sans-captcha.html
Modifié par Bongota (19 Oct 2023 - 08:46)

@bongota,
Si l'idée est de tromper un bot qui rechercherait un formulaire dans le source d'une page, on peut aussi regarder du coté de template voir https://developer.mozilla.org/fr/docs/Web/HTML/Element/template et ainsi générer le formulaire qu’après chargement de la page.
voici deux approches:

https://codepen.io/gc-nomade/pen/rNoXPLm avec la balise template et son contenu dans ... le document . Si vu et rempli par un robot, il n'est en principe pas fonctionnel sous cette forme, mais peut-être copier et soumis depuis une autre page.

https://codepen.io/gc-nomade/pen/PoXMVjM la même avec le template extrait d'une variable

@Olivier on peut aussi penser à générer un captcha simple et son jeton de cette manière pour le rendre invisible aux spammeurs automatisé les moins évolués. Si pas vu, pas rempli

Cdt
Modifié par gcyrillus (19 Oct 2023 - 10:13)