Historia del Clickjacking (2002–2025)

El clickjacking se ha convertido en el parásito persistente de la web moderna. El término surgió a principios de los 2000, cuando Jeremiah Grossman y Robert Hansen describieron un escenario engañoso: inducir al usuario a hacer clic en algo que en realidad no podía ver. Una ilusión óptica aplicada al código, pronto se convirtió en una técnica de ataque de referencia (OWASP).

• 2002–2008: Aparición del “UI redressing”: capas HTML + iframes transparentes atrapando al usuario (Archivo Hansen).
• 2009: Facebook cae víctima del Likejacking (OWASP).
• 2010: Surge el Cursorjacking — desplazar el puntero para manipular clics (OWASP).
• 2012–2015: Explotación vía iframes, anuncios online y malvertising (MITRE CVE) (Infosec).
• 2016–2019: El tapjacking se extiende en móviles Android (Android Security Bulletin).
• 2020–2024: Auge del “clickjacking híbrido” combinando XSS y phishing (OWASP WSTG).
• 2025: En DEF CON 33, Marek Tóth presenta un nuevo nivel: Clickjacking de Extensiones DOM. Esta vez no solo los sitios web, sino también las extensiones del navegador (gestores de contraseñas, billeteras cripto) inyectan formularios invisibles, habilitando la exfiltración sigilosa de secretos.

En DEF CON 33, Tóth reveló públicamente el clickjacking de extensiones DOM, marcando un cambio estructural: de un truco visual a una debilidad sistémica en gestores de contraseñas y wallets cripto.

¿Qué es el Clickjacking de Extensiones DOM? Definición, Flujo de Ataque y Defensa Zero-DOM

El clickjacking extensiones DOM secuestra un gestor de contraseñas o una billetera cripto aprovechando el Document Object Model del navegador. Una página maliciosa encadena iframes invisibles, Shadow DOM y una llamada maliciosa a focus() para forzar el autocompletado en un formulario oculto. La extensión “cree” que está rellenando el campo correcto y vierte secretos — credenciales, TOTP, llaves de acceso (passkeys), incluso claves privadas de wallets — directamente en la trampa del atacante. Al tocar el DOM, los secretos pueden ser exfiltrados en silencio.

Idea clave: mientras los secretos atraviesen el DOM, la superficie de ataque persiste. Las arquitecturas Zero-DOM la eliminan.

El clickjacking de extensiones DOM no es una variante trivial: explota la lógica misma del autocompletado de gestores de contraseñas. Aquí, el atacante no superpone un botón con un iframe; en cambio, obliga a la extensión a completar un formulario falso como si fuera legítimo.

Secuencia típica de ataque:

• Preparación — La página maliciosa incrusta un iframe invisible y un Shadow DOM oculto para disfrazar el contexto real.
• Cebo — La víctima hace clic en un elemento aparentemente inocente; una llamada maliciosa a focus() redirige silenciosamente el evento al campo controlado por el atacante.
• Exfiltración — La extensión cree que interactúa con un formulario válido e inyecta automáticamente credenciales, TOTP, passkeys o incluso claves privadas cripto en el DOM falso.

Este mecanismo sigiloso confunde las señales visuales, evade defensas tradicionales (X-Frame-Options, CSP, frame-ancestors) y convierte el autocompletado en un canal de exfiltración de datos encubierto. A diferencia del clickjacking clásico, el usuario no es engañado para hacer clic en un sitio externo: es la propia extensión del navegador la que se traiciona al confiar en el DOM.

Glosario

• DOM (Document Object Model): estructura interna del navegador que representa los elementos de una página.
• Clickjacking: técnica que engaña al usuario para hacer clic en elementos ocultos o disfrazados.
• Shadow DOM: subárbol encapsulado y oculto del DOM, usado para aislar componentes.
• Zero-DOM: arquitectura de seguridad en la que los secretos nunca tocan el DOM, eliminando riesgos de inyección.

Vulnerabilidades de Gestores de Contraseñas (2025)

Al 27 de agosto de 2025, las pruebas en vivo de Marek Tóth durante DEF CON 33 confirmaron que la mayoría de los gestores de contraseñas basados en navegador siguen expuestos estructuralmente al clickjacking extensiones DOM.

De 11 gestores probados, 10 filtraron credenciales, 9 expusieron códigos TOTP y 8 revelaron passkeys.

