Por qué la criptografía poscuántica comienza con las credenciales – CYBERDEFENSA.MX

Es posible que los datos cifrados de hoy, como las credenciales, ya no sigan siendo confidenciales en el futuro porque la criptografía de clave pública que los protege pronto será descifrada por las computadoras cuánticas. Aunque ninguna máquina hoy puede estropearse criptografía de curva elíptica o RSA, el hardware cuántico está avanzando rápidamente e inevitablemente cambiará la forma en que las organizaciones protegen sus datos. El texto cifrado y las credenciales capturadas por los atacantes ahora se pueden almacenar y descifrar tan pronto como la computación cuántica se ponga al día.

¿Qué tan urgente es la criptografía resistente a los cuánticos?

El Informe Cronología de amenazas cuánticas 2025 del Global Risk Institute muestra que los especialistas en seguridad encuestados creen que es probable que una computadora cuántica criptográficamente relevante esté disponible dentro de 15 años, y entre el 51% y el 70% así lo indica. La amenaza se remonta a 1994, cuando Peter Shor demostró que una poderosa computadora cuántica podía factorizar eficientemente números grandes y calcular logaritmos discretos. Sin embargo, el algoritmo de Shor se aplica a la criptografía de clave pública y no representa una amenaza significativa para el cifrado simétrico como AES-256 o el hash moderno. Esta distinción es importante porque la criptografía de clave pública es lo que dos sistemas utilizan para establecer confianza y acordar las claves que protegen sus datos. Si una computadora cuántica puede romper ese paso, el atacante puede desbloquear los datos protegidos y las credenciales detrás de ella.

Lo que hace que la amenaza cuántica sea relevante hoy, y no sólo en el futuro, es una táctica conocida como Cosechar ahora, descifrar después, en la que un atacante captura el tráfico cifrado hoy, lo almacena y luego lo descifra cuando hay una computadora cuántica disponible. Con una computadora cuántica capaz de estar disponible dentro de 15 años, cualquier dato interceptado y recopilado hoy debería tratarse como datos ya expuestos.

Plazos de Q-día

Aunque no está claro exactamente cuándo llegará una computadora cuántica, las agencias gubernamentales están fijando fechas límite en torno al hito conocido como Q-Day para determinar cuándo debe cambiar la criptografía. El Commercial National Security Algorithm Suite 2.0 de la NSA requerirá que nuevos sistemas de seguridad nacionales comiencen a admitir algoritmos resistentes a los cuánticos a partir del 1 de enero de 2027. Si bien los plazos están escalonados para varias categorías de sistemas a lo largo de principios de la década de 2030, la NSA espera que todos los sistemas de seguridad nacionales sean resistentes a los cuánticos para 2035. El NIST está avanzando en un camino paralelo con su borrador IR 8547, que desaprueba RSA-2048 y ECC P-256 después de 2030 y las prohibirá por completo después de 2035. Estas fechas pueden parecer lejanas, pero una transición empresarial completa podría tardar de 5 a 15 años, ya que la fase de descubrimiento por sí sola puede tardar de 1 a 2 años en las grandes empresas.

Por qué las credenciales conllevan un riesgo importante en un futuro poscuántico

No todos los datos cifrados dentro de una organización conllevan el mismo riesgo cuando la criptografía que los protege acaba quedando obsoleta. La mayoría de los secretos, como los tokens de sesión, tienen una vida útil de confidencialidad medida en meses; Las credenciales pueden persistir durante años o mientras sus sistemas asociados permanezcan en servicio. Para los atacantes, eso hace que valga la pena recolectar las credenciales ahora y conservarlas hasta que una computadora cuántica pueda descifrarlas. Lo que hace que esto sea un riesgo de seguridad importante es la escala, especialmente porque la mayoría de las organizaciones tienen poblaciones crecientes de identidades no humanas (NHI), como cuentas de servicio y claves API. Estas credenciales de máquina tienden a ser duraderas porque ningún usuario humano es responsable de rotarlas y probablemente no hayan sido inventariadas para su exposición criptográfica, lo que las convierte en objetivos ideales para la recolección.

