Actualización de Google Workspace
- A partir del 30 de septiembre de 2024: las apps de terceros que usan solo contraseña para acceder a cuentas de Google y a Google Sync dejarán de ser compatibles.
- Cambio: Google Workspace ya no admitirá métodos de inicio de sesión en apps o dispositivos de terceros que requieran compartir el nombre de usuario y la contraseña de Google.
- Riesgo de seguridad: el método anterior, Less Secure Apps (LSA), aumenta el riesgo de seguridad porque exige compartir las credenciales de la cuenta de Google con apps y dispositivos de terceros.
- Método más seguro: se debe usar la opción Iniciar sesión con Google, que emplea autenticación OAuth y ofrece una forma más segura y protegida de sincronizar el correo electrónico con otras apps.
Calendario del fin del acceso por LSA
- Desde el 15 de junio de 2024: la configuración de LSA se eliminará de la consola de administración y ya no podrá modificarse. Los usuarios que la tengan activada podrán seguir conectándose, pero quienes la tengan desactivada ya no podrán acceder a LSA.
- Desde el 30 de septiembre de 2024: el acceso por LSA se descontinuará para todas las cuentas de Google Workspace. CalDAV, CardDAV, IMAP, POP y Google Sync dejarán de funcionar con inicio de sesión solo por contraseña y deberán usar OAuth.
Fin del servicio Google Sync
- Desde el 15 de junio de 2024: los nuevos usuarios ya no podrán conectarse a Google Workspace mediante Google Sync.
- 30 de septiembre de 2024: los usuarios actuales de Google Sync ya no podrán conectarse a Google Workspace.
Instrucciones para administradores y usuarios finales
- Administradores: deben cambiar a un tipo de acceso más seguro llamado OAuth para que los usuarios finales puedan seguir usando este tipo de apps con sus cuentas de Google Workspace.
- Impacto en la administración de dispositivos móviles (MDM): en las organizaciones que usan un proveedor de MDM para configurar perfiles de IMAP, CalDAV, CardDAV, POP o Exchange ActiveSync (Google Sync), el servicio se retirará de forma gradual.
- Escáneres y otros dispositivos: los escáneres u otros dispositivos que envían correo mediante SMTP o LSA deben configurarse para usar OAuth, emplear un método alternativo o establecer contraseñas de aplicación para usar con el dispositivo.
Instrucciones para usuarios finales
- Aplicaciones de correo electrónico: si usas una versión anterior a Outlook 2016, debes migrar a Microsoft 365 o cambiar a Outlook para Windows o Mac que admita acceso con OAuth.
- Aplicaciones de calendario: si usas una app que utiliza CalDAV basado en contraseña, debes cambiar a un método compatible con OAuth.
- Aplicaciones de contactos: si sincronizas contactos por CardDAV en iOS o macOS e inicias sesión solo con contraseña, debes quitar la cuenta y volver a agregarla.
Instrucciones para desarrolladores
- Desarrolladores: deben actualizar sus apps para usar OAuth 2.0 como método de conexión y así mantener la compatibilidad con cuentas de Google Workspace.
Disponibilidad
- Este cambio afecta a todos los clientes de Google Workspace.
Opinión de GN⁺
- Esta actualización es una medida importante para reforzar la seguridad de los usuarios de Google Workspace. Fortalecer la seguridad de las cuentas usando OAuth en lugar de las apps menos seguras (LSA) que dependen solo de contraseña es esencial en el entorno actual de ciberseguridad.
- Afecta tanto a administradores como a usuarios finales, y especialmente quienes usan apps de correo, calendario y contactos tendrán que migrar al nuevo método de autenticación.
- Este artículo ofrece información útil para que los usuarios y administradores de Google Workspace se preparen para las próximas actualizaciones de seguridad y tomen las medidas necesarias.
1 comentarios
Opiniones de Hacker News
Un usuario tiene scripts que interactúan con Gmail, así que le sorprendió la noticia del fin del soporte para "Less Secure Apps", pero se tranquiliza al ver que las contraseñas de aplicación parecen que seguirán funcionando. Le preocupa que mucha automatización deje de funcionar si llega el momento en que solo se admita OAuth. Se queja de la complejidad de OAuth y valora positivamente la documentación de un módulo de Perl que explica con claridad cómo funciona OAuth.
Si no se puede usar OAuth, un usuario puede usar su propio proxy para que clientes IMAP o POP/SMTP funcionen con proveedores de correo "modernos" aunque no admitan OAuth 2.0. El cliente no necesita saber nada sobre OAuth.
IMAP, SMTP y POP permiten un acceso considerable a una cuenta de Google, pero no pueden hacer autenticación de dos factores ni verificaciones anti-bots, por lo que son vulnerables a ataques de credential stuffing. Se valora positivamente que Google haya desactivado este tipo de acceso por defecto para proteger a los usuarios de esos ataques, y que esta medida vaya dirigida a quienes aún quedaban.
Se señala que este cambio parece buscar mover a los usuarios hacia la propia app de correo de Google. Sin la app de Gmail o Google Sync, que pronto será descontinuado, no se pueden recibir notificaciones de correo en tiempo real. Un usuario expresa su molestia pese a que paga por Google Workspace. En escritorio, Mimestream sigue funcionando, pero teme que Google intente bloquearlo.
En Android, lo más molesto de OAuth2 y Google es que no se puede iniciar sesión en un cliente de correo o calendario con una cuenta de Google sin vincular primero toda la telefonía al conjunto de la cuenta de Google. Además, eso le da a esa cuenta permisos de políticas sobre el dispositivo. El usuario señala que esto no puede ignorarse del todo y que Google puede restringir fácilmente el uso de oauth2 dentro de WebView en Android.
Las contraseñas de aplicación son claves de 16 caracteres que solo pueden usarse en cuentas con autenticación de dos factores activada. Se señala que las "apps menos seguras" ofrecen el mismo nivel de seguridad que las apps compatibles con OAuth, pero gracias a un mecanismo del lado del servidor que Google ha podido promocionar durante mucho tiempo. Se expresa una postura crítica sobre cómo Google interpreta los problemas de seguridad de una manera que impulsa su propia agenda.
Parece que las contraseñas específicas de aplicación (App-Specific Passwords) seguirán funcionando, y se explica que, si se usan apps que no admiten OAuth, habrá que cambiar a una app compatible con OAuth o generar una contraseña de aplicación para acceder.
Se explica que este cambio solo aplica a cuentas de Workspace; para las cuentas normales de Gmail ya se había aplicado hace varios años.
Hace unos 10 años, alguien construyó un sistema que permitía autenticarse en una red interna con cuentas individuales de Google mediante integración con el directorio de cuentas de Google. Según los estándares actuales era menos seguro, pero se valora positivamente porque permitía conectarse de inmediato a la red interna sin pasar por VPN, ahorrándole tiempo a todos.
Al lidiar con la transición de Microsoft a OAuth, alguien tuvo muchas dificultades porque el proceso es muy opaco. Se envía un token y el servidor solo responde "no", sin explicar por qué no funciona, lo que llevó a perder días enteros resolviendo el problema. Se plantea la duda de si los servidores de correo de Google son mejores en ese aspecto.