En resumen: incluso la bóveda más confiada puede volverse porosa cuando delega secretos al DOM.

• Aún vulnerables: 1Password, LastPass, iCloud Passwords, LogMeOnce
• Corregidos: Bitwarden, Dashlane, NordPass, ProtonPass, RoboForm, Enpass, Keeper (parcial)
• En proceso de corrección: Bitwarden, Enpass, iCloud Passwords
• Marcados como “informativos” (sin plan de parche): 1Password, LastPass

Tabla de Estado (Actualizada 27 de agosto de 2025)

Divulgación CVE y Respuestas de Proveedores (Ago–Sep 2025)

El descubrimiento de Marek Tóth en DEF CON 33 no podía permanecer oculto: las vulnerabilidades de clickjacking extensiones DOM están recibiendo actualmente identificadores oficiales CVE.
Sin embargo, como suele ocurrir en los procesos de vulnerability disclosure, el avance es lento. Varias fallas fueron reportadas ya en primavera de 2025, pero a mediados de agosto algunos proveedores aún no habían publicado correcciones públicas.

Respuestas de proveedores y cronología de parches:

• Bitwarden — reaccionó rápidamente con el parche v2025.8.0 (agosto 2025), mitigando fugas de credenciales y TOTP.
• Dashlane — lanzó una corrección (v6.2531.1, inicios de agosto 2025), confirmada en notas oficiales.
• RoboForm — desplegó parches en julio–agosto 2025 en versiones Windows y macOS.
• NordPass y ProtonPass — anunciaron actualizaciones oficiales en agosto 2025, mitigando parcialmente la exfiltración vía DOM.
• Keeper — reconoció el impacto, pero sigue en estado “en revisión” sin parche confirmado.
• 1Password, LastPass, Enpass, iCloud Passwords, LogMeOnce — permanecen sin parche a inicios de septiembre 2025, dejando usuarios expuestos.

El problema no es solo el retraso en los parches, sino también la manera en que algunos proveedores minimizaron el fallo. Según informes de seguridad, ciertos editores inicialmente catalogaron la vulnerabilidad como “informativa”, restándole gravedad.
En otras palabras: reconocieron la fuga, pero la relegaron a una “caja gris” hasta que la presión mediática y comunitaria los obligó a actuar.

Tecnologías de Corrección Utilizadas

Desde la divulgación pública del clickjacking extensiones DOM en DEF CON 33, los proveedores se apresuraron a lanzar parches. Sin embargo, estas correcciones siguen siendo desiguales, limitadas en su mayoría a ajustes de interfaz o comprobaciones condicionales. Ningún proveedor ha re-ingenierizado aún el motor de inyección en sí.

🔍 Antes de profundizar en los métodos de corrección, aquí tienes una vista general de las principales tecnologías desplegadas por los proveedores para mitigar el clickjacking de extensiones DOM. La infografía muestra el espectro: desde parches cosméticos hasta soluciones soberanas Zero-DOM.

Objetivo

Esta sección explica cómo intentaron los proveedores corregir la falla, distingue entre parches cosméticos y correcciones estructurales, y destaca las aproximaciones soberanas Zero-DOM en hardware.

Métodos de Corrección Observados (agosto 2025)

📉 Límites Observados

• Los parches no modificaron el motor de inyección, solo sus disparadores de activación.
• Ningún proveedor introdujo separación estructural entre interfaz y flujo de secretos.
• Cualquier gestor aún atado al DOM permanece expuesto estructuralmente a variantes de clickjacking.

Tecnologías de Corrección frente al Clickjacking de Extensiones DOM — Análisis Técnico y Doctrinal

📌 Observación

El clickjacking extensiones DOM no es un simple bug, sino un defecto de diseño: inyectar secretos en un DOM manipulable sin separación estructural ni verificación contextual.

⚠️ Lo que las correcciones actuales no abordan

• Ningún proveedor ha reconstruido su motor de inyección.
• Las correcciones se limitan a desactivar autocompletado, filtrar subdominios o detectar elementos invisibles.
• Ninguno ha integrado una arquitectura Zero-DOM que garantice inviolabilidad por diseño.

🧠 Lo que requeriría una corrección estructural

• Eliminar toda dependencia del DOM para la inyección de secretos.
• Aislar el motor de inyección fuera del navegador.
• Usar autenticación hardware (NFC, PGP, biometría).
• Registrar cada inyección en un diario auditable.
• Prohibir interacción con elementos invisibles o encapsulados.

