¡Un gran avance para AltaPass! Compatibilidad con múltiples contraseñas en WPA3 y 6 GHz mediante DecoyAuth

Nos complace anunciar que DecoyAuth ya está disponible en el Alta Labs AP7-Pro con firmware 3.0m o posterior. Puedes probar el cliente en Ubuntu mediante nuestro PPA hostap-decoyauth, que también ofrece hostapd para experimentar con puntos de acceso Linux. El objetivo es práctico: autenticar a los usuarios únicamente según la contraseña Wi-Fi que introduzcan, sin nombres de usuario ni identificadores de contraseña.

Te invitamos a probar esta extensión de protocolo emergente, con el objetivo de que todos los clientes Wi-Fi la admitan a corto plazo. Ambos extremos deben ser compatibles con DecoyAuth para utilizar el conjunto completo de contraseñas. A continuación explicamos por qué importa, cómo probarlo y qué demuestran —y qué no— las pruebas disponibles hasta ahora.

Por qué es importante recuperar el uso de varias contraseñas

En un edificio de apartamentos, un único nombre de red no debería obligar a todos los inquilinos a compartir una contraseña. Los edificios con múltiples viviendas, las residencias de estudiantes y otras redes compartidas necesitan credenciales que se puedan emitir y revocar fácilmente para cada hogar o dispositivo. Cuando un inquilino se marcha, el operador debe poder revocar su acceso sin afectar al de los demás.

Las instalaciones WPA2 —todavía hoy— resuelven esto con varias claves precompartidas, a menudo denominadas MPSK o PPSK. Alta Labs tiene su propia solución, AltaPass, con varias mejoras de escalabilidad. Con ellas, los fabricantes pueden aceptar varias contraseñas en un mismo SSID y asociar la credencial correspondiente a la política de un inquilino, pero esta solución se basa en criptografía de hace más de 20 años.

WPA3 llegó en 2018 con una valiosa mejora de seguridad: SAE, un intercambio de claves autenticado mediante contraseña diseñado para resistir ataques pasivos de adivinación de contraseñas sin conexión. Sin embargo, la transición no conservó el conocido proceso de varias contraseñas sin identificadores. Un punto de acceso no puede limitarse a reutilizar el método de WPA2, que prueba claves candidatas durante el intercambio de cuatro mensajes. En SAE, la contraseña interviene antes.

Este es el retroceso práctico que el sector Wi-Fi necesita resolver desde 2018. Más concretamente, el despliegue de WPA3 por parte de Wi-Fi Alliance, basado en SAE según la definición del IEEE, dejó atrás este modelo de implementación. No hizo imposibles todas las formas de autenticación multiusuario: WPA3-Enterprise sigue siendo una opción, y los identificadores de contraseña SAE permiten distinguir contraseñas si los clientes los admiten y están configurados para utilizarlos. Ninguna de estas opciones sustituye sin cambios la experiencia de pedir a un residente que introduzca únicamente su contraseña. Para más información, consulta la presentación de Mathy Vanhoef sobre PAKE: presentación de Mathy Vanhoef en el taller sobre PAKE

El paso a 6 GHz hizo que esta carencia fuera más difícil de evitar. En esa banda, las redes personales protegidas por contraseña deben usar WPA3-SAE, en lugar de WPA2-PSK o el modo de transición WPA2/WPA3. Los operadores no pueden trasladar sin más un diseño antiguo de múltiples contraseñas WPA2 a 6 GHz.

La investigación detrás de DecoyAuth

Una subvención de NGI Sargasso respaldó la colaboración de investigación sobre DecoyAuth entre KU Leuven y Alta Labs. Alta Labs también patrocinó el trabajo de Mathy Vanhoef sobre la base criptográfica de este proyecto. Esta colaboración trasladó el problema operativo a un investigador capaz de abordar el propio protocolo de autenticación, en vez de presentar una alternativa basada en WPA2 como si fuera una solución WPA3. Encontrarás más detalles aquí: ficha del proyecto en NGI Sargasso

