YubiKey 5C NFC para la 2FA de WordPress: configuración, interioridades y errores

5 de agosto de 2026 Actualizado 16 de septiembre de 2026 Patrick Schlesinger

La YubiKey 5C NFC es la llave de hardware con la que nuestro equipo inicia sesión cada día y, desde Hive 2.1.36, es un segundo factor oficialmente compatible en cualquier sitio WordPress que ejecute el plugin. Esta guía cubre el hardware, la ceremonia WebAuthn que hay detrás del inicio de sesión, los ajustes que escribe Hive, los hooks para desarrolladores y los nueve errores con los que realmente te encontrarás en producción.

La foto de arriba no es una imagen de archivo: es la YubiKey 5C NFC de nuestro propio puesto de desarrollo, el dispositivo de referencia detrás de cada versión de Hive. Todos los números de versión y valores predeterminados que siguen provienen de Hive 2.1.57, publicada el 15/09/2026.

¿Qué es la YubiKey 5C NFC?

La YubiKey 5C NFC es un autenticador de hardware fabricado por Yubico. Guarda claves criptográficas en un elemento seguro, firma los desafíos de inicio de sesión cuando la tocas y nunca expone la clave privada al ordenador. No tiene batería, ni pantalla, ni conexión de red. Se conecta por USB-C o se acerca a un teléfono con NFC, justo la combinación que necesita una administradora de WordPress: cable en el escritorio, acercamiento rápido fuera de casa.

Conectores	USB-C y NFC (acercamiento rápido en Android e iOS)
Protocolos de autenticación	WebAuthn / FIDO2 (CTAP 1, 2 y 2.1), U2F, tarjeta inteligente PIV, Yubico OTP, OATH-HOTP/TOTP, OpenPGP, contraseñas estáticas
Capacidad de passkeys	25 credenciales detectables; 100 a partir del firmware 5.7
Algoritmos de firma	ES256, RS256; Ed25519 (EdDSA) desde el firmware 5.2.3
Construcción	IP68 resistente al agua y al polvo, resistente al aplastamiento, sin batería ni piezas móviles; fabricada en Suecia

Las especificaciones completas están en la página oficial del producto de Yubico; la historia de Ed25519 empieza con las notas de versión del firmware 5.2.3. Una nota práctica sobre la capacidad: el límite de 25 solo afecta a las credenciales detectables, es decir, a las passkeys guardadas en la propia llave. Un segundo factor de WordPress configurado con Hive no ocupa ninguna de esas ranuras; el motivo está más abajo.

Por qué una llave de hardware gana a los códigos de un solo uso

Todo segundo factor basado en códigos, ya sea una aplicación de autenticación, el correo o un SMS, comparte una misma debilidad: el código se puede teclear en la página equivocada. Un sitio de phishing que hace de intermediario con tu inicio de sesión real retransmite un código TOTP dentro de su ventana de 30 segundos, y los atacantes automatizan justo eso con kits de proxy inverso ya hechos. Una llave FIDO2 es inmune por construcción a esta clase de ataque: la firma que produce está ligada al origen que la pidió, así que una credencial registrada para tu dominio real no produce nada aprovechable en un dominio imitador. No hay código que robar porque no hay código.

Segundo factor	Resistente al phishing	Funciona sin conexión	Fallo típico
Aplicación de autenticación (TOTP)	No, los códigos se pueden retransmitir	Sí	Teléfono perdido o restablecido sin copia de seguridad
Código por correo	No	No	Buzón comprometido o correo retrasado
Código por SMS	No	No	Intercambio de SIM, fallos de entrega
Llave de hardware (FIDO2)	Sí, firmas ligadas al origen	Sí	Llave perdida sin llave de repuesto