Cómo iniciar una migración cuántica centrada en las credenciales

Dado que la mayor parte del riesgo se concentra en las credenciales, la migración también debería comenzar con ellas. Las organizaciones deben adoptar un enfoque de migración cuántica que dé prioridad a las credenciales haciendo lo siguiente.

Inventario de criptografía existente

La razón principal por la que las migraciones son procesos tan largos es que las organizaciones no pueden detallar sus dependencias criptográficas. Un inventario de credenciales primero comienza con la búsqueda de los sistemas que contienen o negocian secretos, incluidos administradores de contraseñas, administradores de secretos y plataformas de gestión de acceso privilegiado (PAM). Es probable que esta fase exponga cuentas de servicio olvidadas, secretos codificados o integraciones que han estado inactivas durante años.

Priorizar el riesgo sobre el tamaño

Si bien es posible que las organizaciones quieran comenzar a proteger sus sistemas más grandes, es más inteligente priorizar la vida útil de la confidencialidad en función de la exposición, como cuánto tiempo debe permanecer privado un secreto, combinado con qué tan accesible es para un atacante. Con esta lógica, un pequeño secreto de larga duración que facilita el acceso a sistemas críticos pesa más que un conjunto de datos vasto pero de corta duración. Priorizar el riesgo de esta manera garantiza que las credenciales más vulnerables a Harvest Now, Decrypt Later estén protegidas primero.

Migrar a criptografía híbrida

En lugar de reemplazar completamente los algoritmos clásicos, las organizaciones deberían adoptar la criptografía híbrida combinando un algoritmo clásico con uno resistente a los cuánticos en el mismo intercambio de claves. Esto mantiene una conexión protegida tanto contra los atacantes tradicionales de hoy como contra los futuros atacantes cuánticos. La criptografía híbrida también impide que las organizaciones apuesten todo por un algoritmo único y relativamente nuevo, ya que el componente clásico permanece en su lugar y no se elimina nada para agregar protección resistente a los cuánticos.

Construya para la criptoagilidad

Dado que los algoritmos quedan obsoletos y los parámetros cambian, las organizaciones deben esperar que la migración actual no sea la definitiva. Construya teniendo en cuenta la criptoagilidad: de esa manera, los intercambios de algoritmos criptográficos son cambios de configuración en lugar de importantes revisiones de reingeniería. Para las credenciales en particular, esto significa mantener la criptografía en una ubicación centralizada para que, cuando sea necesario cambiar el algoritmo, se pueda actualizar una vez en lugar de volver a trabajar en múltiples aplicaciones, canalizaciones e integraciones.

Comience a proteger donde el riesgo es mayor

Si bien la necesidad de postergar la criptografía resistente a los cuánticos puede ser fuerte, las organizaciones deben recordar que la migración cuántica es un proceso largo y que los datos de hoy deben permanecer secretos en el futuro. No es necesario que exista todavía una computadora cuántica para que la amenaza de credenciales recolectadas y luego descifradas sea un problema real. La transición a la criptografía resistente a los cuánticos debería comenzar con las credenciales, ya que es allí donde se cruzan la vida útil de la confidencialidad y el radio de explosión. En noviembre de 2025, el lanzamiento de criptografía resistente a los cuánticos comenzó en todas las aplicaciones cliente de Keeper, adoptando los mecanismos de encapsulación de claves híbridas (KEM) de Kyber para ayudar a proteger las bóvedas de Harvest Now, Decrypt Later y otras amenazas de la computación cuántica. Proteger las credenciales contra un futuro cuántico es lo que las organizaciones deberían priorizar ahora, antes de que un hardware más avanzado las obligue a hacerlo.

Nota: Este artículo fue escrito cuidadosamente y contribuido para nuestra audiencia por Ashley D’Andrea, redactora de contenido de Keeper Security.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

La implementación de la verificación de desarrolladores de Android comienza antes de la aplicación de la ley en septiembre – CYBERDEFENSA.MX

