Google pone fin al soporte de Google Sync y de las apps que solo usan contraseña

 (workspaceupdates.googleblog.com)
1 puntos por GN⁺ 2024-01-20 | 1 comentarios | Compartir por WhatsApp
  • Google Workspace dejará de admitir el método de Less Secure Apps (LSA), que permite iniciar sesión compartiendo solo nombre de usuario y contraseña, y exigirá inicio de sesión basado en OAuth para la sincronización de correo, calendario y contactos
  • El calendario de desactivación comenzó en dos fases, el 15 de junio de 2024 y el 30 de septiembre de 2024, pero tras una pausa temporal y su reanudación, LSA ya no será compatible a partir del 1 de mayo de 2025
  • Se verán afectadas las conexiones de CalDAV, CardDAV, IMAP, SMTP y POP que usan solo contraseña, así como Google Sync; tanto los usuarios nuevos como los actuales de Google Sync deberán migrar
  • Los administradores deben compartir con los usuarios afectados las instrucciones para migrar a OAuth, y los perfiles basados en contraseña que se distribuían por MDM también deberán cambiarse para volver a agregar la Google Account con OAuth
  • Los usuarios que no tomen medidas antes de la fecha límite no podrán iniciar sesión y verán errores de combinación incorrecta de nombre de usuario y contraseña; los desarrolladores deberán actualizar el método de conexión de sus apps a OAuth 2.0 para mantener la compatibilidad con Workspace

Fin del inicio de sesión solo con contraseña

  • Google Workspace ya no admitirá métodos de inicio de sesión en los que apps o dispositivos de terceros soliciten directamente el nombre de usuario y la contraseña de Google
  • Este método se conoce como Less Secure Apps (LSA) y aumenta el riesgo de acceso no autorizado a la cuenta, ya que requiere compartir las credenciales de la cuenta de Google con apps y dispositivos de terceros
  • La alternativa es Sign in with Google, que usa OAuth, el método de autenticación estándar de la industria que la mayoría de las apps y dispositivos de terceros ya utilizan
  • Google anunció este cambio en 2019 y luego volvió a publicar el calendario de implementación

Calendario de desactivación e historial de aplazamientos

  • El fin del acceso por LSA originalmente estaba dividido en dos fases
    • Desde el 15 de junio de 2024, la configuración de LSA se eliminó de Admin Console y ya no pudo modificarse
    • Los usuarios que ya lo tenían activado podían seguir conectándose, pero quienes lo tuvieran desactivado no podían acceder a LSA
    • Esto incluía apps de terceros basadas en CalDAV, CardDAV, IMAP, SMTP y POP que accedían a Gmail, Google Calendar y Contacts solo con contraseña
    • También se eliminó de la configuración de Gmail del usuario la opción de activar o desactivar IMAP
    • Los usuarios que ya utilizaban LSA antes de esa fecha originalmente podían seguir usándolo hasta el 30 de septiembre de 2024
  • A partir del 30 de septiembre de 2024, estaba previsto desactivar el acceso por LSA en todas las cuentas de Google Workspace
    • CalDAV, CardDAV, IMAP, POP y Google Sync dejarían de funcionar al iniciar sesión solo con contraseña
    • Para seguir usándolos, sería necesario iniciar sesión con OAuth, un método de acceso más seguro
  • Posteriormente, el calendario se ajustó varias veces
    • En la actualización del 15 de octubre de 2024, el despliegue se pausó hasta fin de año y pasó a reanudarse en enero de 2025
    • En la actualización del 27 de enero de 2025, el despliegue se reanudó y la desactivación final quedó prevista para marzo de 2025
    • En la actualización del 12 de febrero de 2025, la fecha de fin de soporte de LSA cambió al 14 de marzo de 2025
    • En la actualización del 29 de abril de 2025, se indicó que LSA ya no será compatible a partir del 1 de mayo de 2025

Qué deben revisar las organizaciones que usan Google Sync

  • Este cambio también incluye la desactivación de Google Sync
  • El calendario original para el fin de Google Sync era el siguiente
    • Desde el 15 de junio de 2024, los usuarios nuevos ya no podían conectarse a Google Workspace mediante Google Sync
    • Desde el 30 de septiembre de 2024, los usuarios existentes de Google Sync tampoco podían seguir conectándose a Google Workspace
  • Es posible verificar el uso de Google Sync dentro de la organización desde Admin Console
    • Ruta: Devices > Mobile & Endpoints > Devices
    • Filtro: Type: Google Sync