La objeción honesta está en la última celda: una llave perdida sin alternativa te deja fuera. La respuesta práctica es la misma que da Yubico. Registra dos llaves y guarda una fuera de la oficina. Hive lo permite con un gestor de llaves que admite una credencial principal y una de respaldo, además de códigos de recuperación y cualquier otro método 2FA como alternativa. Nuestra guía de 2FA para WordPress compara los cuatro métodos con más detalle.

Cómo funciona en realidad la ceremonia WebAuthn

Entender la ceremonia explica la mayoría de los mensajes de error que verás alguna vez, así que estas 400 palabras merecen la pena. WebAuthn divide la autenticación en dos ceremonias: el registro, donde la llave crea un par de claves nuevo, y la aserción, donde la llave firma un desafío para demostrar que sigue teniendo la mitad privada.

El registro vincula un par de claves a un solo dominio

Cuando registras una llave, el servidor envía un desafío aleatorio de 32 bytes, un identificador de parte confiante (el nombre de host escueto, por ejemplo example.com) y una lista de algoritmos de firma aceptables. El navegador añade el origen que está mostrando, lo resume todo en clientDataJSON y pasa la petición al autenticador. La llave genera un par de claves nuevo limitado a ese identificador de parte confiante, guarda la clave privada dentro del elemento seguro y devuelve la clave pública junto con un identificador de credencial. El servidor almacena ambos. Nada secreto cruza jamás la red, y la misma llave produce un par completamente distinto en cada sitio, de modo que dos sitios no pueden correlacionar a sus usuarios a través de la credencial.

La aserción demuestra posesión sin revelar nada

Al iniciar sesión, el servidor envía un desafío aleatorio nuevo y la lista de identificadores de credencial que conoce para esa cuenta. La llave firma la concatenación de sus datos de autenticador y el hash SHA-256 de clientDataJSON. El servidor verifica esa firma contra la clave pública almacenada y comprueba cuatro cosas: que el desafío coincide con el que emitió, que el origen está en su lista, que el hash del identificador de parte confiante coincide y que la bandera de presencia de usuario está puesta. La firma no vale nada en ningún otro dominio, porque el origen va dentro de la carga firmada. Esa única propiedad es la que hace fracasar a un proxy de phishing: el atacante puede retransmitir los bytes, pero la firma lleva su propio dominio y el servidor real la rechaza.

Para qué sirve el toque

Tocar el disco dorado pone la bandera de presencia de usuario. Demuestra que hay una persona físicamente junto a la llave y no un programa malicioso manejando la pila USB en silencio. No es una verificación de identidad. La verificación de identidad (la bandera UV) es un paso aparte que exige un PIN FIDO2 o una huella, y Hive no la pide de forma predeterminada de manera deliberada. El razonamiento está en la sección siguiente.

Cómo implementa Hive WebAuthn en WordPress

Hive incluye un verificador WebAuthn de nivel 2 autónomo en class-two-factor-webauthn.php (1.325 líneas), sin dependencia de Composer. Analiza objetos de atestación CBOR y claves públicas COSE con el OpenSSL de la biblioteca estándar, lo que mantiene ligero el plugin distribuido. El compromiso está documentado en la cabecera de la clase: cubre el subconjunto necesario para el segundo factor y no valida cadenas de certificados de atestación contra el FIDO Metadata Service.

Es una decisión deliberada, no una carencia. La atestación solo dice qué modelo de llave se usó. La ceremonia de alta ocurre de todas formas después de una autenticación por contraseña correcta, así que una cadena de atestación verificada no aporta entropía útil a un segundo factor. Hive verifica las declaraciones de atestación packed en la medida de lo posible y usa el resultado para una sola cosa: la etiqueta del modelo en el gestor de llaves.

Los algoritmos que se ofrecen en el registro

