Desactivación del soporte de Google Sync y de aplicaciones menos seguras

Artículo original ↗ Discusión en Hacker News ↗

Google está retirando Google Sync y el acceso con contraseña de “aplicaciones menos seguras” para cuentas de Workspace, empujando a las organizaciones hacia la autenticación basada en OAuth o contraseñas específicas de aplicación para IMAP, POP y SMTP. Los comentaristas celebran una protección más fuerte contra credential stuffing y phishing, pero temen romper clientes antiguos, impresoras y scripts, la complejidad y el coste de OAuth para proyectos pequeños, y una presión percibida hacia las propias apps de Google y el bloqueo del ecosistema. Muchos señalan las contraseñas de aplicación y los proveedores de correo de terceros como soluciones prácticas, al tiempo que cuestionan cuánto tiempo mantendrá Google disponibles esas alternativas.

Alcance del cambio

  • Muchos señalan que el título de HN es engañoso: Google está desactivando las “Less Secure Apps” (nombre de usuario + contraseña principal) y Google Sync (ActiveSync) para Workspace, no IMAP/SMTP/POP en sí.
  • Las contraseñas de aplicación específicas y OAuth siguen siendo compatibles; varios usuarios confirman que el soporte de Workspace ha dicho explícitamente que las contraseñas de aplicación funcionarán para IMAP, POP y SMTP.
  • Gmail personal perdió las LSA antes; esto completa la transición para Workspace.

Contraseñas de aplicación y dispositivos heredados

  • Hay gran preocupación por impresoras, escáneres y clientes antiguos (p. ej., Outlook 2007, Mail de iOS vía Exchange).
  • El consenso del hilo: estos pueden seguir funcionando mediante contraseñas de aplicación o, en algunos casos, relés SMTP.
  • Algunos administradores informan que las contraseñas de aplicación funcionan de forma fiable; otros las encuentran confusas o poco fiables y temen que los usuarios normales/IT tengan dificultades.

Complejidad y fricción de OAuth

  • Muchos se quejan de que OAuth2 es confuso, opaco y propenso a errores, especialmente para servidores sin interfaz y scripts.
  • Los problemas citados incluyen mensajes de error poco claros, cambios en el comportamiento de los tokens, rarezas con los refresh tokens y el alto listón de Google (y su coste) para tener un cliente de producción verificado.
  • Se mencionan varias herramientas y soluciones alternativas (proxies OAuth, ayudantes CLI, rclone, etc.), pero a menudo requieren configuración manual del cliente OAuth.

Argumentos de seguridad y fortaleza de las contraseñas

  • El bando favorable al cambio: las LSA permiten credential stuffing y carecen de 2FA; OAuth y las contraseñas de aplicación reducen el radio de impacto y el riesgo de phishing.
  • Otros argumentan que contraseñas fuertes y únicas + TLS y 2FA opcional ya son suficientes, calificándolo de “teatro de seguridad” y hostil para el usuario.
  • Debate sobre la entropía de las contraseñas de aplicación (16 caracteres aleatorios en minúsculas). La mayoría concluye que 65–75 bits son más que suficientes, especialmente con límites de velocidad en línea.

Bloqueo, UX y preocupaciones de competencia

  • Varios ven esto como una forma de empujar a los usuarios fuera de clientes de terceros y hacia las apps de Gmail, especialmente dada la pérdida de Exchange push en Mail de iOS y la resistencia de Google a protocolos como JMAP.
  • Algunas instituciones ya restringen IMAP con Exchange/O365, lo que refuerza los temores de una tendencia más amplia hacia ecosistemas propietarios.
  • Varios usuarios discuten o respaldan alternativas (autoalojamiento, Fastmail, Proton, Tuta), citando mejor interoperabilidad o gestión de spam.

Incertidumbres

  • El futuro de las contraseñas de aplicación se percibe como inestable: la documentación de Google las desaconseja, y algunas organizaciones informan advertencias previas de desactivación.
  • El nivel exacto de soporte a largo plazo para IMAP/SMTP sin OAuth mediante contraseñas de aplicación se considera algo “por ahora”, no garantizado.