El diseño de Vanhoef se basa en Dragonfly y en técnicas conocidas como oblivious password-authenticated key exchange (O-PAKE), un intercambio de claves autenticado mediante contraseña. El punto de acceso codifica las respuestas del intercambio en función de las contraseñas; el cliente usa su contraseña para recuperar la respuesta correspondiente y completar la autenticación. El punto de acceso comprueba la confirmación frente a las contraseñas candidatas para identificar la credencial aceptada. No difunde una lista de contraseñas en texto claro, ni siquiera hashes de las contraseñas. Esto permite que la red asocie la contraseña autenticada con la política de un inquilino. El documento técnico está disponible aquí: documento técnico del protocolo, y la especificación de integración, aquí: especificación de integración Wi-Fi

El nombre procede del objetivo de investigación de detectar el uso de credenciales señuelo. Aunque esto puede servir para detectar credenciales comprometidas mediante un honeypot, también puede constituir la base de una autenticación basada exclusivamente en la contraseña introducida. El código y los artículos de investigación son públicos para que implementadores y criptógrafos puedan examinar el diseño: repositorio de investigación de DecoyAuth

Qué cambiamos respecto a la implementación de investigación

La implementación original de hostap de Mathy Vanhoef fue el punto de partida para llevar el diseño criptográfico a Wi-Fi. Nuestra implementación se basa en ese trabajo e introduce cambios en la derivación de elementos de contraseña, el intercambio por radio, la política de implementación y la integración operativa. Estas son ampliaciones de la implementación; no afirmamos haber inventado la construcción subyacente de DecoyAuth.

H2E sustituye a hunting and pecking en DecoyAuth. La preparación original para múltiples contraseñas admitía el método hunting and pecking (HnP) de SAE. Hemos dejado de utilizar esa vía para DecoyAuth y ahora exigimos hash-to-element (H2E), en consonancia con el método SAE requerido para WPA3-Personal en 6 GHz. Esto no elimina HnP de SAE convencional: en el modo opcional todavía se puede recurrir a SAE estándar cuando la red lo permita, pero esa alternativa no ofrece la capacidad de múltiples contraseñas de DecoyAuth.

Un nuevo intercambio fragmentado permite usar cientos de contraseñas. El código original serializaba los coeficientes polinómicos dependientes de las contraseñas directamente en una única respuesta SAE Commit del punto de acceso. El tamaño de esa carga crece con el número de contraseñas y, con conjuntos grandes, no cabe en una sola trama de gestión Wi-Fi. Añadimos una secuencia de solicitud y respuesta que divide las cargas demasiado grandes en fragmentos numerados, transportados en elementos de información específicos del fabricante dentro de tramas SAE Authentication. La estación solicita los fragmentos sucesivos, los valida y los reconstruye antes de completar el intercambio SAE Commit y Confirm. Son tramas Authentication, no tramas Action; una carga pequeña sigue cabiendo en la respuesta Commit sin intercambio adicional de fragmentos. Este transporte nos permite probar un conjunto configurado de 512 contraseñas sin quedar limitados por la capacidad de una sola trama.

Negociación explícita de capacidades y política de compatibilidad. Añadimos los modos desactivado, opcional y obligatorio; el opcional es el predeterminado. La estación anuncia su compatibilidad con DecoyAuth para que el punto de acceso pueda seleccionar el intercambio adecuado. En modo opcional, una estación antigua puede usar la primera contraseña coincidente mediante SAE convencional; el modo obligatorio rechaza los intentos SAE que no negocian DecoyAuth. Tanto el punto de acceso como la estación necesitan la implementación actualizada para usar el intercambio ampliado.