Hive ofrece tres algoritmos COSE, el más fuerte primero: Ed25519 (-8), ES256 (-7) y RS256 (-257). Ed25519 solo entra en la lista cuando sodium_crypto_sign_verify_detached() existe en el servidor, porque una credencial registrada hoy con un algoritmo que el servidor no pueda verificar mañana sería un bloqueo silencioso. Desde PHP 7.2 libsodium forma parte del núcleo, así que la mayoría de los alojamientos cumplen la condición. Una YubiKey con firmware 5.2.3 o posterior elige Ed25519 de esa lista, y puedes confirmarlo en tu propia instalación: la credencial almacenada indica el algoritmo COSE −8.

Por qué userVerification se queda en discouraged

Hive fija userVerification: 'discouraged' en ambas ceremonias, el valor que Yubico recomienda para el uso como segundo factor puro. Una YubiKey nueva no tiene PIN FIDO2, y preferred o required empujaría al usuario a crear un PIN en mitad de un inicio de sesión. Los autenticadores de plataforma como Windows Hello o Touch ID verifican al usuario de forma intrínseca al margen de este valor, así que ahí no se pierde nada. Los sitios que quieren una verificación estricta suben el valor con el filtro reportedip_hive_webauthn_user_verification, y entonces el servidor exige la bandera UV en cada ceremonia en lugar de fiarse del cliente.

Por qué el alta no consume una ranura de passkey

El registro pide residentKey: 'discouraged'. Una credencial detectable, es decir, una passkey guardada en la propia llave, ocuparía una de las 25 ranuras de la YubiKey y obligaría a crear un PIN FIDO2 en plena configuración, sin ningún beneficio para el segundo factor: el flujo de inicio de sesión siempre aporta allowCredentials, así que la llave nunca tiene que descubrir nada por su cuenta. La credencial vive en los metadatos de usuario del sitio, la llave no guarda nada, y por eso una sola YubiKey puede servir a un número ilimitado de sitios WordPress. Las credenciales dadas de alta antes de este cambio siguen funcionando.

Manejo de desafíos y vínculo con la identidad

Los desafíos son 32 bytes aleatorios, se guardan 300 segundos en un transient y se borran en el momento en que se consumen, así que una respuesta repetida falla al segundo intento. Durante el inicio de sesión el usuario todavía no está autenticado, lo que descarta un nonce normal de WordPress. Hive vincula la identidad mediante la cookie httpOnly reportedip_2fa_token que el filtro de autenticación coloca tras la comprobación de la contraseña, con una vida de 900 segundos. El JavaScript nunca lee ese token, lo que lo mantiene fuera del alcance de una inyección de scripts. Las superficies sin esa cookie, sobre todo la puerta de restablecimiento de contraseña, reciben en su lugar un token de ceremonia de un solo uso. Ninguno de los dos tokens sustituye a la firma: presentarlo solo da acceso a la ceremonia.

Las tres superficies de desafío

Una llave de seguridad funciona en los tres sitios donde WordPress puede pedir un segundo factor: el desafío de wp-login.php, el desafío de WooCommerce en la tienda para cuentas de cliente y la puerta de restablecimiento de contraseña. Esta última pesa más de lo que parece. Un sitio que protege el inicio de sesión pero deja el restablecimiento abierto a un segundo factor solo por correo ha movido el ataque en lugar de eliminarlo. Por eso la opción reportedip_hive_2fa_password_reset_excluded_methods excluye ahí email de forma predeterminada.

Configurar una YubiKey en tu sitio WordPress con Hive

El plan gratuito incluye una llave de seguridad o una passkey por cuenta, con inicio de sesión en las tres superficies. La configuración lleva unos dos minutos.

Instala ReportedIP Hive (2.1.36 o posterior) y activa la autenticación de dos factores. Desde la 2.1.54 ese interruptor está en la página de inicio rápido, y los cuatro métodos están permitidos de forma predeterminada.
Abre tu perfil de WordPress y busca la tarjeta Security keys & passkeys.
Ponle nombre a la llave primero (YubiKey oficina ayuda más que Llave 1 cuando tengas que decidir qué credencial revocar) y elige después Security key (USB / NFC). Ese botón envía la pista security-key, que hace que Chrome y Edge abran directamente el diálogo de llave de hardware en vez de ofrecer antes un código QR para el móvil.
Inserta la llave y toca el disco dorado, o mantenla plana contra la parte superior del teléfono si usas NFC.
Registra una segunda llave como respaldo, o genera códigos de recuperación como alternativa.

