Descontinuação do suporte ao Google Sync e a Apps menos seguras

Artigo original ↗ Discussão no Hacker News ↗

O Google está aposentando o Google Sync e o acesso por senha de “Apps menos seguras” para contas do Workspace, empurrando organizações para autenticação baseada em OAuth ou senhas específicas de app para IMAP, POP e SMTP. Os comentaristas acolhem uma proteção mais forte contra credential stuffing e phishing, mas se preocupam com a quebra de clientes legados, impressoras e scripts, com a complexidade e o custo do OAuth para projetos pequenos e com uma aparente pressão para os próprios apps e o lock-in ao ecossistema do Google. Muitos apontam senhas de app e provedores de e-mail de terceiros como alternativas práticas, ao mesmo tempo em que questionam por quanto tempo o Google manterá essas opções disponíveis.

Escopo da mudança

  • Muitos observam que o título do HN é enganoso: o Google está desativando os “Apps menos seguras” (nome de usuário + senha principal) e o Google Sync (ActiveSync) para o Workspace, não o IMAP/SMTP/POP em si.
  • Senhas específicas de app e OAuth continuam suportados; vários usuários confirmam que o suporte do Workspace afirmou explicitamente que senhas de app funcionarão para IMAP, POP e SMTP.
  • O Gmail pessoal perdeu as LSAs antes; isso conclui a transição para o Workspace.

Senhas de app e dispositivos legados

  • Há grande preocupação com impressoras, scanners e clientes antigos (por exemplo, Outlook 2007, Mail do iOS via Exchange).
  • O consenso no tópico: esses podem continuar a funcionar por meio de senhas de app ou, em alguns casos, de SMTP relays.
  • Alguns administradores relatam que as senhas de app funcionam de forma confiável; outros acham-nas confusas ou pouco confiáveis e temem que usuários comuns/TI tenham dificuldades.

Complexidade e atrito do OAuth

  • Muitos reclamam que o OAuth2 é confuso, opaco e propenso a erros, especialmente para servidores sem interface e scripts.
  • Problemas citados: mensagens de erro pouco claras, comportamento mutável de tokens, particularidades de refresh token e a alta exigência (e custo) do Google para ter um cliente de produção verificado.
  • Várias ferramentas e contornos são mencionados (proxies OAuth, auxiliares de CLI, rclone, etc.), mas frequentemente exigem configuração manual do cliente OAuth.

Argumentos de segurança e força das senhas

  • Lado favorável à mudança: LSAs permitem credential stuffing e não têm 2FA; OAuth e senhas de app reduzem o raio de impacto e o risco de phishing.
  • Outros argumentam que senhas fortes e únicas + TLS e 2FA opcional já são suficientes, chamando isso de “teatro de segurança” e hostil ao usuário.
  • Debate sobre a entropia das senhas de app (16 caracteres aleatórios minúsculos). A maioria conclui que 65–75 bits é mais do que suficiente, especialmente com limites de tentativas online.

Preocupações com lock-in, UX e concorrência

  • Vários veem isso como uma forma de empurrar os usuários para longe de clientes de terceiros e em direção aos apps do Gmail, especialmente diante da perda do push Exchange no Mail do iOS e da resistência do Google a protocolos como JMAP.
  • Algumas instituições já restringem IMAP com Exchange/O365, reforçando temores de uma tendência mais ampla em direção a ecossistemas proprietários.
  • Um número de usuários discute ou endossa alternativas (self-hosting, Fastmail, Proton, Tuta), citando melhor interoperabilidade ou tratamento de spam.

Incertezas

  • O futuro das senhas de app é visto como instável: a documentação do Google as desencoraja, e algumas organizações relatam avisos prévios de descontinuação.
  • O nível exato de suporte de longo prazo para IMAP/SMTP não-OAuth via senhas de app é visto como “por enquanto”, não garantido.