Dasi Technology logoDasi Technology
Clave Única API: cuando un trade-off de diseño se volvió un problema de Estado
Volver al blog
Open SourceSeguridadClave ÚnicaArquitecturaGobernanza Digital

Clave Única API: cuando un trade-off de diseño se volvió un problema de Estado

6 min de lectura

¿Qué tan seguro es un sistema de identidad digital cuando se basa en un solo factor de autenticación y se expone a automatización? En 2025 decidimos responder esa pregunta con código abierto. No para “romper” el sistema, sino para mostrar los límites de un diseño que prioriza usabilidad por sobre defensa en profundidad.

Esta es la historia de cómo una demostración técnica ayudó a convertir un debate abstracto en una mejora concreta de la infraestructura digital del Estado.

El contexto: un diseño correcto… hasta que se lleva a escala

En julio de 2025, Chile vivió una controversia pública: empresas comenzaron a solicitar la Clave Única de los usuarios para acceder a servicios del Estado como SII, AFC y otros portales oficiales.

La discusión no giraba en torno a un bug ni a un hackeo. El sistema funcionaba exactamente como había sido diseñado:

  • Un solo factor de autenticación
  • Alta usabilidad para ciudadanos
  • Confianza en la custodia del usuario

Desde el punto de vista técnico, eso es un trade-off legítimo. Pero desde el punto de vista sistémico, también es una decisión con consecuencias: cuando un flujo legítimo se puede automatizar, el riesgo operacional cambia de naturaleza.

No había una falla puntual. Había un límite de diseño.

Nuestra decisión: hacer visible el riesgo con ingeniería, no con opinión

En Dasi Technology optamos por una forma poco habitual de intervenir en el debate: construimos una demostración técnica y la publicamos como código abierto.

No para explotar el sistema. No para ofrecer servicios sobre él. Sino para mostrar, de manera reproducible, qué ocurre cuando un modelo de autenticación de un solo factor se enfrenta a automatización a escala.

Creemos que los problemas de infraestructura pública no se resuelven con slogans, sino con evidencia técnica.

El proyecto: Clave Única API

Desarrollamos una API educativa que muestra cómo un sistema externo puede automatizar flujos legítimos de acceso a plataformas del Estado, entre ellas:

  • CMF (Comisión para el Mercado Financiero)
  • AFC (Administradora de Fondos de Cesantía)
  • SII (Servicio de Impuestos Internos)

El objetivo no era “probar inseguridad”, sino demostrar empíricamente un riesgo de diseño: la dependencia total de un único factor cuando los accesos pueden ser orquestados por software.

Arquitectura técnica

El proyecto fue construido con estándares de ingeniería reales:

  • Strategy Pattern para múltiples métodos de autenticación
  • Procesamiento asíncrono con Redis
  • Workers desacoplados para escalabilidad
  • Playwright para automatización de navegador
clave_unica_api/
├── src/
│   ├── scrapers/           # Módulos por servicio
│   ├── queue/              # Colas con Redis
│   └── login_strategies/   # Estrategias de autenticación
├── docker-compose.yml
└── README.md

Incluimos advertencias legales explícitas: uso personal y educativo únicamente, sin soporte para servicios comerciales ni acceso a cuentas de terceros.

Lo que realmente demostramos

No descubrimos un bug. No explotamos una vulnerabilidad.

Demostramos algo distinto —y más importante:

Un sistema de identidad digital basado en un solo factor es razonable en escala humana, pero frágil cuando se expone a automatización.

Eso es un problema de arquitectura y gobernanza digital, no de “hacking”.

Convertimos una discusión política en una evidencia técnica reproducible.

El resultado: más defensa en profundidad

Meses después de la polémica y de la publicación del proyecto, varias plataformas estatales reforzaron su modelo de autenticación incorporando segundo factor (2FA), entre ellas:

  • ChileCompra (Mercado Público)
  • CMF
  • AFC

¿Fue nuestro proyecto el único detonante? No. Pero sí se alineó con una presión pública y técnica que exigía una cosa clara: defensa en profundidad para servicios de alto impacto ciudadano.

Nuestra contribución fue hacer visible, con ingeniería, por qué el diseño anterior no escalaba en términos de riesgo.

Por qué lo hicimos

En Dasi Technology desarrollamos software para contextos donde las decisiones de arquitectura tienen consecuencias reales: datos sensibles, sistemas críticos, plataformas públicas.

Este proyecto refleja tres principios que guían nuestro trabajo:

  • Rigor técnico: no opinamos sin prototipar
  • Responsabilidad: entendemos el impacto sistémico del software
  • Transparencia: el código abierto como herramienta de auditoría colectiva

No se trata de “exponer fallas”, sino de mejorar decisiones de diseño con evidencia.

El código está disponible

El proyecto es open source bajo licencia GPL v3:

Repositorio: https://github.com/luisbarradev/clave_unica_api

Si trabajas en seguridad, arquitectura de plataformas públicas o sistemas de identidad digital, te invitamos a estudiarlo.


¿Necesitas construir sistemas donde el diseño importa?

En Dasi Technology ayudamos a empresas e instituciones que necesitan:

  • Plataformas que manejan datos sensibles
  • Integraciones con sistemas gubernamentales
  • Arquitecturas con defensa en profundidad
  • Revisión técnica de decisiones críticas de diseño

No vendemos “features”. Diseñamos infraestructura de software que resiste cuando el sistema escala y el riesgo cambia.

Conversemos sobre tu proyecto.

¿Tienes un desafío similar?

Si necesitas software que resuelva un problema real de tu industria, podemos ayudarte.

Hablemos de tu proyecto