📊 Tipología de correcciones

🧪 Pruebas doctrinales para verificar parches

Para comprobar si la corrección de un proveedor es realmente estructural, los investigadores de seguridad pueden:

• Inyectar un campo invisible (opacity:0) dentro de un iframe.
• Simular un Shadow DOM encapsulado.
• Verificar si la extensión aún inyecta secretos.
• Comprobar si la inyección queda registrada o bloqueada.

📜 Ausencia de estándar industrial

Actualmente, no existe ningún estándar oficial (NIST, OWASP, ISO) que regule:

• La lógica de inyección en extensiones,
• La separación entre interfaz y flujo de secretos,
• La trazabilidad de acciones de autocompletado.

Riesgos Sistémicos y Vectores de Explotación

El clickjacking extensiones DOM no es un fallo aislado, sino una vulnerabilidad sistémica. Cuando una extensión del navegador se derrumba, las consecuencias no se limitan a una contraseña filtrada. En cambio, socava todo el modelo de confianza digital, provocando brechas en cascada a través de capas de autenticación e infraestructuras.

Escenarios críticos:

• Acceso persistente — Un TOTP clonado basta para registrar un “dispositivo de confianza” y mantener acceso incluso tras un restablecimiento completo de la cuenta.
• Reutilización de passkeys — La exfiltración de una llave de acceso actúa como un token maestro, reutilizable fuera de cualquier perímetro de control. El “Zero Trust” se convierte en ilusión.
• Compromiso SSO — Una extensión atrapada en una empresa conduce a la fuga de tokens OAuth/SAML, comprometiendo todo el sistema de TI.
• Brecha en la cadena de suministro — Extensiones mal reguladas crean una superficie de ataque estructural a nivel de navegador.
• Sifoneo de criptoactivos — Billeteras como MetaMask, Phantom o TrustWallet inyectan claves en el DOM; frases semilla y claves privadas son drenadas tan fácilmente como credenciales.

Exposición Regional e Impacto Lingüístico — Mundo Anglófono

No todas las regiones comparten el mismo nivel de riesgo frente al clickjacking extensiones DOM y a los ataques Browser-in-the-Browser (BITB). La esfera anglófona —debido a la alta adopción de gestores de contraseñas y billeteras cripto— representa una base de usuarios significativamente más expuesta. Por tanto, las contramedidas soberanas Zero-DOM son críticas para proteger a esta región digitalmente dependiente.

🌍 Exposición estimada — Región Anglófona (ago 2025)

Fuentes: ICLS (hablantes de inglés), Security.org (uso de gestores en EE.UU.), DataReportal (estadísticas digitales UK).

Extensiones de Billeteras Cripto Expuestas

Los gestores de contraseñas no son las únicas víctimas del clickjacking extensiones DOM.
Las billeteras cripto más utilizadas — MetaMask, Phantom, TrustWallet — dependen del mismo mecanismo de inyección DOM para mostrar o firmar transacciones.
En consecuencia, una superposición bien colocada o un iframe invisible engañan al usuario, haciéndole creer que aprueba una transacción legítima, cuando en realidad está autorizando una transferencia maliciosa o exponiendo su frase semilla.

Implicación directa: A diferencia de credenciales robadas o TOTP clonados, estas fugas afectan a activos financieros inmediatos. Miles de millones de dólares en valor líquido dependen de tales extensiones.
Por tanto, el DOM se convierte no solo en un vector de compromiso de identidad, sino también en un canal de exfiltración monetaria.

Sandbox Fallida y Browser-in-the-Browser (BITB)

Los navegadores presentan su sandbox como una fortaleza inexpugnable.
Sin embargo, los ataques de clickjacking extensiones DOM y Browser-in-the-Browser (BITB) demuestran lo contrario.
Una simple superposición y un marco de autenticación falso pueden engañar al usuario, haciéndole creer que interactúa con Google, Microsoft o su banco, cuando en realidad está entregando secretos a una página fraudulenta.
Incluso las directivas frame-ancestors y algunas políticas CSP fallan en prevenir estas ilusiones de interfaz.