Google dijo el lunes que está implementando oficialmente la verificación de desarrollador de Android para todos los desarrolladores para combatir el problema de los malos actores que distribuyen aplicaciones dañinas mientras «se esconden detrás del anonimato».

El desarrollo se produce antes de un mandato de verificación planificado que entrará en vigor en Brasil, Indonesia, Singapur y Tailandia en septiembre, antes de expandirse a nivel mundial el próximo año.

Como parte de este esfuerzo, Google exige a los desarrolladores de aplicaciones que distribuyen aplicaciones fuera de Google Play que creen una cuenta en la Consola de desarrollador de Android para confirmar su identidad. Aquellos que distribuyen aplicaciones a través del mercado oficial de aplicaciones de Android y han verificado su identidad pueden «ya estar configurados», dijo el gigante tecnológico.

Ciberseguridad

«Para la gran mayoría de los usuarios, la experiencia de instalar aplicaciones seguirá siendo exactamente la misma», dijo Matthew Forsythe, director de gestión de productos para Android App Safety. dicho. «Solo cuando un usuario intenta instalar una aplicación no registrada necesitará ADB o flujo avanzado, lo que nos ayuda a mantener segura a la comunidad en general y al mismo tiempo preserva la flexibilidad para nuestros usuarios avanzados».

Los desarrolladores de Android Studio pueden esperar ver el estado de registro de su aplicación directamente desde el entorno de desarrollo integrado (IDE) en los próximos dos meses cuando generen un App Bundle o APK firmado.

Los desarrolladores que hayan completado los requisitos de verificación de desarrollador de Play Console registrarán automáticamente sus aplicaciones de Play elegibles. Si no se puede registrar una aplicación, se solicita a los desarrolladores que sigan un proceso de reclamo de aplicación manual.

Como se anunció hace un par de semanas, los usuarios avanzados siempre tienen la opción de habilitar la descarga de archivos APK no registrados a través de un flujo avanzado que requiere un paso de autenticación para confirmar que están dando este paso por su propia voluntad y un período de espera único de 24 horas para disuadir a los estafadores.

«Este flujo es un proceso único para usuarios avanzados, pero fue diseñado cuidadosamente para evitar que aquellos que se encuentran en medio de un intento de estafa sean coaccionados por tácticas de alta presión para instalar software malicioso», dijo Forsythe.

Ciberseguridad

El desarrollo llega como lo ha hecho Apple. revisado su Acuerdo de Licencia del Programa de Desarrolladores para hacer cumplir las reglas de privacidad con respecto al acceso de dispositivos portátiles de terceros a actividades y notificaciones en vivo.

Apple señaló explícitamente que terceros «no pueden usar la información de reenvío para publicidad, elaboración de perfiles, modelos de entrenamiento o monitoreo de ubicación», y agregó que «no pueden difundir la información de reenvío a ninguna otra aplicación ni a ningún otro dispositivo además de su accesorio de destino autorizado».

La sección recién agregada también enfatizó que los desarrolladores no pueden almacenar de forma remota ninguna información de reenvío en un servicio en la nube, realizar modificaciones que cambien «materialmente» el significado del contenido o descifrar los datos en cualquier otro lugar que no sea el propio accesorio.

Dónde termina la autenticación multifactor y comienza el abuso de credenciales – CYBERDEFENSA.MX

Las organizaciones suelen implementar la autenticación multifactor (MFA) y suponen que las contraseñas robadas ya no son suficientes para acceder a los sistemas. En entornos Windows, esa suposición suele ser errónea. Los atacantes siguen comprometiendo las redes todos los días utilizando credenciales válidas. La cuestión no es la ayuda macrofinanciera en sí, sino la cobertura.

Se aplica a través de un proveedor de identidad (IdP) como Microsoft Entra ID, Okta o Google Workspace. MFA funciona bien para aplicaciones en la nube e inicios de sesión federados. Pero muchos inicios de sesión de Windows dependen únicamente de rutas de autenticación de Active Directory (AD) que nunca activan mensajes de MFA. Para reducir el riesgo basado en credenciales, los equipos de seguridad deben comprender dónde ocurre la autenticación de Windows fuera de su pila de identidades.