Integración más allá del intercambio inicial. Añadimos caché de matrices de interpolación y preparación en segundo plano para conjuntos de contraseñas más grandes, así como análisis de cargas útiles con límites definidos y reconstrucción de fragmentos. También añadimos compatibilidad con operaciones MLO y FT-SAE. Las pruebas siguientes examinan estos comportamientos de implementación, además de la demostración criptográfica.

Todos estos cambios se han enviado al proyecto de código abierto hostap para su revisión, con vistas a incorporarlos al supplicant Wi-Fi más utilizado, presente en miles de millones de dispositivos en todo el mundo.

Cómo instalar y probar DecoyAuth

Usa un AP7-Pro con firmware 3.0m o posterior y un cliente Linux con la versión modificada de wpasupplicant. Crea un SSID específico para pruebas con al menos dos contraseñas diferentes mediante la configuración de múltiples contraseñas del punto de acceso. Configura WPA3 como obligatorio en el SSID de prueba.

Instala los paquetes de Ubuntu

Hazlo desde una consola local o con una conexión de recuperación por cable. Estos paquetes sustituyen el software Wi-Fi del sistema, y la instalación o el reinicio pueden interrumpir la conectividad. No uses la red que vas a modificar como única vía de acceso remoto.

sudo apt update

sudo apt install software-properties-common

sudo add-apt-repository ppa:sqrammi/hostap-decoyauth

sudo apt update

apt-cache policy wpasupplicant hostapd

sudo apt install wpasupplicant

Comprueba que tanto la versión candidata como la instalada procedan del PPA e incluyan +decoyauth. Instala hostapd si también quieres probar una máquina Linux como punto de acceso:

sudo apt install hostapd

dpkg-query -W wpasupplicant hostapd

Reinicia el cliente de prueba cuando te convenga para asegurarte de que utilizas el nuevo supplicant y no un proceso cargado anteriormente. Si hostapd no está instalado, el comando dpkg-query indicará que falta ese paquete; para probar el cliente solo se necesita wpasupplicant.

Estado de publicación de los paquetes a 11 de septiembre de 2026: el mismo PPA contiene versiones de código fuente distintas para Ubuntu 24 Noble y Ubuntu 26 Resolute. Consulta la lista de paquetes del PPA

Conectarse con las contraseñas A y B

Cuando NetworkManager utiliza el backend wpa_supplicant actualizado, el proceso habitual de seleccionar el SSID e introducir la contraseña usará DecoyAuth automáticamente si el punto de acceso lo admite.

Prueba a conectarte primero con la contraseña A y después con la B. Si configuraste cada contraseña para conectar a una VLAN distinta, verás que la subred cambia según la contraseña introducida.

Si quieres hacer una prueba manual, asegúrate de que ni NetworkManager ni ningún otro proceso gestionen la interfaz Wi-Fi; después, usa una configuración similar a esta:

ctrl_interface=/run/wpa_supplicant

sae_pwe=1

network={

ssid="DecoyAuth-Test"

key_mgmt=SAE

ieee80211w=2

psk="passwordB"

decoyauth=2

}

sudo wpa_supplicant -Dnl80211 -i wlan0 \

-c /path/to/decoyauth-test.conf -d

Este comando en primer plano realiza la autenticación y asociación Wi-Fi; no configura DHCP, el enrutamiento ni DNS. Para detenerlo, pulsa Ctrl+C y, cuando termines, devuelve la interfaz a su gestor habitual.

Probar el modo de punto de acceso Linux, si quieres

El paquete hostapd permite una segunda vía de prueba: un punto de acceso Linux con un adaptador compatible. Un dispositivo Intel iwlwifi podría funcionar como punto de acceso en 2,4 GHz, pero esto depende del chipset, el firmware y el controlador concretos. Comprueba los modos de interfaz admitidos con iw list. La marca Intel, por sí sola, no confirma la compatibilidad. Usa una interfaz dedicada que no esté gestionada simultáneamente por NetworkManager u otro servicio de punto de acceso.

