ReportedIP Hive 2.1.36 — Compatibilidad oficial con YubiKey y Hardware Security Key
ReportedIP Hive 2.1.36 convierte las Hardware Security Keys en un segundo factor oficial de primer nivel. Una YubiKey —o cualquier Passkey FIDO2 o Passkey de plataforma— completa ahora un proceso completo de WebAuthn en las tres interfaces de inicio de sesión (wp-login, la tienda de WooCommerce y la página de restablecimiento de contraseña), con el respaldo de un gestor de claves múltiples, la detección automática del modelo de clave y alertas de claves clonadas.
Esta versión agrupa las fases de desarrollo 2.1.33–2.1.35 en una sola actualización. Puedes descargarla desde «Plugins» → «Buscar actualizaciones» o desde la página de GitHub Releases; si te perdiste la serie de actualizaciones para reforzar el cortafuegos que la precedió, el artículo sobre la versión 2.1.21 trata ese tema.
¿Qué ha cambiado desde la versión 2.1.21 de Hive?
Se lanzaron once versiones entre la 2.1.23 (9 de julio de 2026) y la 2.1.36 (5 de agosto de 2026). El hilo conductor: una aplicación más rigurosa con menos errores propios, una versión con un rendimiento sustancialmente mejorado y, por último, el hito de la clave de hardware.
| Versión | Cambio en el titular |
|---|---|
| 2.1.23 | La regla predeterminada del WAF bloquea la sonda PHPUnit eval-stdin.php (CVE-2017-9841) en todos los planes; los usuarios que agotan el periodo de gracia de la autenticación de dos factores (2FA) son redirigidos a la inscripción obligatoria en lugar de quedar bloqueados. |
| 2.1.24 | El envío duplicado de la solicitud de Login con 2FA ya no hace que los usuarios correctamente autenticados se queden bloqueados en una página de «sesión caducada». |
| 2.1.25 | Hay dos reglas básicas dirigidas a la clase de confusión de rutas por lotes REST del núcleo de WordPress; los cuerpos de las solicitudes se comparan tanto en formato sin procesar como una vez descodificados, lo que elimina una vulnerabilidad que permitía eludir el Payload codificado. |
| 2.1.26 | Las solicitudes de los rastreadores se cotejan con el Reverse DNS confirmado y los rangos de IP oficiales; un mecanismo de protección central impide que cualquier sensor bloquee automáticamente un Googlebot verificado; los subsitios Multisite vuelven a leer las tablas correctas. |
| 2.1.27 | Un agente de usuario falsificado de «Jetpack by WordPress.com» ya no evita que los intentos de Login por Brute Force se bloqueen automáticamente; la opción «Confiar en este dispositivo» sigue activa tras los intentos fallidos. |
| 2.1.28 | Ahora, un ataque a la reputación de la comunidad aplica un bloqueo de 24 horas que abarca todas las páginas, no solo el formulario de Login; se ha elevado la versión mínima de WordPress a la 5.9. |
| 2.1.29 | El nuevo indicador «Mantener públicas las páginas de archivo de los autores» distingue la fuga real de User Enumeration (?author=N) de los enlaces de archivo inofensivos. |
| 2.1.30 | El filtro previo a WordPress aplica bloqueos de IP antes de que se cargue WordPress y registra cada acceso en un archivo de cola; Extended Protection aparece finalmente en los registros y en la escala de escalación. |
| 2.1.31 | La escala de Block Escalation tiene en cuenta el volumen de ataques (una ráfaga de 60 infracciones salta varios peldaños); el servidor ya no puede bloquear automáticamente su propia IP debido a la precarga de la caché y a los bucles de retorno de cron. |
| 2.1.32 | Mejoras de rendimiento: de 36 a 11 consultas al plugin por solicitud anónima; las respuestas de la Blocklist se obtienen a partir de un encabezado de 8 KB en lugar de leer un archivo de 1 MB; el TTFB del Dashboard ha pasado de 920 ms a 278 ms en una tabla de registros de 500 000 filas (esquema v13); La capa de WordPress vuelve a aplicar los bloqueos de rangos CIDR. |
| 2.1.36 | Compatibilidad oficial con YubiKey y Hardware Security Key, y la sección de 2FA del perfil rediseñada (que agrupa las versiones 2.1.33 a 2.1.35). |
Las Hardware Security Keys son ahora un segundo factor de primer orden
Hive es compatible con WebAuthn desde la versión 1.4.0, pero era más acertado calificarlo como «de nivel de Passkey» en lugar de «de nivel de clave de hardware»: el desafío de WooCommerce mostraba una pestaña «Passkey» cuyo panel no existía, y la pantalla de restablecimiento de contraseña ofrecía WebAuthn sin cargar ningún script de autenticación. La versión 2.1.36 subsana esa carencia. Las tres interfaces de autenticación —la pantalla intersticial de wp-login, la pantalla de autenticación de la tienda de WooCommerce y la pantalla de restablecimiento de contraseña— muestran ahora un único panel compartido de WebAuthn (templates/partials/webauthn-challenge-panel.php) y completan una ceremonia de autenticación completa.
Los detalles de la ceremonia se han adaptado al hardware real. El tiempo de espera se ha aumentado de los 60 segundos predeterminados por WebAuthn a 120 segundos (CEREMONY_TIMEOUT_MS, class-two-factor-webauthn.php), ya que las lecturas NFC en los teléfonos suelen necesitar ese tiempo adicional. Cuando libsodium está disponible, se ofrece Ed25519 (EdDSA, COSE −8) antes que ES256 y RS256, y se verifica del lado del servidor —el algoritmo que prefiere el firmware 5.2.3+ de YubiKey—. Y userVerification por defecto se discouraged, siguiendo las directrices de Yubico sobre la presencia del usuario frente a la verificación del usuario, de modo que una clave nueva nunca sorprenda al usuario con una solicitud de PIN FIDO2 durante un Login con segundo factor. Los operadores que deseen la verificación mediante PIN o datos biométricos pueden elevar el nivel de seguridad a través del reportedip_hive_webauthn_user_verification filtro; la política elevada se aplica entonces del lado del servidor, no solo se solicita del lado del cliente.
Otra decisión deliberada: el registro ahora requiere residentKey: 'discouraged'. Al registrar una YubiKey como segundo factor de autenticación en WordPress, ya no se consume una de las limitadas ranuras de credenciales detectables de la llave (25 en la mayoría de los firmwares de la serie 5, 100 a partir del firmware 5.7); en su lugar, la credencial se almacena en el servidor. Las credenciales detectables existentes siguen funcionando.
El gestor de claves de seguridad se encuentra en el perfil de usuario
Ahora todos los usuarios disponen de un gestor de «Claves de seguridad y Passkeys» en su perfil: pueden registrar varias claves (una principal y otra de respaldo), asignarles un nombre o cambiarlo, eliminarlas individualmente y consultar cuándo se añadió cada clave y cuándo se utilizó por última vez. Los botones de registro incluyen indicaciones de WebAuthn: «Clave de seguridad (USB/NFC)» se corresponde con authenticatorAttachment: cross-platform, «Este dispositivo» a platform —, de modo que Chrome y Edge abren directamente el cuadro de diálogo correcto en lugar de preguntar dos veces. Al eliminar la última clave, el método se desactiva siguiendo el procedimiento habitual de desactivación, nunca de forma silenciosa.
El complemento te indica qué modelo de clave se ha registrado
El registro solicita una certificación directa, verifica las firmas de certificación empaquetadas, extrae el AAGUID y lo compara con un registro integrado de 91 modelos de autenticadores —81 entradas de hardware de Yubico, además de las principales plataformas de Passkeys (Windows Hello, iCloud Keychain, Google Password Manager, 1Password y otras), procedentes del servicio de metadatos de la Alianza FIDO. El modelo detectado («YubiKey Serie 5 con NFC», «Windows Hello») aparece bajo el nombre de la clave. Toda la ruta es de solo visualización y de «fail-open»: una certificación ausente o no verificable nunca bloquea un registro, en consonancia con las directrices de Yubico de que la certificación debe informar, no actuar como barrera.
Las claves clonadas se detectan y se notifican por correo electrónico
Los autenticadores mantienen un contador de firmas que debe incrementarse con cada afirmación. Una afirmación cuyo contador no se incrementa es el indicio clásico de un autenticador clonado o revertido, por lo que Hive ahora la rechaza, registra 2fa_webauthn_counter_regression con un nivel de gravedad alto y envía un correo electrónico al titular de la cuenta; en todos los planes, con un límite de un correo por credencial cada hora. Las Passkeys de la plataforma sin contador (que legítimamente indican cero) siguen funcionando. Las afirmaciones sin el indicador de presencia del usuario se rechazan según lo establecido en WebAuthn §7.2. Los registros y eliminaciones de claves activan sus propios correos de notificación en el Business plan.
Se ha rediseñado la sección de autenticación 2FA del perfil para los usuarios finales
La sección de perfil anterior daba por hecho que sabías lo que significaba «TOTP». La nueva versión utiliza tarjetas del sistema de diseño con una introducción en lenguaje sencillo y una fila por cada método de inicio de sesión —Authenticator App, Passkey o llave de seguridad, código por correo electrónico, SMS—, cada una con una descripción sencilla, una insignia que indica si está «Activo» o «Predeterminado» y acciones integradas. Se han modificado tres aspectos a nivel técnico:
- Los métodos se pueden añadir en cualquier momento, no solo mientras la 2FA siga desactivada, y todas las vías de registro (perfil, asistente de configuración, WP-CLI, el gestor de claves) pasan por una ruta de activación compartida.
- El usuario puede elegir el método de inicio de sesión predeterminado. Cada fila de método activo ofrece la opción «Establecer como predeterminado»; se solicita esta elección en primer lugar durante el proceso de Login. En realidad, se trata de un nuevo
set_primary_methodEndpoint AJAX que delega enTwo_Factor::set_user_method(), que rechaza cualquier método que el usuario no haya habilitado realmente. - La gestión de SMS se ha trasladado al perfil. Allí se puede configurar o modificar un número, y el número modificado solo sustituye al verificado una vez que el nuevo número haya confirmado un código; ya no es posible que un error tipográfico impida que el método funcione.
Ahora es posible eliminar métodos de forma individual, con una advertencia clara en caso de que al eliminar el último se desactive por completo la autenticación de dos factores (2FA). Las instalaciones nuevas permiten los cuatro métodos de forma predeterminada (totp, email, webauthn, sms — el SMS se puede utilizar una vez que se haya activado un plan con capacidad de retransmisión); los sitios existentes conservan la selección almacenada. Además, añadir un segundo método ya no sobrescribe la configuración predeterminada del usuario ni regenera de forma silenciosa los Recovery Codes existentes, algo que sí hacía el antiguo Endpoint de confirmación TOTP.
¿Qué sigue siendo gratuito y qué requiere la versión Business?
En todos los planes se incluye de forma gratuita una clave de seguridad o Passkey por cuenta, lo que incluye el registro, el Login en las tres superficies de autenticación, el cambio de nombre y la eliminación, así como el correo electrónico de aviso de claves clonadas. El Business plan añade una capa avanzada: varias claves por cuenta, detección automática del modelo mediante certificación y alertas por correo electrónico sobre el ciclo de vida de las claves. La distinción se aplica del lado del servidor en los Endpoints de registro (webauthn_advanced en la matriz de características), y los registros del Free tier solicitan attestation: 'none' , de modo que nunca aparece un mensaje de consentimiento en el navegador para una función que el nivel no incluya. Los detalles de los planes se encuentran en la página de precios.
Si quieres conocer los fundamentos sobre cómo se relacionan WebAuthn, las Passkeys y las claves de hardware, la guía de Login con Passkeys explica estos conceptos; para obtener información sobre la clave específica con la que desarrollamos y realizamos pruebas, consulta el artículo sobre la YubiKey 5C NFC.
Correcciones de seguridad incluidas en la versión
La oficialización de las claves de hardware supuso auditar todo el proceso de WebAuthn, y de esa auditoría surgieron varias correcciones. El proceso de restablecimiento de contraseña ahora vincula el navegador a la identidad restablecida mediante un token de corta duración generado por el servidor —nunca a través de parámetros de URL, que pueden filtrarse a través de las referencias y los registros—. Los endpoints AJAX de Login de WebAuthn se encuentran protegidos por el mismo sistema de bloqueo por IP que el formulario de desafío, lo que impide eludir el Rate Limit, y las opciones de registro están limitadas por usuario. El decodificador CBOR autónomo rechaza entradas truncadas, de longitud indefinida, etiquetadas y de tipo float con mensajes de error claros y un límite de profundidad de anidamiento; la ruta COSE de EC2 verifica la curva P-256 antes de su uso.
Hay dos mejoras relacionadas con la calidad de vida que conviene conocer. Al tocar una YubiKey fuera de una sesión activa ya no se producen errores que puedan llevar a confusión: la entrada Yubico-OTP tecleada (la larga cadena de caracteres en minúsculas que emite una llave al tocarla accidentalmente) se detecta y se responde con instrucciones. Además, al iniciar una configuración de TOTP ya no se sustituye de forma silenciosa el secreto de un autenticador ya confirmado; para volver a configurarlo es necesario seleccionar explícitamente «Configurar de nuevo». Fuera del subsistema de 2FA, la sincronización «drop-in» de WAF ahora comprueba la capacidad de escritura antes de cada escritura de guardias, Blocklist y directivas, y recurre a un comportamiento «fail-open» en lugar de mostrar advertencias de PHP que interrumpían las redirecciones de administrador con el mensaje «headers already sent» en sistemas de archivos de solo lectura.
Se avecina una aplicación más estricta de la ley y menos ruido
La serie de versiones 2.1.23–2.1.32 merece una mención especial, ya que varios de esos cambios modifican el comportamiento diario. Desde las versiones 2.1.26/2.1.27, una declaración de rastreador en el agente de usuario no tiene ningún valor por sí sola: cada declaración se coteja con el Reverse DNS confirmado y los rangos de IP oficiales; un filtro central solo exime a los rastreadores verificados de cualquier decisión de bloqueo automático, y los eventos que implican el uso de credenciales —como los intentos fallidos de Login— eluden por completo la Allowlist de bots, ya que los rastreadores auténticos nunca envían credenciales. Desde la versión 2.1.31, el servidor tampoco puede bloquearse a sí mismo: los rastreadores de precarga de caché, los bucles de WP-Cron y las autosolicitudes REST proceden de la propia dirección pública del sitio, y un Multisite en producción había bloqueado automáticamente su propia dirección IPv6 durante siete días por «uso indebido de la REST API». El proceso automático ahora se desactiva para las direcciones propias del servidor y una migración de actualización elimina los autobloqueos existentes.
Al mismo tiempo, se reforzaron las medidas de aplicación. La escala de escalada ahora tiene en cuenta el volumen: un atacante que provoque sesenta infracciones de las reglas en diez segundos se salta varios peldaños, en lugar de acumular los mismos cinco minutos que se aplicarían por tres infracciones. El filtro previo a WordPress (Extended Protection) aplica bloqueos de IP antes de que se cargue WordPress y registra cada acceso que bloquea, por lo que el sistema de escalonamiento y las denuncias de la comunidad funcionan incluso para las solicitudes que WordPress nunca llega a ver. Y la versión 2.1.32 asumió el coste de rendimiento de todo ello: de 36 a 11 consultas de plugins por solicitud anónima, una Blocklist que responde a partir de un encabezado de 8 KB en lugar de leer hasta 1 MB por solicitud, y un Dashboard cuyo TTFB se redujo de 920 ms a 278 ms en una tabla de registros de 500 000 filas.
Cómo actualizar a Hive 2.1.36
El verificador de actualizaciones integrado consulta GitHub cada 12 horas; para descargar la versión inmediatamente, abre «Plugins» → «Buscar actualizaciones». Los requisitos no han cambiado desde la versión 2.1.28: WordPress 5.9+ y PHP 8.1+. No es necesaria ninguna migración manual: la rutina de actualización se encarga del esquema, y libsodium (incluida con PHP desde la versión 7.2) es todo lo que se necesita para Ed25519. La compatibilidad con el hardware está documentada en la matriz de pruebas de WebAuthn del repositorio, que verifica cada versión con una YubiKey 5C NFC real en Windows, Android, iPhone y macOS.