Impacto en administradores y configuraciones MDM

  • Los administradores deben indicar a los usuarios finales que, para seguir usando apps con sus cuentas de Google Workspace, deben migrar a un método de acceso basado en OAuth
  • La información sobre los usuarios afectados se enviará a las organizaciones por correo electrónico durante los próximos meses
  • También se verán afectadas las organizaciones que configuraban perfiles de IMAP, CalDAV, CardDAV, POP y Exchange ActiveSync (Google Sync) mediante proveedores de MDM
    • Desde el 15 de junio de 2024, el envío por MDM de IMAP, CalDAV, CardDAV, SMTP, POP y Exchange ActiveSync (Google Sync) basados en contraseña ya no funciona para clientes que intenten conectarse por primera vez a LSA
    • Si se usa Google Endpoint Management, no se puede activar la configuración de Custom Push Configuration para CalDAV y CardDAV
    • Desde el 30 de septiembre de 2024, el envío basado en contraseña de IMAP, CalDAV, CardDAV, SMTP y POP para usuarios existentes dejó de funcionar
    • Los administradores deben usar su proveedor de MDM para enviar Google Account, método que vuelve a agregar la cuenta de Google al dispositivo iOS con OAuth
    • El envío basado en contraseña de Exchange ActiveSync (Google Sync) tampoco funciona para los usuarios existentes
    • Las opciones “Custom push configuration-CalDAV” y “Customer push configuration-CardDAV” de Google Endpoint Management dejan de tener efecto

Cómo migrar según el dispositivo, la app o el desarrollador

  • Si un escáner u otro dispositivo envía correo mediante SMTP o LSA, será necesario hacer una de las siguientes cosas
    • Configurar el uso de OAuth
    • Usar un método alternativo
    • Configurar una app password para ese dispositivo
  • Las apps que acceden a una cuenta de Google solo con nombre de usuario y contraseña requieren medidas de migración
    • Si no se actúa antes de la fecha límite, aparecerá un error indicando que la combinación de nombre de usuario y contraseña es incorrecta y no será posible iniciar sesión
  • Acciones por tipo de app de correo
    • Outlook 2016 o versiones anteriores debe migrarse a Microsoft 365, Outlook for Windows u Outlook for Mac, que sí admiten acceso con OAuth
    • Como alternativa, puede usarse Google Workspace Sync for Microsoft Outlook
    • Thunderbird u otros clientes de correo deben volver a agregar la cuenta de Google y configurar IMAP con OAuth
    • Si se inició sesión solo con contraseña en la app Mail de iOS o macOS, o en Outlook for Mac, debe quitarse la cuenta, volver a agregarla y seleccionar “Sign in with Google”
  • Las apps de calendario y contactos también deben cambiar a métodos compatibles con OAuth
    • Las apps de calendario basadas en CalDAV con contraseña deben cambiarse a un método compatible con OAuth, y Google recomienda la app Google Calendar
    • Si se inició sesión solo con contraseña en la app Calendario de iOS o macOS, debe quitarse la cuenta, volver a agregarla y seleccionar “Sign in with Google”
    • Si se sincronizan contactos con CardDAV en iOS o macOS e inició sesión solo con contraseña, debe quitarse la cuenta, volver a agregarla y seleccionar “Sign in with Google”
    • Si en otras plataformas o apps se usa CardDAV solo con contraseña, debe migrarse a un método compatible con OAuth
  • Las apps que no admitan OAuth deben reemplazarse por apps que sí lo ofrezcan, o bien se debe crear una app password para el acceso
  • Los desarrolladores deben actualizar el método de conexión de sus apps a OAuth 2.0 para mantener la compatibilidad con las cuentas de Google Workspace