Para un laboratorio que solo pruebe la autenticación, la configuración de hostapd puede ser como la siguiente. Cambia la interfaz, las credenciales y el canal según sea necesario, y respeta la normativa local sobre el espectro radioeléctrico:

interface=wlan0

driver=nl80211

ssid=DecoyAuth-Test

hw_mode=g

channel=1

wpa=2

wpa_key_mgmt=SAE

rsn_pairwise=CCMP

ieee80211w=2

sae_pwe=1

decoyauth=2

sae_password=replace-with-password-A

sae_password=replace-with-password-B

Después, ejecuta esta configuración con:

sudo hostapd -d /path/to/hostapd-decoyauth.conf

Esta no es una configuración completa para compartir Internet. El puente o enrutamiento, DHCP y las reglas del cortafuegos deben configurarse por separado.

Qué demuestran las pruebas hasta ahora

Nuestras pruebas Wi-Fi automatizadas de DecoyAuth se centran en lo que sucede en la red: qué contraseñas conceden acceso, qué VLAN recibe un cliente y si esa identidad se conserva tras volver a conectarse, al usar varios enlaces y durante la itinerancia. Cuando corresponde, el conjunto de pruebas examina estos comportamientos con MLO activado y desactivado.

Rechazo de una contraseña no incluida en la lista. Una contraseña ausente de la lista configurada debe fallar en la autenticación SAE, no llegar nunca al estado de conexión y no dejar una identidad de contraseña autorizada en el punto de acceso. Después, la prueba se conecta con una contraseña válida y comprueba que el acceso normal se recupera tras el rechazo.

Contraseñas diferentes seleccionan VLAN diferentes. El conjunto de pruebas se conecta con cuatro contraseñas configuradas y asignadas alternativamente a VLAN 1 y VLAN 2. Comprueba la identidad de contraseña seleccionada en el punto de acceso, la subred IP esperada para el cliente, la accesibilidad de la puerta de enlace y el tráfico enrutado. Esto verifica que las contraseñas A y B pueden dar acceso a redes distintas bajo el mismo SSID, y no solo permitir que ambos clientes se asocien.

Un conjunto configurado de 512 contraseñas. La prueba de escala carga 512 contraseñas distintas, las asigna alternativamente a VLAN 1 y VLAN 2 y se conecta con cuatro entradas elegidas al azar. Cada conexión muestreada debe recibir la VLAN y la identidad de contraseña correctas.

Unos 10 segundos para la primera conexión. En nuestras pruebas con el AP7-Pro y 512 contraseñas, la primera conexión tarda unos 10 segundos mientras el punto de acceso prepara los datos de interpolación. El conjunto de pruebas también comprueba que las conexiones posteriores reutilizan el archivo de caché de matrices del punto de acceso en lugar de reconstruirlo, y registra los tiempos de cálculo en frío y en caliente cuando los registros los proporcionan. Ese resultado aproximado de 10 segundos es el tiempo observado para una primera conexión, no una demora fija para todas las conexiones ni una garantía en todas las condiciones de hardware y radio. La caché de matrices reduce el tiempo de conexión a 1-2 segundos, y FT reduce el tiempo de itinerancia a menos de 100 ms, según lo previsto.

Caché PMKSA y reconexiones. Tras autenticarse con una contraseña no principal asignada a VLAN 2, la prueba comprueba que existe una entrada PMKSA y que el supplicant intenta reutilizarla durante la reasociación. Verifica que la identidad de contraseña y la VLAN siguen siendo correctas; luego vuelve a aprovisionar el SSID del punto de acceso y comprueba que la reconexión restablece la misma política y el mismo acceso a la red. La caché PMKSA y la caché de interpolación del punto de acceso son mecanismos distintos: una almacena material de claves de autenticación y la otra evita repetir la preparación del conjunto de contraseñas.