El segundo botón de esa tarjeta, This device (Face ID / Windows Hello), envía la pista client-device y da de alta el autenticador de plataforma. Ambos acaban en la misma lista de credenciales; solo cambian la etiqueta del modelo y el transporte.

Un detalle que ahorra un ticket de soporte: el registro está limitado a diez peticiones de opciones por usuario cada diez minutos. Probar el alta una y otra vez en un sitio de pruebas alcanza ese techo, y el mensaje («Too many registration attempts») parece un fallo si no conoces la regla.

Qué ajustes del sitio gobiernan las llaves de seguridad

La mayoría de los sitios nunca tocan estos valores, pero saber qué existe convierte un despliegue de obligatoriedad en un plan y no en una apuesta. Todos están en la página Protection desde la 2.1.56, y todos se pueden aplicar en remoto mediante MainWP o el transporte de flota en la nube.

Opción	Valor predeterminado	Efecto
`2fa_allowed_methods`	totp, email, webauthn, sms	Qué métodos pueden configurar los usuarios. Un método retirado aquí se rechaza en el servidor durante el alta, de modo que no se puede registrar una llave mientras el método está apagado para que empiece a funcionar en silencio en cuanto se vuelva a encender.
`2fa_enforce_roles`	administrator	Roles que deben tener un segundo factor.
`2fa_enforce_grace_days`	7	Días que un usuario afectado puede iniciar sesión antes de que la configuración sea obligatoria.
`2fa_max_skips`	3	Cuántas veces se puede aplazar el aviso de configuración una vez pasado el plazo.
`2fa_enforce_action`	enroll	Qué ocurre cuando se agotan el plazo y los aplazamientos. Con el valor `lockout` se rechaza el inicio de sesión, salvo para administradores y superadministradores, que nunca quedan bloqueados para que un sitio no se quede sin cuenta utilizable.
`2fa_trusted_device_days`	30	Cuánto tiempo sigue siendo de confianza un dispositivo antes de volver a pedir el segundo factor.
`2fa_ip_allowlist`	vacío	IP o bloques CIDR que se saltan el desafío (IPv4 e IPv6). Útil para un rango de oficina, arriesgado para cualquier cosa dinámica.
`2fa_enforce_super_admins`	true	Los superadministradores de multisitio siempre necesitan un segundo factor.

Los intentos fallidos escalan por IP en una escalera fija que comparten todos los métodos 2FA: 3 fallos cuestan 30 segundos, 5 cuestan 5 minutos, 10 cuestan 30 minutos, 15 cuestan una hora. Los endpoints de WebAuthn consultan esa escalera antes de emitir un desafío, así que los intentos automatizados contra el endpoint de aserción chocan con el mismo muro que la adivinación automatizada de códigos.

Qué detecta el contador de firmas

Cada autenticador mantiene un contador que incrementa en cada aserción e incluye en los datos firmados. El servidor guarda el último valor que vio. Si llega una aserción con un contador que no ha avanzado, o bien la llave fue clonada o bien su estado se restauró hacia atrás. Hive rechaza ese inicio de sesión, escribe un evento 2fa_webauthn_counter_regression con gravedad high junto al identificador de usuario, el de la credencial y ambos valores del contador, y dispara un hook de acción que envía un correo al titular de la cuenta. Este aviso está incluido en todos los planes.