Siete rutas de autenticación de Windows en las que confían los atacantes

1. Inicio de sesión interactivo de Windows (local o unido a un dominio)

Cuando un usuario inicia sesión directamente en una estación de trabajo o servidor de Windows, la autenticación normalmente la maneja AD (a través de Kerberos o NTLM), no mediante un IdP en la nube.

En entornos híbridosincluso si Entra ID aplica MFA para aplicaciones en la nube, los controladores de dominio locales validan los inicios de sesión tradicionales de Windows en sistemas unidos a un dominio. A menos que se implemente Windows Hello for Business, tarjetas inteligentes u otro mecanismo MFA integrado, no hay ningún factor adicional en ese flujo.

Si un atacante obtiene la contraseña de un usuario (o hash NTLM), puede autenticarse en una máquina unida a un dominio sin activar las políticas MFA que protegen las aplicaciones de software como servicio o el inicio de sesión único federado. Desde la perspectiva del controlador de dominio, esta es una solicitud de autenticación estándar.

Herramientas como Acceso seguro a Specops son clave para limitar el riesgo de abuso de credenciales en estos escenarios. Al aplicar MFA para el inicio de sesión de Windows, así como para las conexiones VPN y de Protocolo de escritorio remoto (RDP), esta herramienta dificulta que los atacantes obtengan acceso no autorizado a su red. Esto se extiende incluso a los inicios de sesión fuera de línea, que están protegidos con autenticación con contraseña de un solo uso.

Acceso seguro a Specops

2. Acceso RDP directo que evita el acceso condicional

RDP es uno de los métodos de acceso más específicos en entornos Windows. Incluso cuando RDP no está expuesto a Internet, los atacantes suelen llegar a través de movimiento lateral después del compromiso inicial. Una sesión RDP directa a un servidor no pasa automáticamente por los controles MFA basados ​​en la nube, lo que significa que el inicio de sesión puede depender únicamente de la credencial AD subyacente.

3. Autenticación NTLM

NTLM es un protocolo de autenticación heredado que, a pesar de estar en desuso a favor del protocolo Kerberos, más seguro, todavía existe por razones de compatibilidad. También es un vector de ataque común porque admite técnicas como pass-the-hash.

En los ataques pass-the-hash, el atacante no necesita la contraseña en texto plano; en su lugar, utilizan el hash NTLM para autenticarse. Ministerio de Asuntos Exteriores no ayuda si el sistema acepta el hash como prueba de identidad.

NTLM también puede aparecer en flujos de autenticación internos que las organizaciones tal vez no monitoreen activamente; sólo un incidente o una auditoría lo revelará a los equipos de seguridad.

4. Abuso de tickets de Kerberos

Kerberos es el protocolo de autenticación principal para AD. En lugar de robar contraseñas directamente, Los atacantes roban tickets de Kerberos. desde la memoria o generar tickets falsificados después de comprometer cuentas privilegiadas. Esto permite técnicas como:

  • Pase el boleto
  • Boleto Dorado
  • Boleto de Plata

Estos ataques permiten el acceso a largo plazo y el movimiento lateral y también reducen la necesidad de inicios de sesión repetidos, lo que reduce las posibilidades de detección. Estos ataques pueden persistir incluso después de restablecer la contraseña si el compromiso subyacente no se aborda por completo.

5. Cuentas de administrador local y reutilización de credenciales

Las organizaciones todavía dependen de cuentas de administrador local para tareas de soporte y recuperación del sistema. Si las contraseñas de administrador local se reutilizan en todos los puntos finales, los atacantes pueden escalar un compromiso hacia un acceso amplio.

Las cuentas de administrador local generalmente se autentican directamente en el punto final, evitando por completo los controles de MFA. No se aplican las políticas de acceso condicional de Entra ID. Ésta es una de las razones por las que el volcado de credenciales sigue siendo tan eficaz en entornos Windows.