Coherencia de políticas MLO y recuperación de enlaces. Con MLO activado, el conjunto de pruebas comprueba que al menos dos enlaces activos coinciden en la identidad de contraseña autenticada y la VLAN. Elimina dinámicamente un enlace del punto de acceso que no se utilizó para la asociación y comprueba que se mantiene el acceso a la puerta de enlace de VLAN 2. Tras restaurar los enlaces del punto de acceso y volver a asociarse, verifica que se conservan la misma identidad de contraseña, la VLAN y el acceso enrutado.

Itinerancia Fast Transition. La prueba FT comienza con una autenticación DecoyAuth y luego realiza una itinerancia FT-SAE por radio entre dos puntos de acceso. Comprueba que FT se completa correctamente tanto en el cliente como en el punto de acceso de destino, que se mantienen la identidad de contraseña y el acceso a VLAN 2, y que los registros muestran que ninguno de los extremos repite el intercambio DecoyAuth ni la preparación del punto de acceso durante la itinerancia. En la parte de la prueba con MLO, también verifica que las direcciones locales de los enlaces de la estación se mantienen constantes.

Requisito del kernel para la itinerancia FT con MLO. En los kernels Linux afectados, probar Fast Transition junto con MLO también requiere una corrección de mac80211 que conserve las direcciones MAC de los enlaces de la estación durante la itinerancia. Sin ella, el punto de acceso puede rechazar la reasociación porque esas direcciones ya no coinciden con la comprobación de integridad FT. Instalar nuestros paquetes hostapd y wpasupplicant desde el PPA no instala esta corrección del kernel. Se trata de un requisito independiente de DecoyAuth que no se aplica, en general, a las pruebas básicas con múltiples contraseñas.

Descarga el parche mac80211 para FT/MLO. Prevemos enviar este parche al proyecto principal del kernel Linux.

Cambios de contraseña y compatibilidad. Otros casos invierten el orden de la lista de contraseñas sin cambiar la identidad ni la VLAN de la contraseña seleccionada; sustituyen una contraseña de modo que se rechace el valor anterior y el nuevo conserve su política de VLAN; y prueban la compatibilidad del modo opcional. Un cliente con DecoyAuth desactivado puede usar la contraseña principal, pero no la secundaria; al activar DecoyAuth, puede usar esa misma contraseña secundaria. Las pruebas PWE sin MLO también comprueban el funcionamiento de H2E, el rechazo de SAE con hunting and pecking cuando DecoyAuth es obligatorio y el uso de SAE estándar como alternativa cuando DecoyAuth es opcional.

¡Queremos conocer tus resultados!

Si tus pruebas tienen éxito, cuéntanoslo en nuestro foro (forum.alta.inc) e incluso en redes sociales. Llegar hasta aquí nos ha llevado varios años, así que puede pasar algún tiempo antes de que los principales fabricantes de clientes admitan esta función. Cuanto más se hable de resolver el problema, mejor.

Una prueba útil demuestra un intercambio SAE completo con una contraseña distinta de la primera configurada. En una autenticación nueva, busca en el registro del cliente los mensajes de procesamiento de valores DecoyAuth y la confirmación de que se ha completado la conexión. Las reconexiones con PMK en caché o mediante Fast Transition pueden omitir un nuevo intercambio SAE; por ello, borra el estado en caché o usa un perfil de prueba nuevo cuando compruebes la negociación.

Prueba cada contraseña válida y después una no configurada. Las credenciales válidas deben conectar; la no configurada debe fallar. Comprueba que el método de autenticación negociado es SAE y que la prueba sin recurrir a la alternativa utilizó realmente DecoyAuth.
Aumenta la cantidad de contraseñas y repite las conexiones en frío y en caliente. En esta implementación, las cargas codificadas de mayor tamaño utilizan fragmentos adicionales de tramas de autenticación.
Prueba cada banda por separado y, después, MLO y la itinerancia en las versiones compatibles. Comprueba la conectividad IP y la VLAN prevista, y verifica activamente que un inquilino no pueda acceder a la red protegida de otro.
Indica el modelo y firmware del punto de acceso, la versión de Ubuntu y del paquete, el chipset del cliente, el kernel y el controlador, la banda, el canal, la cantidad de contraseñas, el modo de política, los intentos, los éxitos y los síntomas de los fallos.