Hay una excepción incorporada: muchas passkeys de plataforma (llavero de iCloud, Google Password Manager) informan por diseño de un contador constante en cero, porque una credencial sincronizada no tiene un único dispositivo en el que contar. Hive trata un cero almacenado y un cero declarado como algo normal y solo marca una regresión real. Clonar una YubiKey no es un ataque practicable, la clave privada nunca sale del elemento seguro, pero la comprobación no cuesta nada y detecta el caso en que se restaura la copia de un autenticador emulado.

Planifica la llave que acabarás perdiendo

Perder una llave es el único fallo realista de este montaje, así que planifícalo antes de necesitarlo. Existen cuatro alternativas, en orden decreciente de comodidad.

Una segunda llave registrada. El camino cómodo, y la razón por la que el plan Business permite varias credenciales por cuenta. Guarda la llave de respaldo en un lugar físicamente separado de la principal.
Códigos de recuperación. Códigos de un solo uso generados durante la configuración. Imprímelos o guárdalos en un gestor de contraseñas, nunca en el mismo perfil de navegador que estás protegiendo.
Un segundo método. TOTP como factor paralelo no cuesta nada y sobrevive a una llave perdida. Resiste peor el phishing, un compromiso que asumes a conciencia.
WP-CLI. Una administradora del servidor ejecuta wp reportedip 2fa reset <user_id>, que elimina todos los datos 2FA de esa cuenta y escribe un aviso en el registro de actividad, de modo que el restablecimiento queda auditado.

Hive impide un bloqueo autoinfligido concreto: borrar tu última llave cuando WebAuthn es el único método que tienes activo y tu rol está sujeto a la obligatoriedad. El borrado se rechaza con un mensaje que te pide configurar antes otro método. Fuera de ese caso, quitar una credencial la invalida al instante, que es justo lo que haces en el momento en que una llave desaparece.

Multisitio, subdominios y pruebas: donde muerde el identificador de parte confiante

El identificador de parte confiante se deriva del host de home_url(). Una credencial solo vale para ese identificador, lo que produce tres situaciones que conviene conocer antes de un despliegue y no después.

Multisitio con subdominios. Una llave registrada en shop.example.com no funciona en blog.example.com. El filtro reportedip_hive_webauthn_rp_id permite a una administradora de red devolver el dominio padre registrable (example.com) para que un solo alta cubra toda la red. Ajústalo una vez, antes del despliegue: cambiar el identificador más tarde deja huérfana cada credencial registrada con el valor antiguo.
Escritorio en otro host. Las instalaciones donde site_url() y home_url() difieren se resuelven solas, porque ambos hosts entran en la lista de orígenes aceptados. El filtro reportedip_hive_webauthn_allowed_origins cubre cualquier caso más exótico.
Copias de pruebas. Una base de datos clonada de producción arrastra credenciales de producción cuyo identificador no coincide con el host de pruebas. La aserción falla por origen o por identificador. Ese comportamiento es correcto, no un fallo. Registra allí una llave aparte, o mantén activo otro método 2FA.

Una restricción emparentada con la que tropiezan las instalaciones locales: WebAuthn necesita un contexto seguro. HTTPS, o http://localhost. Un sitio de pruebas en HTTP plano bajo una IP de red local no mostrará nunca el diálogo de la llave, y el navegador lo notifica como un error de seguridad en vez de como una función ausente.

Nueve errores que verás de verdad, y qué significan

Los navegadores informan de los errores de WebAuthn de forma deliberadamente vaga, porque los mensajes detallados filtrarían información sobre las credenciales registradas. Hive traduce las excepciones del navegador a textos accionables, y la tabla siguiente las devuelve a sus causas.

