Mises à jour Google Workspace
- À partir du 30 septembre 2024 : les applications tierces qui utilisent uniquement un mot de passe pour accéder à un compte Google et à Google Sync ne seront plus prises en charge.
- Changement : Google Workspace ne prendra plus en charge les méthodes de connexion des applications ou appareils tiers qui exigent le partage du nom d’utilisateur Google et du mot de passe de l’utilisateur.
- Risque de sécurité : l’ancienne méthode, Less Secure Apps (LSA), augmente les risques de sécurité car elle impose de partager les identifiants du compte Google avec des applications et appareils tiers.
- Méthode plus sûre : il faut utiliser l’option de connexion avec Google, qui s’appuie sur l’authentification OAuth pour synchroniser les e-mails avec d’autres applications de manière plus sûre et plus sécurisée.
Calendrier d’arrêt de l’accès LSA
- À partir du 15 juin 2024 : le paramètre LSA sera supprimé de la console d’administration et ne pourra plus être modifié. Les utilisateurs déjà activés pourront encore se connecter, mais les utilisateurs désactivés ne pourront plus accéder à LSA.
- À partir du 30 septembre 2024 : l’accès LSA sera interrompu pour tous les comptes Google Workspace. CalDAV, CardDAV, IMAP, POP et Google Sync ne fonctionneront plus avec une connexion par mot de passe seul et devront utiliser OAuth.
Fin du service Google Sync
- À partir du 15 juin 2024 : les nouveaux utilisateurs ne pourront plus se connecter à Google Workspace via Google Sync.
- 30 septembre 2024 : les utilisateurs existants de Google Sync ne pourront plus se connecter à Google Workspace.
Consignes pour les administrateurs et les utilisateurs finaux
- Administrateurs : vous devez faire migrer les utilisateurs finaux vers un type d’accès plus sûr, appelé OAuth, afin qu’ils puissent continuer à utiliser ce type d’applications avec leur compte Google Workspace.
- Impact sur la gestion des appareils mobiles (MDM) : pour les organisations qui utilisent un fournisseur MDM afin de configurer des profils IMAP, CalDAV, CardDAV, POP ou Exchange ActiveSync (Google Sync), le service sera progressivement supprimé.
- Scanners et autres appareils : les scanners ou autres appareils qui envoient des e-mails via SMTP ou LSA doivent être configurés pour utiliser OAuth, recourir à une méthode alternative ou configurer un mot de passe d’application à utiliser avec l’appareil.
Consignes pour les utilisateurs finaux
- Applications de messagerie : si vous utilisez une version antérieure à Outlook 2016, vous devez passer à Microsoft 365 ou basculer vers Outlook pour Windows ou Mac prenant en charge l’accès OAuth.
- Applications de calendrier : si vous utilisez une application reposant sur CalDAV avec authentification par mot de passe, vous devez passer à une méthode prenant en charge OAuth.
- Applications de contacts : si vous synchronisez vos contacts via CardDAV sur iOS ou macOS et que vous vous connectez uniquement avec un mot de passe, vous devez supprimer le compte puis l’ajouter de nouveau.
Consignes pour les développeurs
- Développeurs : pour conserver la compatibilité avec les comptes Google Workspace, vous devez mettre à jour vos applications afin d’utiliser OAuth 2.0 comme méthode de connexion.
Disponibilité
- Ce changement affecte tous les clients Google Workspace.
L’avis de GN⁺
- Cette mise à jour constitue une mesure importante pour renforcer la sécurité des utilisateurs de Google Workspace. Remplacer les applications moins sécurisées (LSA) qui reposent uniquement sur un mot de passe par OAuth est indispensable dans le contexte actuel de la cybersécurité.
- Elle affecte à la fois les administrateurs et les utilisateurs finaux, et en particulier les personnes qui utilisent des applications de messagerie, de calendrier et de contacts, qui devront migrer vers la nouvelle méthode d’authentification.
- Cet article fournit des informations utiles aux utilisateurs et administrateurs de Google Workspace afin de les aider à se préparer aux prochaines mises à jour de sécurité et à prendre les mesures nécessaires.
1 commentaires
Avis Hacker News
Un utilisateur a un script qui interagit avec Gmail et a été surpris par l’annonce de la fin du support des « Less Secure Apps », mais se rassure en constatant que les mots de passe d’application devraient continuer à fonctionner. Il craint qu’une situation où seul OAuth serait pris en charge ne casse beaucoup d’automatisations. Il se plaint de la complexité d’OAuth et juge positivement la documentation d’un module Perl qui expliquait clairement son fonctionnement.
Lorsqu’il n’est pas possible d’utiliser OAuth, un utilisateur peut employer son propre proxy afin de faire fonctionner des clients IMAP ou POP/SMTP avec des fournisseurs d’e-mail « modernes », même si ces clients ne prennent pas en charge OAuth 2.0. Le client n’a pas besoin de connaître OAuth.
IMAP, SMTP et POP permettent un accès important à un compte Google, mais ne peuvent pas appliquer l’authentification à deux facteurs ni la vérification anti-robot, ce qui les rend vulnérables aux attaques de credential stuffing. Google avait désactivé ce type d’accès par défaut pour protéger les utilisateurs contre ces attaques, et cette mesure est vue positivement comme visant les utilisateurs restants.
Il est souligné que ce changement semble viser à pousser les utilisateurs vers l’application mail de Google. Sans l’app Gmail ni Google Sync, promis à la disparition, il n’est pas possible de recevoir des notifications e-mail en temps réel. Un utilisateur exprime son mécontentement alors même qu’il paie pour Google Workspace. Sur desktop, Mimestream fonctionne encore, mais il craint que Google ne cherche à le bloquer.
Sur Android, l’aspect le plus agaçant d’Oauth2 et de Google est qu’il est impossible de se connecter à un client e-mail ou à un calendrier avec un compte Google sans lier tout le téléphone à ce compte Google. Cela accorde aussi à ce compte des autorisations de politique sur l’appareil. L’utilisateur note qu’on ne peut pas totalement ignorer cela et que Google peut facilement restreindre l’usage d’oauth2 dans WebView sur Android.
Les mots de passe d’application sont des mots de passe à 16 caractères qui ne peuvent être utilisés que sur des comptes où l’authentification à deux facteurs est activée. Il est souligné que les « applications moins sécurisées » offrent le même niveau de sécurité que les applications prenant en charge OAuth, mais en s’appuyant sur des mécanismes côté serveur que Google peut promouvoir depuis longtemps. Un avis critique est exprimé sur la façon dont Google interprète les questions de sécurité pour faire avancer son propre agenda.
Il est expliqué que les mots de passe spécifiques aux applications (App-Specific Passwords) devraient continuer à fonctionner et que, si l’on utilise une application ne prenant pas en charge OAuth, il faut soit passer à une application compatible OAuth, soit générer un mot de passe d’application pour y accéder.
Il est précisé que ce changement ne s’applique qu’aux comptes Workspace et qu’il avait déjà été appliqué aux comptes Gmail classiques il y a quelques années.
Il y a environ dix ans, quelqu’un a mis en place un système permettant de s’authentifier sur un réseau interne avec des comptes Google individuels via une intégration avec l’annuaire des comptes Google. Selon les standards actuels, c’est moins sécurisé, mais c’était perçu positivement car cela permettait de se connecter immédiatement au réseau interne sans passer par un VPN, ce qui faisait gagner du temps à tout le monde.
En gérant la transition OAuth de Microsoft, quelqu’un a rencontré des difficultés, le principal problème étant l’opacité du processus. On envoie un token et le serveur répond seulement « non », sans explication sur la raison de l’échec, ce qui fait perdre des jours à déboguer. La question est posée de savoir si les serveurs mail de Google font mieux.