6. Autenticación y movimiento lateral del Bloque de mensajes del servidor (SMB)

SMB se utiliza para compartir archivos y acceder remotamente a recursos de Windows. También es una de las rutas de movimiento lateral más confiables una vez que un atacante tiene credenciales válidas. Los atacantes suelen utilizar SMB para acceder a recursos compartidos administrativos como C$ o para interactuar con sistemas de forma remota utilizando credenciales válidas.

Si la autenticación SMB se trata como tráfico interno, rara vez se aplica MFA en esta capa. Si el atacante tiene credenciales válidas, puede usar SMB para moverse rápidamente entre sistemas.

7. Cuentas de servicio que nunca activan MFA

cuentas de servicio existen para ejecutar tareas programadas, aplicaciones, integraciones y servicios del sistema. Suelen tener credenciales estables, amplios permisos y una larga vida útil.

En muchas organizaciones, las contraseñas de las cuentas de servicio no caducan y rara vez se controlan. También son difíciles de proteger con MFA porque la autenticación está automatizada. Con frecuencia, estas cuentas se utilizan en aplicaciones heredadas que no pueden admitir controles de autenticación modernos.

Esta es una de las razones por las que los atacantes apuntan credenciales de soporte técnico y acceso de administrador de endpoints en las primeras etapas de una intrusión.

Cómo cerrar las brechas de autenticación de Windows

Los equipos de seguridad deben tratar la autenticación de Windows como su propia superficie de seguridad. Hay varias medidas prácticas que los equipos de seguridad pueden tomar para reducir la exposición:

1. Aplicar políticas de contraseñas más seguras en AD

Se debe aplicar una política de contraseñas segura frases de contraseña más largas de 15 o más caracteres. Las frases de contraseña son más fáciles de recordar para los usuarios y más difíciles de descifrar para los atacantes. Las políticas sólidas también deberían impedir la reutilización de contraseñas y bloquear patrones débiles que los atacantes puedan adivinar.

2. Bloquear continuamente las contraseñas comprometidas

El robo de credenciales no siempre es el resultado de ataques de fuerza bruta. Miles de millones de contraseñas ya están disponibles en conjuntos de datos violados para que los atacantes las reutilicen. ataques de credenciales. El bloqueo de contraseñas comprometidas en el momento de su creación reduce la posibilidad de que los usuarios establezcan credenciales que los atacantes ya tienen.

3. Reducir la exposición a protocolos de autenticación heredados

Siempre que sea posible, las organizaciones deben restringir o eliminar la autenticación NTLM. Los equipos de seguridad deben fijarse el objetivo de comprender dónde existe NTLM, reducirlo cuando sea posible y reforzar los controles cuando no se pueda eliminar.

4. Audite las cuentas de servicio y reduzca la pérdida de privilegios

Trate las cuentas de servicio como identidades de alto riesgo. Las organizaciones deben inventariarlos, reducir privilegios innecesariosrotar credenciales y eliminar cuentas que ya no sean necesarias. Si una cuenta de servicio tiene permisos a nivel de dominio, la organización debe asumir que será el objetivo.

Cómo puede ayudar Specops

Las políticas de contraseñas sólidas y las comprobaciones proactivas de credenciales comprometidas conocidas son dos de las formas más efectivas de reducir el riesgo de ataques basados ​​en credenciales. Política de contraseñas de Specops ayuda aplicando controles de contraseña flexibles que van más allá de lo que está disponible de forma nativa en Microsoft.

Política de contraseñas de Specops

Es Protección de contraseña violada La función verifica continuamente las contraseñas de Active Directory con una base de datos de más de 5,4 mil millones de credenciales expuestas, avisándole rápidamente si se descubre que la contraseña de un usuario está en riesgo. Si está interesado en ver cómo Specops puede ayudar a su organización, hable con un experto o reservar una demostración para ver nuestras soluciones en acción.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.