Google encerra suporte ao Google Sync e a apps que usam apenas senha
(workspaceupdates.googleblog.com)- O Google Workspace está encerrando o método de login Less Secure Apps (LSA), que compartilha apenas nome de usuário e senha, e passará a exigir login baseado em OAuth para sincronização de e-mail, calendário e contatos
- O cronograma de encerramento começou em duas fases, em 15 de junho de 2024 e 30 de setembro de 2024, mas após pausa e retomada do rollout, o suporte a LSA foi descontinuado a partir de 1º de maio de 2025
- Conexões CalDAV, CardDAV, IMAP, SMTP e POP que usam apenas senha, além do Google Sync, serão afetadas, e tanto novos quanto antigos usuários do Google Sync entram na migração
- Administradores devem compartilhar com os usuários as instruções de migração para OAuth, e os perfis baseados em senha distribuídos via MDM também precisam ser alterados para o método de readicionar a Conta do Google com OAuth
- Usuários que não tomarem providências até a data limite não conseguirão fazer login por erro na combinação de nome de usuário e senha, e desenvolvedores devem atualizar a forma de conexão dos apps para OAuth 2.0 para manter compatibilidade com o Workspace
Fim do login usando apenas senha
- O Google Workspace não oferece mais suporte a formas de login em que apps ou dispositivos de terceiros pedem diretamente o nome de usuário e a senha do Google
- Esse método é chamado de Less Secure Apps (LSA) e aumenta o risco de acesso não autorizado à conta, porque exige compartilhar as credenciais da Conta do Google com apps e dispositivos de terceiros
- A alternativa é Sign in with Google, que usa OAuth, padrão de autenticação da indústria já adotado pela maioria dos apps e dispositivos de terceiros
- O Google anunciou essa mudança em 2019 e depois voltou a divulgar o cronograma de aplicação
Cronograma de encerramento e histórico de adiamentos
- O fim do acesso por LSA foi originalmente dividido em duas fases
- A partir de 15 de junho de 2024, a configuração de LSA no Admin Console foi removida e não pode mais ser alterada
- Usuários que já estavam com o recurso ativado puderam continuar se conectando, mas usuários desativados não puderam mais acessar LSA
- Isso inclui apps de terceiros baseados em CalDAV, CardDAV, IMAP, SMTP e POP que acessam Gmail, Google Calendar e Contacts apenas com senha
- A configuração de ativar/desativar IMAP nas preferências do Gmail do usuário também foi removida
- Usuários que já usavam LSA antes dessa data originalmente poderiam continuar até 30 de setembro de 2024
- A partir de 30 de setembro de 2024, estava previsto o desligamento do acesso por LSA em todas as contas do Google Workspace
- CalDAV, CardDAV, IMAP, POP e Google Sync deixariam de funcionar quando o login fosse feito apenas com senha
- Para continuar usando, seria necessário entrar com OAuth, forma de acesso mais segura
- Depois disso, o cronograma foi ajustado várias vezes
- Na atualização de 15 de outubro de 2024, o rollout foi pausado até o fim do ano e remarcado para recomeçar em janeiro de 2025
- Na atualização de 27 de janeiro de 2025, o rollout foi retomado e a desativação final passou a estar planejada para março de 2025
- Na atualização de 12 de fevereiro de 2025, a data de fim do suporte a LSA mudou para 14 de março de 2025
- Na atualização de 29 de abril de 2025, LSA passou a não ser mais suportado a partir de 1º de maio de 2025
Pontos de verificação para organizações que usam Google Sync
- Essa mudança também inclui o fim do Google Sync
- O cronograma original para o encerramento do Google Sync era o seguinte
- A partir de 15 de junho de 2024, novos usuários não poderiam mais se conectar ao Google Workspace via Google Sync
- A partir de 30 de setembro de 2024, usuários existentes do Google Sync também não poderiam mais se conectar ao Google Workspace
- É possível verificar o uso de Google Sync na organização pelo Admin Console
- Caminho: Devices > Mobile & Endpoints > Devices
- Filtro: Type: Google Sync
Impacto para administradores e configurações de MDM
- Administradores devem orientar os usuários finais a migrar para métodos de acesso baseados em OAuth para continuar usando apps com contas do Google Workspace
- Informações sobre os usuários afetados devem ser enviadas por e-mail às organizações ao longo dos próximos meses
- Organizações que configuravam perfis IMAP, CalDAV, CardDAV, POP e Exchange ActiveSync (Google Sync) por meio de fornecedores de MDM também serão afetadas
- Desde 15 de junho de 2024, o push por MDM de IMAP, CalDAV, CardDAV, SMTP, POP e Exchange ActiveSync (Google Sync) baseados em senha não funciona para clientes que tentam se conectar pela primeira vez a LSA
- Ao usar o Google Endpoint Management, não é possível ativar a configuração Custom Push Configuration para CalDAV e CardDAV
- Desde 30 de setembro de 2024, o push baseado em senha de IMAP, CalDAV, CardDAV, SMTP e POP deixou de funcionar para usuários existentes
- Administradores devem usar o fornecedor de MDM para distribuir a Conta do Google, método que readiciona a conta do Google com OAuth em dispositivos iOS
- O push baseado em senha de Exchange ActiveSync (Google Sync) também deixa de funcionar para usuários existentes
- As configurações “Custom push configuration-CalDAV” e “Customer push configuration-CardDAV” do Google Endpoint Management deixam de ter efeito
Como migrar em dispositivos, apps e para desenvolvedores
- Se um scanner ou outro dispositivo envia e-mail via SMTP ou LSA, será necessário um dos seguintes caminhos
- Configurar o uso de OAuth
- Usar um método alternativo
- Configurar uma senha de app para esse dispositivo
- Apps que acessam uma Conta do Google apenas com nome de usuário e senha precisam migrar
- Se nada for feito até a data limite, será exibido um erro informando que a combinação de nome de usuário e senha está incorreta, e o login não será possível
- Ações por app de e-mail
- Outlook 2016 ou anterior deve ser substituído por Microsoft 365, Outlook for Windows ou Outlook for Mac, que oferecem suporte a acesso via OAuth
- Como alternativa, é possível usar o Google Workspace Sync for Microsoft Outlook
- Thunderbird e outros clientes de e-mail devem readicionar a Conta do Google e configurar IMAP com OAuth
- Se o login no app Mail do iOS ou macOS, ou no Outlook for Mac, estiver sendo feito apenas com senha, é preciso remover a conta, adicioná-la novamente e escolher Sign in with Google
- Apps de calendário e contatos também precisam migrar para métodos com suporte a OAuth
- Apps de calendário baseados em CalDAV e senha devem ser trocados por uma opção com suporte a OAuth, e o Google recomenda o app Google Calendar
- Se o login no app de calendário do iOS ou macOS estiver sendo feito apenas com senha, é preciso remover a conta, adicioná-la novamente e escolher Sign in with Google
- Se você sincroniza contatos via CardDAV no iOS ou macOS com login apenas por senha, é preciso remover a conta, adicioná-la novamente e escolher Sign in with Google
- Em outras plataformas ou apps que usam apenas CardDAV e senha, será necessário migrar para uma opção com suporte a OAuth
- Apps que não oferecem suporte a OAuth devem ser substituídos por apps que ofereçam OAuth, ou então o acesso deve ser feito com uma senha de app
- Desenvolvedores devem atualizar a forma de conexão dos apps para OAuth 2.0 para manter compatibilidade com contas do Google Workspace
Contas pessoais do Google e escopo de aplicação
- Para usuários de contas pessoais do Google, o botão de ativar/desativar IMAP nas configurações do Gmail será removido
- O acesso IMAP em contas pessoais já fica sempre ativado via OAuth, e as conexões atuais não serão afetadas
- Usuários de contas pessoais do Google não precisam tomar nenhuma ação
- Essa mudança se aplica a todos os clientes do Google Workspace
1 comentários
Opiniões do Hacker News
Ao ler isto, levei um susto por um instante — porque tenho vários scripts e ferramentas integrados ao Gmail
Ainda assim, parece que está tudo bem. As senhas de app aparentemente continuam funcionando, e esta mudança parece mais uma remoção do suporte a Less Secure Apps, que usam o nome de usuário/senha comum da conta
Só de pensar em quanta automação morreria se o Google realmente eliminasse tudo que não fosse OAuth, já dá vertigem
Não gosto da complexidade do OAuth, e gostei de como a documentação deste módulo Perl destrinchou a estrutura. Com certeza parece ter sido escrita por alguém tão irritado quanto eu: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
Passei por um problema parecido, e em um Workspace as senhas de app estavam bloqueadas. Basta pegar um token OAuth com um pequeno script em Python e usá-lo como se fosse uma senha: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Veja o exemplo em https://github.com/lefcha/imapfilter/issues/186
Hoje preciso manter a chave LSA ativada para que minha conta principal do Gmail possa enviar via SMTP usando as credenciais de várias outras contas do Gmail. Não entendo por que o Gmail é visto como LSA por outras contas do Gmail
São 16 letras minúsculas, separadas por espaços a cada 4 caracteres, sem números nem caracteres especiais
O Keepass avalia isso, quando os espaços são removidos, como uma senha fraca de 65 bits de entropia
Não sei como isso é uma melhoria
Se você não consegue migrar para OAuth, meu proxy permite usar clientes IMAP/POP/SMTP que não dão suporte direto a OAuth 2.0 com provedores de e-mail “modernos”: https://github.com/simonrob/email-oauth2-proxy
O cliente não precisa saber nada sobre OAuth
Se você não consegue migrar para OAuth, crie uma senha de app e continue usando-a normalmente como senha IMAP
Porque IMAP, SMTP e POP dão acesso significativo à conta Google e à vida da pessoa como um todo, mas não há como fazer autenticação de dois fatores, nem oferecem verificação antirobô
Isso torna ataques de preenchimento de credenciais muito fáceis e, na escala do Google, esses ataques podem arruinar a vida de muita gente
Esta é uma boa mudança e deveria ter acontecido anos atrás. Na verdade, em certa medida isso já foi feito ao desativar por padrão o acesso IMAP/POP/SMTP, e a maioria dos usuários fica protegida por isso. Esta medida é para os usuários restantes
No Dovecot, basta escolher seu módulo de autenticação preferido e alterá-lo para ler a senha informada como
pwd+otp code. Se o usuário tiver ativado a autenticação de dois fatores, leia os últimos 6 dígitos e compare com o TOTPSe corresponder, permita aquele IP por x minutos, ou aplique a política que quiser
Funciona surpreendentemente bem
Esse endereço pode não ser do Gmail e pode estar em um lugar que continue permitindo IMAP/POP. Não é uma solução milagrosa, mas pode ser uma alternativa aceitável para alguns casos de uso
Isto é uma tentativa de tirar os usuários de ótimos apps de e-mail nativos e empurrá-los para os próprios apps do Google.
Sem o gmail.app ou o Google Sync, que será descontinuado em breve, não dá para receber notificações de e-mail em tempo real. Não gosto disso. Mesmo pagando pelo Workspace, continuo não gostando. No desktop, o Mimestream ainda funciona, mas acho que ele também será alvo em breve.
O JMAP é um bom protocolo padrão, mas sua adoção é absurdamente baixa por causa do problema do ovo e da galinha entre provedores de e-mail e apps de e-mail. Se o Gmail oferecer suporte a JMAP, pode incentivar implementadores em todos os lugares a também oferecer suporte. O JMAP também suporta notificações e outros recursos.
OAuth para e-mail faz parte de vários RFCs relacionados à autenticação de e-mail e existe há anos.
O Thunderbird e vários apps móveis oferecem bom suporte ao Gmail usando OAuth. O problema maior é que muitos apps de desktop parecem ter parado de implementar mudanças em IMAP e SMTP há cerca de 10 anos.
Se for um app de e-mail que não é mais mantido, dá para usar senhas específicas de app, como o Google orienta no texto linkado. Elas continuarão funcionando. O que vai desaparecer é o método de usuário/senha codificado diretamente da conta principal.
Isso deve ser uma grande dor de cabeça para usuários do Office 2016, porque 30 de setembro ainda fica cerca de 9 meses antes do fim do suporte ao Outlook. Mas, para a maioria dos usuários, parece ser uma correção bem simples.
E-mail é assíncrono, então não deveria haver problema em saber de uma mensagem 10 minutos depois de ela chegar. Se for um e-mail que estou esperando, de qualquer forma vou ficar apertando atualizar até ele chegar.
Se for mais urgente, mande mensagem de texto. Só não ligue, por favor. Odeio chamadas.
Há uma explicação dizendo que “senhas de app são códigos de 16 dígitos que dão a apps ou dispositivos menos seguros permissão para acessar sua Conta do Google, e só podem ser usadas em contas com verificação em duas etapas ativada”: https://support.google.com/mail/answer/185833
Não é engraçado que “apps ou dispositivos menos seguros” fiquem praticamente equivalentes, em termos de segurança, a apps com suporte a OAuth se usarem apenas um mecanismo do lado do servidor que o Google poderia ter incentivado há muito tempo? Tecnicamente, isso nem parece ser uma funcionalidade do app.
Claro, dá para dizer que a simplificação se justifica, porque chamar de “apps com fluxo de trabalho seguro menos conveniente” não comunica tão bem. O problema maior é que o Google tende a interpretar preocupações de segurança sempre de um jeito favorável à própria agenda, e este pedaço não é exceção.
Agora está apenas tornando isso obrigatório para apps que não conseguem ser atualizados para oferecer suporte a OAuth.
Senhas de app são funcionalmente quase um tudo ou nada, enquanto no OAuth é possível configurar permissões como leitura, modificação e alteração de configurações.
O ponto mais irritante do Google OAuth2 no Android é que, para entrar com uma conta do Google em um cliente de e-mail ou calendário, o telefone inteiro precisa ficar associado a essa conta do Google.
Além disso, essa conta do Google passa a ter até permissões de política do dispositivo. Na minha opinião, isso não faz sentido nenhum.
Usar OAuth2 dentro de um WebView no próprio app também é algo que o Google pode restringir facilmente no Android, então é difícil contornar.
Infelizmente, não há muitos clientes de e-mail confiáveis. Muitos acabam enviando credenciais para servidores remotos.
Correção: o k9 já suporta OAuth para IMAP.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
A redação é um pouco ambígua, mas parece que senhas específicas de app continuarão funcionando.
No trecho citado, diz que scanners e dispositivos que enviam e-mail por SMTP ou LSA devem ser configurados para usar OAuth, usar um método alternativo ou configurar uma senha de app para o dispositivo.
Também diz que apps que não suportam OAuth devem ser trocados por apps que ofereçam OAuth, ou então acessar criando uma senha de app.
Por isso perguntei ontem diretamente ao Google Workspace Support, e a resposta foi: “senhas de aplicativo oferecem suporte a IMAP, POP e todas as configurações de SMTP”.
A segunda frase era sobre continuar pressionando pela adoção de OAuth. Eu também gostaria disso, mas o custo das revisões de segurança recorrentes é inviável para um app SaaS pequeno como o nosso, então felizmente vamos continuar usando senhas de app.
Isto se refere a contas do Workspace, e é uma mudança que já foi aplicada a contas comuns do Gmail há alguns anos
Ainda acesso minha conta pessoal do Gmail no Mail.app do iPhone pela opção Microsoft Exchange, e recebo notificações push dessa forma, sem ficar preso ao Fetch
O motivo de funcionar é que a conexão criada no Google Sync com a conta pessoal antes da data de descontinuação, há cerca de 10 anos, ainda é mantida e reconhecida como um “direito adquirido”
Então, para fazer funcionar, basta alterar o GUID do Exchange do iPhone para o GUID do celular usado na época em que se fez login no Google Sync antes do bloqueio de novos logins
Felizmente, é possível fazer essa alteração de GUID criando um backup do iPhone, modificando o arquivo plist dentro do backup e depois restaurando
Ainda hoje uso o Mail.app e notificações push para uma conta pessoal do Gmail em um iPhone 14 Pro
Pelo comunicado, entendo que as senhas de app serão mantidas por enquanto. Mas, se um dia o Google também eliminar as senhas de app, o uso de clientes de terceiros no GMail ficará bastante limitado por causa da estrutura em que clientes OAuth precisam passar por uma avaliação de segurança por conta própria
O e-mail ainda é um dos últimos “protocolos abertos de mensagens” amplamente usados, e é possível escolher o cliente; seria triste ver esse caminho
Na empresa, estamos lidando com a migração para OAuth da Microsoft, e tem sido bem problemática
Parte do problema é que tudo é opaco demais. Quando você envia um token, o servidor apenas responde “não”, sem explicação adicional
Passei dias tentando descobrir por que o fluxo Client Credentials não funcionava e, no fim, encontrei no fundo de um fórum de ajuda a resposta: “ah, o client credentials flow ainda não é compatível”. Hoje ele é compatível com IMAP/POP, mas, se me lembro bem, ainda não com SMTP. Porém, no SMTP, OAuth ainda não é obrigatório
Depois foi descobrir o escopo (scope) correto, que na época não era muito bem documentado. As mensagens de erro do servidor também não ajudam em nada
Os servidores de e-mail do Google são melhores?
Infelizmente, o servidor não pode se dar ao luxo de fornecer informações “úteis” a clientes não autenticados