Mantén una vía de recuperación por cable. Para devolver los paquetes instalados a las versiones del archivo de Ubuntu, usa ppa-purge desde esa conexión de recuperación y revisa los cambios propuestos antes de aprobarlos:

sudo apt install ppa-purge

sudo ppa-purge ppa:sqrammi/hostap-decoyauth

Eliminar simplemente el PPA no devuelve los paquetes ya instalados desde él a sus versiones anteriores. Tras la reversión, reinicia los servicios correspondientes o el equipo para cargar los binarios restaurados.

Los identificadores de contraseña no recuperan el Wi-Fi basado únicamente en contraseñas

Los identificadores de contraseña SAE permiten que un punto de acceso seleccione entre varias contraseñas, pero obligan al cliente a proporcionar un identificador adicional, que en la práctica equivale a un nombre de usuario. Sin aprovisionamiento automático, el inquilino debe introducir tanto el identificador como la contraseña. Los códigos QR pueden contener ambos datos, pero sigue siendo necesario ese aprovisionamiento adicional y no hay compatibilidad retroactiva con las configuraciones WPA2-PSK existentes. Esto cambia la experiencia habitual de entrada en una vivienda de un edificio multifamiliar: elegir la red e introducir la contraseña.

El mecanismo de rotación de identificadores 802.11bi mejora la privacidad en las conexiones posteriores, pero no protege automáticamente la primera. En la implementación actual de hostap, un cliente sin alias cifrados aprovisionados previamente envía su identificador original en texto claro antes de autenticar al punto de acceso. Los alias posteriores ocultan ese identificador, pero los alias reutilizados siguen siendo reconocibles. La implementación también descarta los alias tras mensajes de rechazo no autenticados y vuelve al identificador original cuando ya no queda ninguno: una posible vía para que un punto de acceso malicioso vuelva a exponerlo.

El espacio reservado a los identificadores de contraseña también es extremadamente pequeño: solo permite unos 5 identificadores, muy lejos de las 512 contraseñas que admite esta implementación de DecoyAuth.

Estos mecanismos pueden admitir varias contraseñas, pero no ofrecen el proceso sin identificadores que buscamos recuperar. Con DecoyAuth, la propia contraseña selecciona la política de acceso adecuada, sin necesidad de introducir, aprovisionar ni transmitir un identificador aparte.

‍

El riesgo cuántico no justifica dejar este problema sin resolver

Ni el diseño actual de DragonFly ni el de DecoyAuth, ambos basados en curvas elípticas, son seguros frente a ataques cuánticos. Conviene decirlo claramente. Un ordenador cuántico suficientemente potente pondría en peligro sus supuestos fundamentales, igual que los de otros sistemas clásicos de clave pública ampliamente utilizados.

Pero la ausencia de seguridad poscuántica no justifica ignorar un problema real de gestión del acceso surgido con la transición a WPA3 en 2018 y agravado por los 6 GHz. No existe una fecha fiable para el «Q-Day». Mientras tanto, inquilinos y operadores necesitan una separación de credenciales que funcione. Información del NIST sobre criptografía poscuántica

Aunque el «Q-Day» esté cerca, renunciar a la facilidad de uso de varias contraseñas no es la respuesta. Debemos mejorar el sistema actual mientras desarrollamos e implantamos un sucesor poscuántico sometido a revisión que conserve esta capacidad.

Prueba el PPA, somete la implementación a examen y comparte resultados reproducibles. Recuperar un Wi-Fi práctico con múltiples contraseñas y prepararse para una autenticación resistente a ataques cuánticos son dos tareas necesarias.