Aquí es donde las tecnologías soberanas cambian la ecuación.
Con EviBITB (IRDR), Freemindtronic integra en PassCypher HSM PGP un motor de detección y destrucción de iframes maliciosos, neutralizando intentos BITB en tiempo real.
Activable con un solo clic, funciona en modo manual, semiautomático o automático, totalmente serverless y sin base de datos, garantizando defensa instantánea (explicación · guía detallada).

La piedra angular sigue siendo la Sandbox URL.
Cada identificador o clave criptográfica se vincula a una URL de referencia almacenada de forma segura en el HSM cifrado.
Cuando una página solicita autocompletado, la URL activa se compara con la referencia. Si no coincide, no se inyecta ningún dato.
Así, incluso si un iframe logra evadir la detección, la Sandbox URL bloquea los intentos de exfiltración.

Esta barrera de doble capa también se extiende al uso en escritorio.
Mediante el emparejamiento seguro NFC entre un smartphone Android y la aplicación Freemindtronic con PassCypher NFC HSM, los usuarios se benefician de protección anti-BITB en escritorio.
Los secretos permanecen cifrados dentro del HSM NFC y solo se descifran en memoria RAM durante unos milisegundos, lo justo para el autocompletado — nunca persisten en el DOM.

Señales Estratégicas desde DEF CON 33

En los pasillos electrificados de DEF CON 33, no solo parpadean insignias: también lo hacen nuestras certezas.
Entre una cerveza tibia y un frenético CTF, las conversaciones convergen en un punto común: el navegador ya no es una zona de confianza.
En consecuencia, el clickjacking extensiones DOM no se trata como una clase de bug, sino como un fallo estructural que afecta por igual a gestores de contraseñas, passkeys y billeteras cripto.

• El DOM se convierte en un campo minado: ya no aloja solo “XSS básicos”; ahora porta primitivas de identidad — gestores, passkeys y wallets — haciendo del secuestro de autocompletado vía Shadow DOM un riesgo de primer orden.
• La promesa de “resistencia al phishing” se tambalea: ver una passkey ser phished en vivo equivale a ver a Neo apuñalado por un script kiddie — dramático, pero trivial una vez que la interfaz es subvertida.
• Lentitud industrial: algunos proveedores publican parches en 48h; otros se pierden en comités y notas de prensa. Mientras tanto, millones siguen expuestos a flaws de seguridad en extensiones y overlays invisibles.
• Zero Trust reforzado: cualquier secreto que toque el DOM debe considerarse ya comprometido — desde credenciales hasta TOTP y passkeys.
• Retorno del hardware soberano: a medida que las ilusiones cloud se desmoronan, la atención se dirige a contramedidas Zero-DOM offline: PassCypher NFC HSM, PassCypher HSM PGP y SeedNFC para respaldo cifrado de claves cripto. Zero DOM, cero ilusión de interfaz.

Contramedidas Soberanas (Zero DOM)

Los parches de proveedores pueden tranquilizar a corto plazo, sin embargo, no resuelven el problema de fondo: el DOM sigue siendo un colador.
La única respuesta duradera es eliminar los secretos de su alcance.
Este principio, conocido como Zero DOM, dicta que ningún dato sensible debe residir, transitar ni depender del navegador.
En otras palabras, el clickjacking extensiones DOM se neutraliza no con remiendos, sino con soberanía arquitectónica.

En este paradigma, los secretos (credenciales, TOTP, passkeys, claves privadas) se preservan en HSMs hardware offline.
El acceso solo es posible mediante activación física (NFC, HID, emparejamiento seguro) y deja una huella efímera en RAM.
Esto elimina por completo la exposición al DOM.

A diferencia de los gestores cloud o passkeys FIDO, estas soluciones no aplican parches reactivos: eliminan la superficie de ataque por diseño.
Es la esencia del enfoque soberano-por-diseño: arquitectura descentralizada, sin servidor central y sin base de datos a filtrar.

PassCypher HSM PGP — Tecnología Zero-DOM Patentada desde 2015

Mucho antes de la exposición del clickjacking extensiones DOM en DEF CON 33, Freemindtronic tomó otro camino.
Desde 2015, su I+D estableció un principio fundador: nunca usar el DOM para transportar secretos.
Esta doctrina de Zero Trust dio origen a una arquitectura Zero-DOM patentada en PassCypher, garantizando que credenciales, TOTP/HOTP, contraseñas y claves criptográficas permanezcan confinadas en un HSM hardware — nunca inyectadas en un entorno manipulable.

