CAPTCHA o honeypot en formularios de registro

CAPTCHA incluye varios diseños. Por ejemplo, la documentación de reCAPTCHA v3 de Google describe una puntuación sin una tarea interactiva. Tanto la puntuación como la acción esperada siguen necesitando verificación en el servidor.

Qué establece cada comprobación

Un honeypot es un campo señuelo que un envío normal debe dejar vacío. El servidor comprueba esa regla al recibir el formulario. Puede detectar scripts que rellenan todos los campos, pero un atacante puede reconocerlo y omitirlo. La documentación de Drupal Honeypot explica ese límite y una comprobación opcional de tiempo mínimo. El umbral de tiempo es una regla independiente, no una propiedad de todo honeypot.

Un CAPTCHA interactivo pide al visitante que complete una tarea. La nota de borrador del grupo W3C sobre accesibilidad de CAPTCHA describe las barreras que esas tareas pueden crear para las personas con discapacidad. Si la tarea forma parte del registro, pruebe el acceso con teclado y tecnologías de asistencia, la recuperación y una ruta alternativa. Una evaluación no interactiva tiene otros compromisos y también necesita su propia evaluación.

Superar una comprobación aporta evidencia de esa interacción. No establece que la cuenta pertenezca a una persona única. Un honeypot vacío no demuestra que el envío sea humano.

Elija una combinación para el registro

Las siguientes combinaciones cubren comprobaciones distintas. Elija según la evidencia que necesite y el coste de una decisión incorrecta:

• Honeypot y confirmación del correo. Use el señuelo como primer filtro para scripts que lo rellenan. Exija un enlace de confirmación antes de conceder los permisos ligados al control del buzón. Siguen siendo posibles los scripts que lo omiten, y quien controle muchos buzones puede crear muchas cuentas.
• CAPTCHA y confirmación del correo. Use una prueba validada o una evaluación de interacción cuando necesite esa comprobación adicional. Mantenga la confirmación para el control del buzón. Decida cómo continúa un visitante legítimo que no puede completar la prueba y mida tanto registros satisfactorios como abandonos.
• Señales de visita y confirmación del correo. Use evidencia de la visita y del envío para decidir cuándo confirmar. Puede evitar añadir una tarea que resolver, pero no establece una protección equivalente al CAPTCHA elegido. Evalúelo con su propio tráfico de registro.

Confirmar establece acceso al buzón usado para el enlace. La verificación del correo comprueba la dirección y la evidencia del sistema de correo sin enviar ese mensaje. La comparación entre verificación y confirmación explica cuándo hace falta cada paso.

Distinga las comprobaciones incompletas

En el servidor, distinga una regla incumplida, una respuesta caducada y una comprobación no disponible. Por ejemplo, la documentación de validación de Turnstile de Cloudflare separa los tokens caducados o duplicados de los errores internos y exige validación del servidor. El widget por sí solo no protege el formulario. Siga las reglas de validación y reintento del componente concreto que use.

Elija una alternativa explícita si la comprobación no está disponible: pedir una prueba nueva, retener el registro o limitar permisos hasta completar otra comprobación. La opción depende de los privilegios de la cuenta y de las reglas de su aplicación. Limite los reintentos, conserve los campos introducidos cuando corresponda y explique el siguiente paso. Un tiempo de espera agotado no demuestra que el visitante haya fallado una prueba humana.

Para un honeypot, defina qué hace el servidor con un campo ausente o mal formado, además de uno rellenado. Antes de rechazar cuentas por esa regla, compruebe que los navegadores habituales, el autocompletado y las tecnologías de asistencia envían correctamente el formulario.

Qué aporta Emvero

Signup Protection combina evidencia de correo y visita o comprueba las señales por separado. Su servidor envía el token y los datos disponibles de la petición; Emvero devuelve una action recomendada. Su aplicación la aplica. Emvero no proporciona el honeypot o CAPTCHA, no envía su confirmación ni concede permisos de cuenta.

Las señales pueden elevar un correo permitido a allow_with_email_confirmation. Por sí solas no recomiendan reject; una respuesta combinada puede rechazar por el resultado del correo. Los hallazgos de red, como el uso de VPN, son informativos por defecto. Un resultado de señales unavailable no es evidencia de una visita segura.

Mantenga separados la acción externa de registro, el correo anidado y el resultado de señales. Los límites de frecuencia, el estado de confirmación y las reglas de acceso siguen siendo responsabilidad de su aplicación. La guía de instalación para proteger el registro explica formulario, token, petición del servidor y acción.