Mensaje o excepción	Causa	Solución
`NotAllowedError` («request timed out or was cancelled»)	La ceremonia pasó de 120 segundos, se cerró el diálogo o nunca se tocó la llave. El caso NFC más habitual: la llave se sostuvo contra la parte equivocada del teléfono.	Reintentar y, en el móvil, sostener la llave plana contra la antena, normalmente en el tercio superior de la parte trasera.
`SecurityError`	El origen de la página no coincide con el identificador de parte confiante de la credencial. Clon de pruebas, subdominio distinto o un sitio accesible con www y sin www.	Iniciar sesión en el host canónico, o fijar el filtro de identificador antes del despliegue.
`InvalidStateError` en el registro	Esta llave ya está dada de alta en esta cuenta. El servidor envía los identificadores existentes en `excludeCredentials` y el autenticador rechaza el duplicado.	No hay nada que corregir. Usa la llave que ya registraste, o registra otra distinta.
`AbortError`	Otra petición WebAuthn tomó el control, o la página cambió en mitad de la ceremonia.	Reintentar en una página de desafío recién cargada.
«Challenge expired, please start again»	Pasaron más de 300 segundos entre abrir el diálogo y responder.	Volver a empezar la ceremonia.
«Signature counter anomaly»	El contador no avanzó. Autenticador clonado o revertido, o imagen de emulador restaurada.	Tratarlo como un incidente: revocar la credencial, registrar una llave nueva, revisar el registro de actividad.
«Too many registration attempts»	Diez ceremonias de alta iniciadas en diez minutos.	Esperar unos minutos. Durante las pruebas es lo esperable.
«Security keys are not available on this site»	El método WebAuthn está apagado en la lista de métodos permitidos.	Volver a activarlo en la página Protection.
«Multiple security keys per account require the Business plan»	Se intentó una segunda credencial en un plan que incluye una.	Usar códigos de recuperación o un segundo método como respaldo, o comparar planes en la página de precios.

Hay un síntoma que no es ningún error: una ristra de caracteres aleatorios que aparece en el campo de contraseña, normalmente empezando por cccc. Eso es Yubico OTP. La llave tecleó una contraseña de un solo uso porque se la tocó mientras un campo de texto tenía el foco, fuera de cualquier ceremonia WebAuthn. Vacía el campo y lanza la ceremonia desde su propio botón.

NFC en el móvil: qué funciona y qué no

El NFC es la parte del montaje que más confusión genera, porque el fallo se manifiesta como silencio y no como un mensaje. Tres cosas deciden si el acercamiento funciona.

La posición. La antena no está en el centro del teléfono. En la mayoría de los Android queda en el tercio superior de la parte trasera; en los iPhone, en el borde de arriba. Sostén la llave plana y quieta uno o dos segundos en vez de moverla de un lado a otro.
Las fundas. El plástico fino no estorba. Las placas metálicas para soportes magnéticos de coche, las fundas con batería gruesas y algunas fundas cartera bloquean el campo por completo.
El tiempo. Despertar el teléfono, encontrar la llave y colocarla lleva con frecuencia más de los 60 segundos que WebAuthn prevé por defecto. Hive sube el tiempo de ceremonia a 120 segundos justo por eso, y ese valor es una constante en la clase WebAuthn, no un ajuste.

En iOS el navegador muestra una hoja del sistema que te pide acercar la llave a la parte superior del dispositivo antes de que empiece la ceremonia. En Android el aviso varía según la versión de Chrome, y si el NFC está apagado en los ajustes del sistema, el navegador ofrece en silencio el flujo por código QR en un segundo dispositivo. Activar el NFC en los ajustes rápidos es la solución en la que nadie piensa.

Hooks, filtros y WP-CLI para desarrolladores

La implementación de WebAuthn expone tres filtros y tres hooks de acción. Los filtros dan forma a la ceremonia; con las acciones conectas los eventos del ciclo de vida de las llaves a tu propia auditoría o a tus alertas.