🚀 Un avance único en gestores de contraseñas

• Zero DOM nativo — ningún dato sensible toca jamás el navegador.
• HSM PGP integrado — cifrado AES-256 CBC + segmentación de claves patentada.
• Autonomía soberana — sin servidor, sin base de datos, sin dependencia cloud.

🛡️ Protección BITB reforzada

Desde 2020, PassCypher HSM PGP incluye — incluso en su versión gratuita — la tecnología EviBITB.
Esta innovación neutraliza los ataques Browser-in-the-Browser (BITB) en tiempo real: destruye iframes maliciosos, detecta superposiciones fraudulentas y valida contextos de forma serverless, sin base de datos y totalmente anónima.
Descubre en detalle cómo funciona EviBITB.

⚡ Implementación inmediata

El usuario no configura nada: simplemente instala la extensión PassCypher HSM PGP desde la Chrome Web Store o Edge Add-ons, activa la opción BITB y disfruta de protección soberana Zero-DOM al instante — mientras los competidores siguen reaccionando a destiempo.

</figure]

PassCypher NFC HSM — Gestor Soberano sin Contraseñas

Los gestores de contraseñas basados en software caen en la trampa de un simple iframe.
Sin embargo, PassCypher NFC HSM sigue un camino diferente: nunca permite que tus credenciales y contraseñas transiten por el DOM.
El nano-HSM las mantiene cifradas offline y solo las libera por un instante efímero en memoria volátil — lo justo para autenticar.

Funcionamiento en el lado del usuario:

• Secretos intocables — el NFC HSM cifra y almacena credenciales que nunca aparecen ni se filtran.
• TOTP/HOTP — la app Android PassCypher NFC HSM o el PassCypher HSM PGP en escritorio los generan y muestran al instante bajo demanda.
• Entrada manual — el usuario introduce un PIN o TOTP directamente en el campo de login en un ordenador o teléfono NFC Android. La app muestra el código generado por el módulo NFC HSM. El mismo proceso aplica a credenciales, passkeys y otros secretos.
• Autocompletado sin contacto — el usuario presenta el módulo NFC HSM a un smartphone o PC, que ejecuta el autofill de forma transparente, incluso emparejado con PassCypher HSM PGP.
• Autofill en escritorio — con PassCypher HSM PGP en Windows o macOS, un clic sobre el campo de login completa usuario y contraseña, con validación opcional.
• Anti-BITB distribuido — el emparejamiento seguro NFC ↔ Android ↔ navegador (Win/Mac/Linux) activa EviBITB para destruir iframes maliciosos en tiempo real.
• Modo HID BLE — un emulador de teclado Bluetooth HID inyecta credenciales fuera del DOM, bloqueando tanto ataques DOM como keyloggers.

PassCypher HSM PGP — Gestión Soberana de Claves Anti-Phishing

En un mundo donde los gestores tradicionales son saqueados por un simple iframe fantasma, PassCypher HSM PGP se niega a ceder.

¿Su regla? Cero servidor, cero base de datos, cero DOM.

Tus secretos — credenciales, contraseñas, passkeys, claves SSH/PGP, TOTP/HOTP — residen en contenedores PGP cifrados AES-256 CBC, protegidos por un sistema patentado de claves segmentadas diseñado para resistir incluso la era cuántica.

¿Por qué resiste ataques del nivel DEF CON 33?

Porque nada transita jamás por el DOM, no existe contraseña maestra que pueda ser extraída y, crucialmente, los contenedores permanecen cifrados en todo momento.
El sistema los descifra únicamente en RAM volátil, durante el breve instante necesario para ensamblar los segmentos de clave.
Una vez completado el autocompletado, todo desaparece al instante — sin dejar rastro explotable.

Características clave:

• Autofill blindado — un clic es suficiente, pero siempre vía sandbox de URL, nunca en claro dentro del navegador.
• EviBITB integrado — destruye iframes y overlays maliciosos en tiempo real, operable en modo manual, semiautomático o totalmente automático, de forma serverless.
• Herramientas criptográficas integradas — generación y gestión de claves AES-256 segmentadas y PGP sin dependencias externas.
• Compatibilidad universal — funciona con cualquier sitio vía software + extensión del navegador — sin actualizaciones forzadas ni plugins adicionales.
• Arquitectura soberana — sin servidor, sin base de datos, sin contraseña maestra, totalmente anonimizada — inatacable por diseño, donde los gestores cloud se derrumban.

