Google met fin à Google Sync et aux applications utilisant uniquement un mot de passe
(workspaceupdates.googleblog.com)- Google Workspace met fin à la méthode Less Secure Apps (LSA), qui consiste à se connecter en partageant uniquement un nom d’utilisateur et un mot de passe, et exige une connexion basée sur OAuth pour la synchronisation des e-mails, calendriers et contacts
- Le calendrier d’arrêt a commencé en deux étapes, les 15 juin et 30 septembre 2024, mais après une suspension puis une reprise du déploiement, les LSA ne sont plus prises en charge à partir du 1er mai 2025
- Les connexions CalDAV, CardDAV, IMAP, SMTP et POP utilisant uniquement un mot de passe, ainsi que Google Sync, sont concernées ; les nouveaux utilisateurs comme les utilisateurs existants de Google Sync doivent migrer
- Les administrateurs doivent communiquer aux utilisateurs concernés les consignes de migration vers OAuth, et les profils basés sur un mot de passe déployés via MDM doivent aussi être remplacés par un nouvel ajout du compte Google avec OAuth
- Les utilisateurs n’ayant pas agi avant la date d’arrêt ne pourront pas se connecter en raison d’une erreur liée à la combinaison nom d’utilisateur/mot de passe, et les développeurs doivent mettre à jour le mode de connexion de leurs applications vers OAuth 2.0 pour assurer la compatibilité avec Workspace
Fin des connexions utilisant uniquement un mot de passe
- Google Workspace ne prend plus en charge les méthodes de connexion dans lesquelles des applications ou appareils tiers demandent directement le nom d’utilisateur et le mot de passe Google
- Cette méthode est appelée Less Secure Apps (LSA) ; elle impose de partager les identifiants du compte Google avec des applications et appareils tiers, ce qui augmente le risque d’accès non autorisé au compte
- L’alternative est Sign in with Google, qui utilise OAuth, une méthode d’authentification standard du secteur déjà employée par la plupart des applications et appareils tiers
- Google a annoncé ce changement en 2019, puis a de nouveau publié le calendrier d’application
Calendrier d’arrêt et reports
- La fin de l’accès LSA était initialement prévue en deux étapes
- À partir du 15 juin 2024, le paramètre LSA a été supprimé de l’Admin Console et ne peut plus être modifié
- Les utilisateurs pour lesquels il était déjà activé peuvent continuer à se connecter, mais ceux pour lesquels il est désactivé ne peuvent pas accéder aux LSA
- Cela inclut les applications tierces basées sur CalDAV, CardDAV, IMAP, SMTP et POP qui accèdent à Gmail, Google Calendar et Contacts uniquement avec un mot de passe
- Le paramètre d’activation/désactivation d’IMAP a aussi été supprimé des paramètres Gmail des utilisateurs
- Les utilisateurs qui utilisaient déjà les LSA avant cette date pouvaient initialement continuer à les utiliser jusqu’au 30 septembre 2024
- À partir du 30 septembre 2024, il était prévu de désactiver l’accès LSA pour tous les comptes Google Workspace
- CalDAV, CardDAV, IMAP, POP et Google Sync ne fonctionnent plus lorsque la connexion repose uniquement sur un mot de passe
- Pour continuer à les utiliser, il faut se connecter avec une méthode d’accès plus sûre, OAuth
- Le calendrier a ensuite été ajusté à plusieurs reprises
- Dans la mise à jour du 15 octobre 2024, le déploiement a été suspendu jusqu’à la fin de l’année, avec une reprise prévue en janvier 2025
- Dans la mise à jour du 27 janvier 2025, le déploiement a repris, avec une désactivation finale prévue en mars 2025
- Dans la mise à jour du 12 février 2025, la date de fin de prise en charge des LSA est passée au 14 mars 2025
- Dans la mise à jour du 29 avril 2025, les LSA ne sont plus prises en charge à partir du 1er mai 2025
Points à vérifier pour les organisations utilisant Google Sync
- Ce changement inclut aussi la fin de Google Sync
- Le calendrier initial d’arrêt de Google Sync était le suivant
- À partir du 15 juin 2024, les nouveaux utilisateurs ne peuvent plus se connecter à Google Workspace via Google Sync
- À partir du 30 septembre 2024, les utilisateurs existants de Google Sync ne peuvent plus non plus se connecter à Google Workspace
- L’utilisation de Google Sync au sein d’une organisation peut être vérifiée dans l’Admin Console
- Chemin : Devices > Mobile & Endpoints > Devices
- Filtre : Type: Google Sync
Impact pour les administrateurs et les configurations MDM
- Les administrateurs doivent indiquer aux utilisateurs finaux de passer à une méthode d’accès basée sur OAuth afin de continuer à utiliser leurs applications avec leur compte Google Workspace
- Les informations sur les utilisateurs concernés seront fournies par e-mail aux organisations au cours des prochains mois
- Les organisations qui configuraient des profils IMAP, CalDAV, CardDAV, POP ou Exchange ActiveSync (Google Sync) via un fournisseur MDM sont également concernées
- À partir du 15 juin 2024, les push MDM basés sur un mot de passe pour IMAP, CalDAV, CardDAV, SMTP, POP et Exchange ActiveSync (Google Sync) ne fonctionnent pas pour les clients qui tentent de se connecter aux LSA pour la première fois
- Si vous utilisez Google Endpoint Management, il n’est pas possible d’activer le paramètre Custom Push Configuration pour CalDAV et CardDAV
- À partir du 30 septembre 2024, les push basés sur un mot de passe pour IMAP, CalDAV, CardDAV, SMTP et POP ne fonctionnent plus pour les utilisateurs existants
- Les administrateurs doivent utiliser leur fournisseur MDM pour pousser un compte Google ; cette méthode ajoute de nouveau le compte Google sur les appareils iOS avec OAuth
- Les push Exchange ActiveSync (Google Sync) basés sur un mot de passe ne fonctionnent plus non plus pour les utilisateurs existants
- Les paramètres “Custom push configuration-CalDAV” et “Customer push configuration-CardDAV” de Google Endpoint Management n’ont plus d’effet
Méthodes de migration selon les appareils, applications et développeurs
- Si un scanner ou un autre appareil envoie des e-mails via SMTP ou LSA, l’une des options suivantes est nécessaire
- Configurer l’utilisation d’OAuth
- Utiliser une méthode alternative
- Configurer un mot de passe d’application pour cet appareil
- Les applications qui accèdent à un compte Google uniquement avec un nom d’utilisateur et un mot de passe nécessitent une action de migration
- Si aucune action n’est effectuée avant la date d’arrêt, une erreur indiquant que la combinaison nom d’utilisateur/mot de passe est incorrecte s’affichera et la connexion sera impossible
- Actions selon les applications de messagerie
- Outlook 2016 ou les versions antérieures doivent migrer vers Microsoft 365, Outlook for Windows ou Outlook for Mac, qui prennent en charge l’accès OAuth
- Il est également possible d’utiliser Google Workspace Sync for Microsoft Outlook
- Thunderbird ou d’autres clients de messagerie doivent réajouter le compte Google et configurer IMAP avec OAuth
- Dans l’app Mail d’iOS ou de macOS, ou dans Outlook for Mac, si la connexion se fait uniquement avec un mot de passe, il faut supprimer le compte, le rajouter, puis sélectionner “Sign in with Google”
- Les applications de calendrier et de contacts doivent aussi migrer vers une méthode compatible OAuth
- Les applications de calendrier CalDAV basées sur un mot de passe doivent être remplacées par une méthode compatible OAuth ; Google recommande l’app Google Calendar
- Dans l’app Calendrier d’iOS ou de macOS, si la connexion se fait uniquement avec un mot de passe, il faut supprimer le compte, le rajouter, puis sélectionner “Sign in with Google”
- Sur iOS ou macOS, si les contacts sont synchronisés via CardDAV et que la connexion se fait uniquement avec un mot de passe, il faut supprimer le compte, le rajouter, puis sélectionner “Sign in with Google”
- Sur d’autres plateformes ou applications utilisant uniquement CardDAV et un mot de passe, il faut passer à une méthode compatible OAuth
- Les applications qui ne prennent pas en charge OAuth doivent être remplacées par des applications le prenant en charge, ou utiliser un mot de passe d’application pour l’accès
- Les développeurs doivent mettre à jour le mode de connexion de leurs applications vers OAuth 2.0 afin de maintenir la compatibilité avec les comptes Google Workspace
Comptes Google personnels et périmètre d’application
- Pour les utilisateurs de comptes Google personnels, le bouton d’activation/désactivation d’IMAP sera supprimé des paramètres Gmail
- L’accès IMAP des comptes personnels est toujours activé via OAuth, et les connexions actuelles ne sont pas affectées
- Les utilisateurs de comptes Google personnels n’ont aucune action particulière à effectuer
- Ce changement s’applique à tous les clients Google Workspace
1 commentaires
Avis sur Hacker News
En lisant cet article, j’ai eu un moment de panique — parce que j’ai plusieurs scripts et outils intégrés à Gmail.
Mais ça semble aller. Les mots de passe d’application ont l’air de continuer à fonctionner, et ce changement ressemble plutôt à la suppression de la prise en charge des Less Secure Apps qui utilisent le nom d’utilisateur/mot de passe général du compte.
Rien qu’en imaginant le nombre d’automatisations qui mourraient si Google supprimait vraiment tout ce qui n’est pas OAuth, j’en ai des sueurs froides.
Je déteste la complexité d’OAuth, et j’ai aimé la manière dont la documentation de ce module Perl en démêle la structure. Elle a manifestement été écrite par quelqu’un d’aussi agacé que moi : https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
J’ai eu un problème similaire, et dans un Workspace les mots de passe d’application étaient bloqués. Il suffit d’obtenir un token OAuth avec un petit script Python et de l’utiliser comme un mot de passe : https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Voir l’exemple ici : https://github.com/lefcha/imapfilter/issues/186
Pour l’instant, je dois garder activé le commutateur LSA afin que mon compte Gmail principal puisse envoyer des messages SMTP avec les identifiants de plusieurs autres comptes Gmail. Je ne comprends pas pourquoi Gmail apparaît comme une LSA aux yeux d’un autre compte Gmail.
Ils font 16 lettres minuscules, séparées par des espaces tous les 4 caractères, sans chiffres ni caractères spéciaux.
Keepass les évalue comme des mots de passe faibles à 65 bits d’entropie une fois les espaces retirés.
Je ne vois pas en quoi c’est une amélioration.
Si vous ne pouvez pas passer à OAuth, mon proxy permet d’utiliser des clients IMAP/POP/SMTP qui ne prennent pas directement en charge OAuth 2.0 avec des fournisseurs d’e-mail « modernes » : https://github.com/simonrob/email-oauth2-proxy
Le client n’a pas du tout besoin de connaître OAuth.
Si vous ne pouvez pas passer à OAuth, créez un mot de passe d’application et continuez à l’utiliser comme mot de passe IMAP comme d’habitude.
Parce qu’IMAP, SMTP et POP donnent un accès important à un compte Google et, plus largement, à une grande partie de la vie de quelqu’un, sans aucun moyen d’effectuer une validation en deux étapes ni de proposer une vérification anti-robot.
Les attaques par bourrage d’identifiants deviennent donc très faciles, et à l’échelle de Google, elles peuvent ruiner la vie de beaucoup de gens.
C’est un bon changement, qui aurait dû être fait il y a des années. En fait, cela a déjà été fait dans une certaine mesure, par exemple en désactivant par défaut l’accès IMAP/POP/SMTP, et la plupart des utilisateurs sont protégés par cela. Ici, il s’agit de s’occuper des utilisateurs restants.
Dans Dovecot, il suffit de choisir le module d’authentification préféré et de le modifier pour lire le mot de passe saisi sous la forme
pwd+otp code. Si l’utilisateur a activé la validation en deux étapes, on lit les 6 derniers caractères et on les compare au TOTP.Si ça correspond, on autorise cette IP pendant x minutes, ou on applique la politique souhaitée.
Ça fonctionne étonnamment bien.
Cette adresse ne serait pas chez Gmail et devrait être chez un fournisseur qui continue d’autoriser IMAP/POP. Ce n’est pas une panacée, mais ça peut être un contournement acceptable pour certains cas d’usage.
Il s’agit d’une manœuvre pour détourner les utilisateurs d’excellentes apps mail natives et les pousser vers les propres apps de Google.
Sans gmail.app ou Google Sync, qui sera bientôt abandonné, on ne peut pas recevoir de notifications mail en temps réel. Je déteste ça. Même en payant pour Workspace, je déteste ça. Sur desktop, Mimestream fonctionne encore, mais j’ai l’impression qu’ils vont bientôt le viser aussi.
JMAP est un bon protocole standard, mais son adoption est absurdement faible à cause du problème de la poule et de l’œuf entre fournisseurs de mail et apps mail. Si Gmail prenait JMAP en charge, cela pourrait inciter des implémenteurs un peu partout à le supporter. JMAP prend aussi en charge les notifications et d’autres fonctionnalités.
OAuth pour l’e-mail fait partie de plusieurs RFC liées à l’authentification e-mail et existe depuis des années.
Thunderbird et plusieurs apps mobiles prennent bien en charge Gmail via OAuth. Le plus gros problème, c’est que beaucoup d’apps desktop semblent avoir arrêté d’implémenter les évolutions d’IMAP et SMTP depuis environ dix ans.
Si une app e-mail n’est plus maintenue, il suffit d’utiliser les mots de passe spécifiques aux applications, comme Google l’indique dans l’article lié. Ils continueront de fonctionner. Ce qui disparaît, c’est la méthode avec nom d’utilisateur/mot de passe du compte principal codés en dur.
Pour les utilisateurs d’Office 2016, ce sera un gros casse-tête, car le 30 septembre arrive encore environ neuf mois avant la fin du support d’Outlook. Mais pour la plupart des utilisateurs, la correction devrait être assez simple.
L’e-mail est asynchrone, donc être informé 10 minutes après l’arrivée d’un message devrait aller. Si j’attends un mail, je vais de toute façon marteler le bouton d’actualisation jusqu’à ce qu’il arrive.
Si c’est plus urgent, envoyez un SMS. Évitez de m’appeler. Je déteste le téléphone.
Il y a cette explication : « Les mots de passe d’application sont des codes à 16 chiffres qui permettent à une application ou à un appareil moins sécurisé d’accéder à votre compte Google, et ne peuvent être utilisés que sur les comptes avec la validation en deux étapes activée » : https://support.google.com/mail/answer/185833
N’est-ce pas amusant que des « applications ou appareils moins sécurisés » deviennent quasiment équivalents, en matière de sécurité, à des apps compatibles OAuth dès lors qu’ils utilisent simplement des mécanismes côté serveur que Google aurait pu encourager depuis longtemps ? Techniquement, cela ne semble même pas relever d’une fonctionnalité de l’app.
Bien sûr, on pourrait dire que la simplification se justifie, parce que parler « d’apps avec un workflow sécurisé mais moins pratique » serait moins parlant. Le problème plus large, c’est que Google a tendance à interpréter les préoccupations de sécurité d’une manière qui sert toujours son propre agenda, et ce fragment ne fait pas exception.
Ils ne font maintenant que les rendre obligatoires pour les apps qui ne peuvent pas être mises à jour afin de prendre en charge OAuth.
Les mots de passe d’application reviennent fonctionnellement à tout autoriser ou tout bloquer, alors qu’avec OAuth on peut configurer des droits comme la lecture, la modification ou le changement de paramètres.
Ce qu’il y a de plus agaçant avec Google OAuth2 sur Android, c’est que pour se connecter avec un compte Google dans un client e-mail ou un calendrier, tout le téléphone doit être associé à ce compte Google.
Et ce compte Google obtient aussi des droits de politique de l’appareil. À mon avis, cela n’a absolument aucun sens.
Utiliser OAuth2 dans une WebView interne à l’app est aussi facile à restreindre pour Google sur Android, donc c’est difficile à contourner.
Malheureusement, il n’y a pas beaucoup de clients e-mail dignes de confiance. Beaucoup envoient les identifiants à un serveur distant.
Modification : k9 prend déjà en charge OAuth pour IMAP.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
La formulation est un peu ambiguë, mais il semble que les mots de passe spécifiques aux applications continueront de fonctionner.
La citation dit que les scanners et appareils qui envoient des e-mails via SMTP ou LSA doivent être configurés pour utiliser OAuth, employer une autre méthode, ou définir un mot de passe d’application pour l’appareil.
Elle dit aussi que les apps qui ne prennent pas en charge OAuth doivent être remplacées par des apps qui le proposent, ou qu’il faut créer un mot de passe d’application pour y accéder.
J’ai donc demandé directement hier au support Google Workspace, et la réponse a été : « Les mots de passe d’application prennent en charge IMAP, POP et toutes les configurations SMTP ».
La deuxième phrase continuait à pousser l’adoption d’OAuth. J’aimerais bien le faire aussi, mais le coût des audits de sécurité récurrents est ingérable pour une petite app SaaS comme la nôtre ; heureusement, nous allons donc continuer à utiliser les mots de passe d’application.
Cela concerne les comptes Workspace ; pour les comptes Gmail grand public, ce changement a déjà été appliqué il y a quelques années
J’accède encore à mon compte Gmail personnel dans Mail.app sur iPhone via l’option Microsoft Exchange, et je reçois ainsi des notifications push sans être limité par le mode Fetch
Si cela fonctionne, c’est parce qu’une connexion Google Sync créée avec mon compte personnel avant la date d’arrêt, il y a environ 10 ans, est toujours maintenue et reconnue comme un « droit acquis »
Donc, pour que ça fonctionne, il suffit de modifier le GUID Exchange de l’iPhone pour le remplacer par le GUID du téléphone qui s’était connecté à Google Sync avant l’arrêt des nouvelles connexions
Heureusement, il est possible de changer ce GUID en créant une sauvegarde de l’iPhone, en modifiant le fichier plist dans la sauvegarde, puis en la restaurant
Aujourd’hui encore, j’utilise Mail.app et les notifications push pour mon compte Gmail personnel sur un iPhone 14 Pro
D’après l’annonce, je comprends que les mots de passe d’application seront maintenus pour le moment. Mais si Google finit un jour par les supprimer aussi, l’usage de clients tiers avec Gmail sera fortement limité, car les clients OAuth devront passer à leurs frais une évaluation de sécurité
L’e-mail reste l’un des derniers « protocoles de messagerie ouverts » largement utilisés, avec la possibilité de choisir son client ; ce serait une évolution regrettable
Dans mon entreprise, je m’occupe de la transition vers OAuth chez Microsoft, et ça a été assez pénible
Une partie du problème vient du fait que tout est très opaque. Quand on envoie un token, le serveur répond simplement « non », sans explication supplémentaire
J’ai passé des jours à essayer de comprendre pourquoi le flux Client Credentials ne fonctionnait pas, pour finalement trouver, enfouie dans un forum d’aide, la réponse : « ah, le client credentials flow n’est pas encore pris en charge ». Aujourd’hui, il est pris en charge pour IMAP/POP, mais de mémoire pas encore pour SMTP. Cela dit, OAuth n’est pas encore obligatoire pour SMTP
Ensuite, il a fallu déterminer le bon scope ; à l’époque, ce n’était pas très bien documenté. Les messages d’erreur du serveur n’aidaient absolument pas
Les serveurs mail de Google sont-ils meilleurs ?
Malheureusement, le serveur ne peut pas se permettre de fournir des informations « utiles » à des clients non authentifiés