Hook	Tipo	Uso
`reportedip_hive_webauthn_rp_id`	Filtro	Devuelve el dominio padre registrable para multisitio con subdominios. Ajustar una vez, antes del despliegue.
`reportedip_hive_webauthn_allowed_origins`	Filtro	Añade orígenes aceptados en instalaciones con dominios mapeados o hosts separados.
`reportedip_hive_webauthn_user_verification`	Filtro	Sube el valor a `preferred` o `required`. La bandera UV se exige entonces en el servidor en cada ceremonia.
`reportedip_hive_2fa_webauthn_key_registered`	Acción	Se dispara con el identificador de usuario y el nombre de la llave después de guardar una credencial.
`reportedip_hive_2fa_webauthn_key_removed`	Acción	Se dispara con el identificador de usuario y el nombre de la llave después de borrar una credencial.
`reportedip_hive_2fa_webauthn_counter_regression`	Acción	Se dispara con el identificador de usuario, el de la credencial y el nombre de la llave cuando se rechaza una aserción por contador estancado.

En la línea de comandos, wp reportedip 2fa status lista cada usuario con sus métodos configurados y si le afecta la obligatoriedad, que es la forma más rápida de auditar un despliegue. wp reportedip 2fa enforce --role=editor añade un rol a la lista de obligados y --remove lo quita. El comando que merece una advertencia es wp reportedip 2fa enable --method=webauthn: marcar el método para un usuario que no tiene ninguna credencial registrada es un bloqueo, no una configuración, así que el comando se niega mientras no pases --force.

¿Qué llaves de seguridad funcionan con WordPress y Hive?

Funciona cualquier autenticador FIDO2/WebAuthn. Nosotros probamos con la serie YubiKey 5, y el mismo flujo de alta acepta los modelos Security Key by Yubico, llaves FIDO2 de otros fabricantes y passkeys de plataforma como Windows Hello, el llavero de iCloud, Google Password Manager, 1Password o Bitwarden.

En el plan Business el gestor de llaves nombra el hardware en vez de mostrar una etiqueta genérica. Eso viene de un registro AAGUID estático incluido en el plugin: 90 identificadores de autenticador asignados a 32 nombres de modelo, las entradas de Yubico tomadas del FIDO Alliance Metadata Service y los proveedores de plataforma de la lista AAGUID de la comunidad. La consulta es solo para mostrar y nunca alimenta una decisión de política, así que un AAGUID desconocido simplemente cae en la etiqueta genérica. No hay consulta en tiempo de ejecución ni tarea cron detrás; la lista se actualiza cuando sale hardware nuevo.

Si ya usas passkeys, la guía de inicio de sesión con passkeys explica cómo se relacionan ambas. En resumen: una llave de hardware es una passkey que puedes sostener en la mano, que no le prestas a nadie y que puedes dejar en una caja fuerte.

Cómo usamos y probamos la YubiKey 5C NFC

No elegimos este modelo para el artículo. El artículo existe porque usamos este modelo. La YubiKey 5C NFC protege nuestras propias cuentas, y esa misma llave física es la puerta de publicación del soporte WebAuthn de Hive: ninguna versión que toque la ruta 2FA sale hasta que la llave ha completado alta e inicio de sesión en un sitio de pruebas a lo largo de cinco combinaciones de plataforma y transporte. Windows 11 con Chrome y con Edge por USB-C, Android Chrome e iPhone Safari por NFC, y macOS Safari por USB-C. La matriz comprueba además que una segunda llave se registra limpiamente, que una llave ajena se rechaza y que una ceremonia cancelada y repetida se recupera sin recargar la página.

La cobertura automatizada corre en integración continua con Playwright y el autenticador virtual de Chromium en cada compilación. Detecta rápido y barato las regresiones de protocolo, y es ciega a todo lo físico: la colocación NFC, los contadores de firma reales, la sensación de un tiempo de espera de 120 segundos y el caso del toque accidental en que una YubiKey teclea su contraseña de un solo uso en un formulario porque alguien la rozó a mitad de sesión. Esa distancia entre emulación y hardware es la razón de que una llave física siga en el proceso de publicación.

Un plan de despliegue para un equipo

Pasar a todo un equipo editorial a llaves de hardware falla de formas predecibles. Esta secuencia evita casi todas.