Cuentas personales de Google y alcance de la medida

  • Para los usuarios de cuentas personales de Google, se eliminará el interruptor para activar o desactivar IMAP en la configuración de Gmail
  • El acceso IMAP en cuentas personales siempre ha estado habilitado mediante OAuth, y las conexiones actuales no se verán afectadas
  • Los usuarios de cuentas personales de Google no necesitan tomar ninguna acción adicional
  • Este cambio se aplica a todos los clientes de Google Workspace

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-20
Comentarios en Hacker News

  • Al leer esto se me paró el corazón por un momento, porque tengo varios scripts y herramientas integrados con Gmail
    Aun así, parece que todo bien. Las contraseñas de aplicación parecen seguir funcionando, y este cambio se parece más a eliminar el soporte para Less Secure Apps que usan el nombre de usuario/contraseña normal de la cuenta
    Da vértigo solo pensar cuánta automatización moriría si Google de verdad eliminara todo lo que no sea OAuth
    No me gusta la complejidad de OAuth, y me gustó cómo esta documentación de módulo Perl desmenuza su estructura. Claramente parece escrita por alguien tan frustrado como yo: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

    • No parece que migrar los scripts vaya a ser muy difícil
      Pasé por un problema parecido, y en un Workspace las contraseñas de aplicación estaban bloqueadas. Basta con obtener un token de OAuth con un pequeño script de Python y usarlo como si fuera la contraseña: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
      Como ejemplo, ver https://github.com/lefcha/imapfilter/issues/186
    • Ojalá Gmail mismo dejara de ser una Less Secure App como cliente
      Ahora tengo que seguir dejando activado el interruptor de LSA solo para que mi cuenta principal de Gmail pueda enviar por SMTP usando las credenciales de varias otras cuentas de Gmail. No entiendo por qué Gmail es visto como una LSA por otras cuentas de Gmail
    • El problema es que no puedes configurar directamente las contraseñas de aplicación, y además su seguridad parece ridículamente débil
      Son 16 letras minúsculas, separadas por espacios cada 4 caracteres, sin números ni caracteres especiales
      Keepass las evalúa como una contraseña débil de 65 bits de entropía al quitar los espacios
      No veo cómo eso es una mejora
    • https://github.com/smallstep/cli podría ayudar, ya que implementa algunos flujos de OAuth en la línea de comandos

  • Si no puedes cambiarte a OAuth, puedes usar mi proxy para que clientes IMAP/POP/SMTP que no soportan OAuth 2.0 directamente funcionen con proveedores de correo “modernos”: https://github.com/simonrob/email-oauth2-proxy
    El cliente no necesita saber absolutamente nada de OAuth

    • El título enviado lleva a confusión. En realidad no es “solo OAuth”, sino OAuth y contraseñas de aplicación
      Si no puedes pasarte a OAuth, puedes crear una contraseña de aplicación y seguir usándola como contraseña IMAP, como siempre
    • Excelente. De esta forma, clientes como mu/mu4e podrían seguir funcionando con Gmail y outlook365
    • Lamentablemente, este método requiere que el usuario configure por su cuenta un cliente OAuth, y es un proceso bastante manual y tedioso

  • Porque IMAP, SMTP y POP dan un acceso considerable a la cuenta de Google y a gran parte de la vida digital de una persona, pero no hay forma de aplicar autenticación de dos factores, ni tampoco ofrecen verificación anti-bots
    Eso hace que los ataques de credential stuffing sean muy fáciles, y a la escala de Google esos ataques pueden arruinarle la vida a mucha gente
    Este es un buen cambio y debió haberse hecho hace años. De hecho, ya habían avanzado un poco al desactivar por defecto el acceso IMAP/POP/SMTP, y así la mayoría de los usuarios queda protegida. Esto es para los usuarios restantes

    • Agregar autenticación de dos factores a SMTP/POP/IMAP es trivial
      En Dovecot basta con elegir el módulo de autenticación que prefieras y hacer que lea la contraseña de entrada como pwd+otp code. Si el usuario tiene activada la autenticación de dos factores, tomas los últimos 6 caracteres y los comparas con el TOTP
      Si coincide, permites esa IP por x minutos o aplicas la política que quieras
      Sorprendentemente funciona bien
    • Si alguien de verdad quiere seguir descargando todo el correo a la antigua, supongo que en Gmail podría configurar el reenvío de todos los correos a otra dirección
      Esa dirección no tendría que ser Gmail, sino algún servicio que siga permitiendo IMAP/POP. No es una solución universal, pero para algunos casos de uso podría ser un atajo aceptable
    • Las contraseñas al estilo antiguo ofrecen una seguridad razonable, pero no permiten plantar cookies identificables del usuario en el dispositivo cliente
    • Que “no permita verificación anti-bots” en realidad es una característica

  • Esto parece un intento de sacar a los usuarios de las excelentes apps de correo nativas para empujarlos hacia las apps propias de Google.
    Sin gmail.app ni Google Sync, que pronto desaparecerá, no se pueden recibir notificaciones de correo en tiempo real. No me gusta. Y menos aún cuando estoy pagando por Workspace. En escritorio, Mimestream todavía funciona, pero parece que también lo van a apuntar pronto.

    • Google ahora debería adoptar JMAP.
      JMAP es un buen protocolo estándar, pero su adopción es absurdamente baja por el problema del huevo y la gallina entre los proveedores de correo y las apps de correo. Si Gmail soportara JMAP, podría incentivar a implementadores de todos lados a darle soporte. JMAP también soporta notificaciones y otras funciones.
    • Implementar OAuth no es tan difícil. En el proceso de configuración hace falta un WebView, pero después de eso la app de correo puede guardar el token como si fuera una contraseña y seguir funcionando.
      OAuth para correo existe desde hace años y está incluido en varios RFC relacionados con autenticación de email.
      Thunderbird y varias apps móviles soportan bien Gmail usando OAuth. El problema más grande parece ser que muchas apps de escritorio dejaron de implementar cambios de IMAP y SMTP hace como 10 años.
      Si es una app de correo que ya no recibe mantenimiento, entonces se puede usar una contraseña específica de aplicación como indica Google en el post enlazado. Esas seguirán funcionando. Lo que desaparece es el método de nombre de usuario/contraseña hardcodeado de la cuenta principal.
      Para los usuarios de Office 2016 va a ser un dolor de cabeza importante, porque el 30 de septiembre todavía llega unos 9 meses antes del fin de soporte de Outlook. Pero para la mayoría de los usuarios parece que será un arreglo bastante sencillo.
    • Las contraseñas específicas de aplicación seguirán funcionando, y se pueden usar sin problema aunque la app nativa no soporte el flujo normal de OAuth.
    • Entiendo que cada quien se preocupa por cosas distintas, pero yo no voy a abandonar Thunderbird por las notificaciones de correo en tiempo real.
      El correo electrónico es asíncrono, así que no debería haber problema en enterarse de un mensaje 10 minutos después de que llegó. Si es un correo que estás esperando, de todos modos vas a estar dándole refrescar hasta que llegue.
      Si es más urgente, que manden un SMS. Ojalá no llamen. Odio las llamadas.
    • Totalmente de acuerdo. Pago por una cuenta de Gmail y la odio a cada momento, pero en filtrado de spam casi nada parece acercarse a Gmail.

  • Está esta explicación de que “las contraseñas de aplicación son códigos de 16 dígitos que otorgan a una app o dispositivo menos seguro acceso a tu Cuenta de Google, y solo pueden usarse en cuentas con la verificación en dos pasos activada”: https://support.google.com/mail/answer/185833
    ¿No es gracioso que algo llamado “app o dispositivo menos seguro” quede casi al mismo nivel de seguridad que una app con soporte de OAuth si solo se usan mecanismos del lado del servidor que Google podría haber promovido desde hace tiempo? Técnicamente ni siquiera parece una función de la app.
    Claro, se podría decir que simplificarlo se justifica porque llamarlo “apps con flujo seguro pero menos conveniente” comunica peor. El problema más grande es que Google tiende a interpretar las preocupaciones de seguridad de formas que favorecen su propia agenda, y este fragmento no es la excepción.

    • Google lleva muchísimo tiempo impulsando la verificación en dos pasos y las contraseñas específicas de aplicación.
      Ahora simplemente lo está haciendo obligatorio para apps que ya no se pueden actualizar para soportar OAuth.
    • OAuth y las contraseñas de aplicación no son equivalentes. OAuth es mucho menos vulnerable al phishing y también ofrece mucho más control sobre permisos específicos.
      Las contraseñas de aplicación son funcionalmente casi todo o nada, pero con OAuth puedes configurar permisos como leer, modificar o cambiar ajustes.

  • Lo más molesto de Google OAuth2 en Android es que, para iniciar sesión con una cuenta de Google en un cliente de correo o calendario, todo el teléfono tiene que estar vinculado a esa cuenta de Google.
    Además, esa cuenta de Google termina teniendo incluso permisos de política del dispositivo. En mi opinión, eso no tiene ningún sentido.
    Usar OAuth2 en un WebView dentro de la app también es difícil de esquivar en Android, porque Google puede restringirlo fácilmente.

    • ¿No podrían clientes alternativos como K-9 implementar OAuth por su cuenta? En Thunderbird de escritorio me parece que lo configuré para que funcionara con OAuth, al menos con Office365.
      Lamentablemente no hay muchos clientes de correo confiables. Bastantes terminan enviando las credenciales a un servidor remoto.
      Edit: K-9 ya soporta OAuth para IMAP.
      https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
    • Para la gente común que no conoce la diferencia entre Google, Android y Chrome, resulta molesto que todas estas cosas estén separadas.

  • El texto es un poco ambiguo, pero parece que las contraseñas específicas de aplicación van a seguir funcionando.
    En la cita dice que los escáneres y dispositivos que envían correo mediante SMTP o LSA deben configurarse para usar OAuth, usar un método alternativo o establecer una contraseña de aplicación para el dispositivo.
    También dice que las apps que no soportan OAuth deben cambiarse por apps que sí ofrezcan OAuth o crear una contraseña de aplicación para acceder.

    • La parte citada no me parece nada ambigua. Claramente las contraseñas de aplicación van a seguir siendo compatibles.
    • A mí tampoco me quedó 100% claro. Por el texto sí parece claro que SMTP soporta contraseñas de aplicación, pero no quedaba claro si IMAP también seguiría soportándolas.
      Así que ayer le pregunté directamente a Google Workspace Support, y la respuesta fue: “las contraseñas de aplicación soportan IMAP, POP y todas las configuraciones de SMTP”.
      La segunda oración insistía en seguir empujando la adopción de OAuth. Yo también quisiera hacerlo, pero el costo de las revisiones de seguridad recurrentes es imposible de sostener para una app SaaS pequeña como la nuestra, así que por suerte seguiremos usando contraseñas de aplicación.

  • Esto trata sobre las cuentas de Workspace, y es un cambio que ya se había aplicado a las cuentas normales de Gmail hace algunos años

    • No es del todo correcto
      Todavía accedo a mi cuenta personal de Gmail desde Mail.app en iPhone usando la opción de Microsoft Exchange, y recibo notificaciones push de esta manera sin quedar atado a Fetch
      Funciona porque una conexión de Google Sync creada con mi cuenta personal antes de la fecha de descontinuación de hace unos 10 años sigue vigente y quedó como "derecho adquirido"
      Así que, para hacerlo funcionar, basta con cambiar el GUID de Exchange del iPhone por el GUID del teléfono que había iniciado sesión en Google Sync antes de que se bloquearan los nuevos inicios de sesión
      Por suerte, es posible cambiar ese GUID creando un respaldo del iPhone, modificando el archivo plist dentro del respaldo y luego restaurándolo
      Incluso hoy sigo usando Mail.app y notificaciones push para mi cuenta personal de Gmail en un iPhone 14 Pro

  • Entiendo por el anuncio que las contraseñas de aplicación se mantendrán por un tiempo. Pero si Google llega a eliminar también las contraseñas de aplicación, el uso de clientes de terceros con GMail quedará muy restringido por la forma en que los clientes OAuth tienen que pagar de su bolsillo una evaluación de seguridad
    El correo electrónico sigue siendo uno de los últimos “protocolos de mensajería abiertos” de uso amplio, y todavía se puede elegir el cliente, así que sería un desarrollo triste

    • Todos son libres de usar otra cosa que no sea GMail. Nadie está obligado

  • En el trabajo estamos lidiando con la transición de Microsoft a OAuth, y ha sido bastante problemática
    Parte del problema es que es demasiado opaco. Envías el token y el servidor solo responde “no” sin ninguna explicación adicional
    Pasé días tratando de averiguar por qué no funcionaba el flujo de Client Credentials, y al final encontré en lo profundo de un foro de ayuda la respuesta: “ah, el client credentials flow todavía no es compatible”. Ahora sí funciona para IMAP/POP, pero, si no recuerdo mal, todavía no para SMTP. Eso sí, para SMTP OAuth todavía no es obligatorio
    Lo siguiente fue averiguar el scope correcto, y en ese momento no estaba muy bien documentado. Los mensajes de error del servidor tampoco ayudaban en absoluto
    ¿Los servidores de correo de Google son mejores?

    • Los HTTP 401 y 403 genéricos son para evitar https://en.wikipedia.org/wiki/Oracle_attack
      Por desgracia, el servidor no puede darse el lujo de dar información “útil” a clientes no autenticados
    • Microsoft es sorprendentemente bueno para crear mensajes de error opacos. La experiencia de usuario es un desastre total