SeedNFC + HID Bluetooth — Inyección Segura de Wallets

Las extensiones de navegador para billeteras cripto viven en el DOM — y los atacantes explotan esa debilidad.
Con SeedNFC HSM, la lógica se invierte: el enclave nunca libera claves privadas ni frases semilla.
Cuando los usuarios inicializan o restauran una wallet (web o escritorio), el sistema realiza la entrada mediante una emulación HID Bluetooth — como un teclado hardware — sin portapapeles, sin DOM y sin dejar rastros de claves privadas, públicas o credenciales de hot wallets.

Flujo operativo (anti-DOM, anti-portapapeles):

• Custodia — el SeedNFC HSM cifra y almacena la semilla/clave privada (nunca la exporta, nunca la revela).
• Activación física — el módulo NFC HSM autoriza la operación cuando el usuario lo presenta de forma contactless a través de la app Freemindtronic (smartphone Android NFC).
• Inyección HID BLE — el sistema “teclea” la semilla (o fragmento/format requerido) directamente en el campo de la wallet, fuera del DOM y fuera del portapapeles, resistiendo incluso keyloggers de software.
• Protección BITB — los usuarios pueden activar EviBITB (motor anti-BITB destruye iframes) dentro de la app, neutralizando overlays y redirecciones maliciosas en la configuración o recuperación.
• Efimeridad — la RAM volátil mantiene temporalmente los datos durante la entrada HID, para borrarlos al instante.

Casos de uso típicos:

• Onboarding o recuperación de wallets (MetaMask, Phantom, etc.) sin exponer nunca la clave privada al navegador ni al DOM. El HSM mantiene el secreto cifrado y lo descifra solo en RAM, el tiempo mínimo necesario.
• Operaciones sensibles en escritorio (air-gap lógico), con validación física por el usuario: presentar el módulo NFC HSM bajo un smartphone NFC Android para autorizar, sin teclado ni DOM.
• Backup seguro multi-activo: un HSM hardware offline almacena frases semilla, claves maestras y privadas, permitiendo reutilización sin copiar, exportar ni exponer. La activación siempre ocurre por medios físicos, soberanos y auditables.

Escenarios de Explotación y Rutas de Mitigación

Las revelaciones de DEF CON 33 no son el final del juego, sino una advertencia.
Lo que sigue puede resultar aún más corrosivo:

• Phishing impulsado por IA + secuestro del DOM — mañana ya no serán kits de phishing caseros, sino LLMs generando superposiciones DOM en tiempo real, virtualmente indistinguibles de portales legítimos de banca o nube.
  Estos ataques de clickjacking potenciados por IA convertirán el robo de credenciales vía Shadow DOM en un arma a escala.
• Tapjacking móvil híbrido — la pantalla táctil se convierte en un campo minado: aplicaciones apiladas, permisos invisibles y gestos en segundo plano secuestrados para validar transacciones o exfiltrar OTPs.
  Esto representa la evolución del tapjacking de phishing hacia un compromiso sistémico en entornos móviles.
• HSM preparado para la era post-cuántica — la próxima línea de defensa no será un parche del navegador, sino HSMs resistentes a la computación cuántica, capaces de soportar los algoritmos de Shor o Grover.
  Soluciones como PassCypher HSM PGP y SeedNFC, ya concebidas como anclajes soberanos Zero-DOM post-cloud, encarnan este cambio de paradigma.

Síntesis Estratégica

El clickjacking extensiones DOM revela una verdad contundente: los navegadores y las extensiones no son entornos de confianza.
Los parches llegan en oleadas fragmentadas, la exposición de usuarios alcanza decenas de millones y los marcos regulatorios permanecen en un eterno desfase.

¿El único camino soberano? Una estricta gobernanza del software, combinada con salvaguardas hardware offline fuera del DOM (PassCypher NFC HSM / PassCypher HSM PGP), donde los secretos permanecen cifrados, offline e intocables por técnicas de redressing.

La Vía Soberana:

• Gobernanza estricta de software y extensiones
• Seguridad de identidad respaldada en hardware (PassCypher NFC HSM / HSM PGP)
• Secretos cifrados, fuera del DOM, fuera de la nube, redress-proof