Compra dos llaves por cada cuenta con privilegios. Un despliegue con una sola llave por persona crea una cola de soporte tres meses después, cuando la primera pase por la lavadora.
Da de alta tu propia cuenta primero y cierra sesión del todo. Comprueba el inicio de sesión en una ventana privada antes de tocar la cuenta de otra persona.
Haz obligatorio un rol cada vez, empezando por los administradores. El plazo predeterminado de 7 días más 3 aplazamientos da a la gente dos ocasiones reales de darse de alta sin abrir un ticket.
Mantén activo un método sin WebAuthn durante el despliegue. TOTP no cuesta nada y evita el único escenario que daña la confianza en todo el proyecto: un redactor bloqueado fuera a la hora del cierre.
Audita con wp reportedip 2fa status antes de apretar 2fa_enforce_action hasta lockout. El comando muestra a quién le falta todavía un método.
Anota dónde están las llaves de respaldo. Una llave de respaldo que nadie encuentra no es una copia de seguridad.

Preguntas frecuentes

¿Qué pasa si pierdo mi YubiKey?

Inicias sesión con tu respaldo: una segunda llave registrada, códigos de recuperación o cualquier otro método 2FA activo. Después quitas la llave perdida de tu perfil, lo que invalida su credencial al instante. Si no existe ninguna alternativa, una administradora del sitio restablece la 2FA con wp reportedip 2fa reset <user_id>, y ese restablecimiento queda en el registro de actividad.

¿Funciona la YubiKey 5C NFC con mi teléfono?

Sí. En Android y iPhone se sostiene la llave plana contra la antena NFC, normalmente en el tercio superior de la parte trasera o en el borde de arriba, cuando el navegador la pide. El tiempo de ceremonia de 120 segundos de Hive existe precisamente porque encontrar la posición lleva un momento. Las fundas gruesas o con trasera metálica bloquean el campo.

¿Necesito un plan de pago para usar una YubiKey con Hive?

No. Una llave de seguridad o passkey por cuenta es gratuita en todos los planes, incluido el inicio de sesión en las tres superficies, el renombrado, el borrado y el correo de aviso por llave clonada. Business añade varias llaves por cuenta, la detección automática del modelo y los avisos del ciclo de vida de las llaves.

¿Dar de alta un sitio WordPress gasta una de las 25 ranuras de passkey?

No. Hive registra una credencial no detectable, así que la llave no guarda nada y el número de ranuras queda intacto. Una YubiKey puede proteger así un número ilimitado de sitios WordPress.

¿Funcionará mi llave en una copia de pruebas del sitio?

No con credenciales clonadas de producción. Una credencial está ligada al identificador de parte confiante derivado del host del sitio, así que un dominio de pruebas la rechaza por no coincidir el origen o el identificador. Registra allí una llave aparte, o deja activo otro método 2FA.

¿Tengo que poner un PIN FIDO2?

Para el uso como segundo factor, no. Hive pide userVerification: 'discouraged', de modo que una llave nueva nunca desencadena la creación de un PIN durante el inicio de sesión. Los sitios que quieren que la llave verifique al usuario suben la regla con el filtro reportedip_hive_webauthn_user_verification.

¿Es mejor una llave de hardware que una passkey en mi gestor de contraseñas?

Ambas resisten el phishing. La diferencia está en la custodia: una passkey sincronizada es tan segura como la cuenta por la que se sincroniza, mientras que la clave privada de una llave de hardware no puede salir físicamente del dispositivo. Para una cuenta de administrador de WordPress, un objetivo que merece un ataque dirigido, usamos llaves de hardware y guardamos una passkey sincronizada como alternativa cómoda.

¿Puedo usar una llave para varios sitios WordPress?

Sí, y sin límite práctico. Cada sitio genera su propio par de claves limitado a su propio dominio, y ninguno de esos pares ocupa almacenamiento en la llave.