Google stellt Google Sync und Unterstützung für reine Passwort-Apps ein
(workspaceupdates.googleblog.com)- Google Workspace beendet die Less Secure Apps (LSA)-Methode, bei der man sich nur mit Nutzername und Passwort anmeldet, und verlangt für die Synchronisierung von E-Mails, Kalendern und Kontakten eine OAuth-basierte Anmeldung
- Der Abschaltplan begann in zwei Phasen am 15. Juni 2024 und 30. September 2024, aber nach einer vorübergehenden Pause und der Wiederaufnahme des Rollouts wird LSA ab dem 1. Mai 2025 nicht mehr unterstützt
- Betroffen sind CalDAV-, CardDAV-, IMAP-, SMTP- und POP-Verbindungen, die nur ein Passwort verwenden, sowie Google Sync; sowohl neue als auch bestehende Google-Sync-Nutzer müssen umsteigen
- Administratoren sollten betroffenen Nutzern Anleitungen für den Umstieg auf OAuth bereitstellen; auch passwortbasierte Profile, die per MDM verteilt wurden, müssen auf die Methode umgestellt werden, bei der das Google-Konto per OAuth erneut hinzugefügt wird
- Nutzer, die bis zum Abschalttermin nichts unternehmen, können sich wegen eines Fehlers bei der Kombination aus Nutzername und Passwort nicht anmelden; Entwickler müssen die Verbindungsweise ihrer Apps für die Workspace-Kompatibilität auf OAuth 2.0 aktualisieren
Ende der reinen Passwort-Anmeldung
- Google Workspace unterstützt keine Anmeldemethode mehr, bei der Drittanbieter-Apps oder -Geräte direkt den Google-Nutzernamen und das Passwort verlangen
- Diese Methode wird als Less Secure Apps (LSA) bezeichnet und erhöht das Risiko eines unbefugten Kontozugriffs, da Google-Konto-Zugangsdaten mit Drittanbieter-Apps und -Geräten geteilt werden müssen
- Die Alternative ist Sign in with Google; dabei wird OAuth verwendet, ein branchenüblicher Authentifizierungsstandard, den die meisten Drittanbieter-Apps und -Geräte bereits nutzen
- Google hat diese Änderung 2019 angekündigt und später den Zeitplan für die Einführung erneut veröffentlicht
Zeitplan für die Abschaltung und Historie der Verschiebungen
- Die Abschaltung des LSA-Zugriffs war ursprünglich in zwei Phasen gegliedert
- Ab dem 15. Juni 2024 wurde die LSA-Einstellung in der Admin Console entfernt und kann nicht mehr geändert werden
- Bereits aktivierte Nutzer können weiterhin Verbindungen herstellen, aber deaktivierte Nutzer haben keinen Zugriff auf LSA
- Dazu gehören Drittanbieter-Apps auf Basis von CalDAV, CardDAV, IMAP, SMTP und POP, die mit nur einem Passwort auf Gmail, Google Calendar und Contacts zugreifen
- Auch die Einstellung zum Aktivieren/Deaktivieren von IMAP in den Gmail-Einstellungen des Nutzers wurde entfernt
- Nutzer, die LSA bereits vor diesem Datum verwendeten, konnten es ursprünglich noch bis zum 30. September 2024 weiter nutzen
- Ab dem 30. September 2024 war geplant, den LSA-Zugriff für alle Google-Workspace-Konten zu deaktivieren
- CalDAV, CardDAV, IMAP, POP und Google Sync funktionieren bei einer Anmeldung nur mit Passwort dann nicht mehr
- Um sie weiter zu nutzen, ist eine Anmeldung über OAuth erforderlich, also über die sicherere Zugriffsmethode
- Danach wurde der Zeitplan mehrfach angepasst
- Im Update vom 15. Oktober 2024 wurde der Rollout bis Jahresende pausiert und die Wiederaufnahme auf Januar 2025 verschoben
- Im Update vom 27. Januar 2025 wurde der Rollout wieder aufgenommen, die endgültige Deaktivierung war nun für März 2025 geplant
- Im Update vom 12. Februar 2025 wurde das Ende des LSA-Supports auf den 14. März 2025 geändert
- Im Update vom 29. April 2025 wurde mitgeteilt, dass LSA ab dem 1. Mai 2025 nicht mehr unterstützt wird
Prüfpunkte für Organisationen, die Google Sync nutzen
- Diese Änderung umfasst auch das Ende von Google Sync
- Der ursprüngliche Zeitplan für die Abschaltung von Google Sync war wie folgt
- Ab dem 15. Juni 2024 können neue Nutzer keine Verbindung mehr zu Google Workspace über Google Sync herstellen
- Ab dem 30. September 2024 können auch bestehende Google-Sync-Nutzer keine Verbindung mehr zu Google Workspace herstellen
- Ob Google Sync in der Organisation verwendet wird, lässt sich in der Admin Console prüfen
- Pfad: Devices > Mobile & Endpoints > Devices
- Filter: Type: Google Sync
Auswirkungen auf Administratoren und MDM-Konfigurationen
- Administratoren sollten Endnutzer anweisen, auf eine OAuth-basierte Zugriffsmethode umzusteigen, damit sie Apps weiterhin mit ihrem Google-Workspace-Konto nutzen können
- Informationen zu betroffenen Nutzern sollen in den kommenden Monaten per E-Mail an die Organisationen übermittelt werden
- Betroffen sind auch Organisationen, die mit einem MDM-Anbieter Profile für IMAP, CalDAV, CardDAV, POP und Exchange ActiveSync (Google Sync) konfiguriert haben
- Seit dem 15. Juni 2024 funktioniert der MDM-Push für passwortbasierte IMAP-, CalDAV-, CardDAV-, SMTP-, POP- und Exchange ActiveSync (Google Sync)-Profile nicht mehr für Kunden, die erstmals eine Verbindung über LSA herstellen wollen
- Bei Nutzung von Google Endpoint Management kann die Einstellung Custom Push Configuration für CalDAV und CardDAV nicht aktiviert werden
- Seit dem 30. September 2024 funktioniert der passwortbasierte Push für IMAP, CalDAV, CardDAV, SMTP und POP bei bestehenden Nutzern nicht mehr
- Administratoren müssen über ihren MDM-Anbieter ein Google-Konto pushen; bei dieser Methode wird das Google-Konto auf iOS-Geräten per OAuth erneut hinzugefügt
- Auch der passwortbasierte Push für Exchange ActiveSync (Google Sync) funktioniert für bestehende Nutzer nicht mehr
- Die Einstellungen „Custom push configuration-CalDAV“ und „Customer push configuration-CardDAV“ in Google Endpoint Management verlieren ihre Wirkung
Migrationswege je nach Gerät, App und Entwickler
- Wenn ein Scanner oder ein anderes Gerät E-Mails über SMTP oder LSA sendet, ist eine der folgenden Maßnahmen erforderlich
- Nutzung von OAuth konfigurieren
- Eine alternative Methode verwenden
- Ein App-Passwort für dieses Gerät einrichten
- Apps, die nur mit Nutzername und Passwort auf ein Google-Konto zugreifen, müssen umgestellt werden
- Wer bis zum Abschalttermin nichts unternimmt, erhält einen Fehler, dass die Kombination aus Nutzername und Passwort nicht korrekt sei, und kann sich nicht anmelden
- Maßnahmen je nach E-Mail-App
- Outlook 2016 oder älter muss auf Microsoft 365, Outlook for Windows oder Outlook for Mac umgestellt werden; diese unterstützen den Zugriff per OAuth
- Alternativ kann Google Workspace Sync for Microsoft Outlook verwendet werden
- Bei Thunderbird oder anderen E-Mail-Clients muss das Google-Konto erneut hinzugefügt und IMAP mit OAuth eingerichtet werden
- Wer sich in der Mail-App von iOS oder macOS oder in Outlook for Mac nur mit Passwort anmeldet, muss das Konto entfernen, erneut hinzufügen und „Sign in with Google“ auswählen
- Auch Kalender- und Kontakte-Apps müssen auf eine OAuth-fähige Methode umgestellt werden
- Passwortbasierte CalDAV-Kalender-Apps müssen auf eine OAuth-fähige Methode wechseln; Google empfiehlt die Google-Calendar-App
- Wer sich in der Kalender-App von iOS oder macOS nur mit Passwort anmeldet, muss das Konto entfernen, erneut hinzufügen und „Sign in with Google“ auswählen
- Wer auf iOS oder macOS Kontakte per CardDAV synchronisiert und sich nur mit Passwort anmeldet, muss das Konto entfernen, erneut hinzufügen und „Sign in with Google“ auswählen
- Wer auf anderen Plattformen oder in anderen Apps CardDAV nur mit Passwort verwendet, muss auf eine OAuth-fähige Methode umsteigen
- Apps ohne OAuth-Unterstützung müssen entweder durch Apps ersetzt werden, die OAuth anbieten, oder der Zugriff muss über ein App-Passwort erfolgen
- Entwickler müssen die Verbindungsweise ihrer Apps auf OAuth 2.0 aktualisieren, um die Kompatibilität mit Google-Workspace-Konten zu erhalten
- Google stellt einen Leitfaden für Entwickler zum Zugriff auf Google APIs mit OAuth 2.0 sowie einen OAuth-2.0-Leitfaden für mobile und Desktop-Apps bereit
Private Google-Konten und Geltungsbereich
- Bei Nutzern privater Google-Konten wird der Schalter zum Aktivieren/Deaktivieren von IMAP in den Gmail-Einstellungen entfernt
- Der IMAP-Zugriff für private Konten ist über OAuth immer aktiviert, bestehende Verbindungen sind davon nicht betroffen
- Nutzer privater Google-Konten müssen nichts unternehmen
- Diese Änderung gilt für alle Google-Workspace-Kunden
1 Kommentare
Meinungen auf Hacker News
Beim Lesen dieses Beitrags ist mir kurz das Herz in die Hose gerutscht — weil ich mehrere Skripte und Tools habe, die mit Gmail integriert sind.
Scheint aber in Ordnung zu sein. App-Passwörter funktionieren offenbar weiter, und diese Änderung ist eher die Abschaffung der Unterstützung für Less Secure Apps, die den normalen Nutzernamen/das normale Passwort des Kontos verwenden.
Mir wird schwindelig, wenn ich nur daran denke, wie viel Automatisierung kaputtgehen würde, wenn Google wirklich alles außer OAuth abschafft.
Ich mag die Komplexität von OAuth nicht, und mir gefiel, wie die Dokumentation dieses Perl-Moduls die Struktur erklärt. Sie wurde ganz offensichtlich von jemandem geschrieben, der genauso genervt ist wie ich: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
Ich hatte ein ähnliches Problem, und in einem Workspace waren App-Passwörter gesperrt. Mit einem kleinen Python-Skript kann man sich ein OAuth-Token holen und es wie ein Passwort verwenden: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Ein Beispiel gibt es unter https://github.com/lefcha/imapfilter/issues/186
Derzeit muss ich den LSA-Schalter für mein Haupt-Gmail-Konto weiterhin aktiviert lassen, damit es mit den Zugangsdaten mehrerer anderer Gmail-Konten per SMTP senden kann. Ich verstehe nicht, warum Gmail aus Sicht anderer Gmail-Konten eine LSA ist.
Es sind 16 Kleinbuchstaben, in Vierergruppen durch Leerzeichen getrennt, ohne Zahlen und ohne Sonderzeichen.
Keepass bewertet es nach Entfernen der Leerzeichen als schwaches Passwort mit 65 Bit Entropie.
Ich weiß nicht, inwiefern das eine Verbesserung sein soll.
Wenn man nicht auf OAuth umstellen kann, lassen sich mit meinem Proxy auch IMAP/POP/SMTP-Clients, die OAuth 2.0 nicht direkt unterstützen, mit „modernen“ E-Mail-Anbietern verwenden: https://github.com/simonrob/email-oauth2-proxy
Der Client muss überhaupt nichts von OAuth wissen.
Wenn man nicht auf OAuth umstellen kann, kann man ein App-Passwort erstellen und es wie gewohnt weiter als IMAP-Passwort verwenden.
Weil IMAP, SMTP und POP einem Google-Konto und damit einem großen Teil des digitalen Lebens erhebliche Zugriffsrechte geben, es aber keine Möglichkeit für Zwei-Faktor-Authentifizierung gibt und auch keine Bot-Schutzprüfung angeboten wird.
Dadurch werden Credential-Stuffing-Angriffe sehr einfach, und in Googles Größenordnung können solche Angriffe das Leben vieler Menschen ruinieren.
Das ist eine gute Änderung und hätte schon vor Jahren passieren sollen. Eigentlich wurde das in gewissem Umfang bereits getan, indem der IMAP/POP/SMTP-Zugriff standardmäßig deaktiviert wurde; die meisten Nutzer sind dadurch geschützt. Diese Maßnahme ist für die übrigen Nutzer gedacht.
In Dovecot wählt man das bevorzugte Authentifizierungsmodul und ändert es so, dass das eingegebene Passwort als
pwd+otp codegelesen wird. Wenn der Nutzer Zwei-Faktor-Authentifizierung aktiviert hat, liest man die letzten 6 Zeichen und vergleicht sie mit dem TOTP.Wenn es übereinstimmt, erlaubt man diese IP für x Minuten oder wendet die gewünschte Richtlinie an.
Funktioniert überraschend gut.
Diese Adresse dürfte dann kein Gmail sein und müsste IMAP/POP weiterhin erlauben. Kein Allheilmittel, aber für manche Anwendungsfälle vielleicht ein akzeptabler Workaround.
Das ist ein Versuch, Nutzer aus hervorragenden nativen Mail-Apps herauszuziehen und in Googles eigene Apps zu treiben.
Ohne gmail.app oder das bald eingestellte Google Sync bekommt man Echtzeit-Mail-Benachrichtigungen nicht. Das gefällt mir nicht. Auch wenn ich für Workspace bezahle, gefällt es mir nicht. Auf dem Desktop funktioniert Mimestream noch, aber ich vermute, dass sie das auch bald ins Visier nehmen werden.
JMAP ist ein guter Standardprotokoll, aber wegen des Henne-Ei-Problems zwischen Mail-Anbietern und Mail-Apps ist die Verbreitung absurd gering. Wenn Gmail JMAP unterstützt, könnte das Implementierer überall dazu bewegen, es ebenfalls zu unterstützen. JMAP unterstützt auch Benachrichtigungen und weitere Funktionen.
OAuth für E-Mail ist in mehreren RFCs zur E-Mail-Authentifizierung enthalten und existiert seit Jahren.
Thunderbird und mehrere Mobile-Apps unterstützen Gmail problemlos über OAuth. Das größere Problem ist, dass viele Desktop-Apps anscheinend vor etwa zehn Jahren aufgehört haben, Änderungen an IMAP und SMTP umzusetzen.
Wenn es eine nicht mehr gepflegte E-Mail-App ist, kann man, wie Google im verlinkten Beitrag erklärt, App-spezifische Passwörter verwenden. Die funktionieren weiterhin. Was verschwindet, ist die hartcodierte Benutzername/Passwort-Methode für das Hauptkonto.
Für Nutzer von Office 2016 dürfte das ein großes Ärgernis sein, denn der 30. September liegt noch etwa neun Monate vor dem Support-Ende von Outlook. Für die meisten Nutzer dürfte es aber eine recht einfache Korrektur sein.
E-Mail ist asynchron, also sollte es kein Problem sein, wenn man 10 Minuten nach Eingang von einer Nachricht erfährt. Wenn es eine Mail ist, auf die ich warte, werde ich ohnehin bis zur Ankunft ständig auf Aktualisieren drücken.
Wenn es dringender ist, soll man eine SMS schicken. Bitte nicht anrufen. Ich hasse Telefonate.
Es gibt die Erklärung: „Ein App-Passwort ist ein 16-stelliger Code, der einer weniger sicheren App oder einem weniger sicheren Gerät Zugriff auf Ihr Google-Konto gewährt, und kann nur für Konten mit aktivierter Bestätigung in zwei Schritten verwendet werden“: https://support.google.com/mail/answer/185833
Ist es nicht komisch, dass „weniger sichere Apps oder Geräte“ in puncto Sicherheit fast gleichwertig mit OAuth-Apps werden, wenn sie nur einen serverseitigen Mechanismus verwenden, den Google schon lange hätte fördern können? Technisch wirkt es nicht einmal wie eine Funktion der App.
Natürlich könnte man sagen, dass die Vereinfachung gerechtfertigt ist, weil „Apps mit sicherem Workflow, aber weniger Komfort“ weniger gut kommunizierbar wäre. Das größere Problem ist, dass Google dazu neigt, Sicherheitsbedenken immer so auszulegen, wie es der eigenen Agenda nützt, und dieses Stück ist da keine Ausnahme.
Jetzt macht es das lediglich für Apps verpflichtend, die nicht aktualisiert werden können, um OAuth zu unterstützen.
App-Passwörter sind funktional eher Alles-oder-nichts, während man bei OAuth Berechtigungen wie Lesen, Ändern oder Einstellungsänderungen konfigurieren kann.
Das Nervigste an Google OAuth2 unter Android ist, dass das gesamte Smartphone mit diesem Google-Konto verknüpft sein muss, wenn man sich in einem E-Mail-Client oder Kalender mit einem Google-Konto anmelden will.
Außerdem erhält dieses Google-Konto dann sogar Geräte-Policy-Berechtigungen. Meiner Meinung nach ist das völlig absurd.
OAuth2 in einem app-internen WebView zu verwenden, kann Google unter Android ebenfalls leicht einschränken, daher ist es schwer zu umgehen.
Leider gibt es nicht viele vertrauenswürdige E-Mail-Clients. Viele schicken Zugangsdaten an entfernte Server.
Korrektur: k9 unterstützt bereits OAuth für IMAP.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
Die Formulierung ist etwas mehrdeutig, aber App-spezifische Passwörter scheinen weiterhin zu funktionieren.
In dem Zitat heißt es, Scanner und Geräte, die E-Mails per SMTP oder LSA senden, müssten so eingerichtet werden, dass sie OAuth verwenden, eine alternative Methode nutzen oder ein App-Passwort für das Gerät einrichten.
Außerdem heißt es, Apps ohne OAuth-Unterstützung solle man durch Apps ersetzen, die OAuth anbieten, oder ein App-Passwort erstellen, um Zugriff zu erhalten.
Deshalb habe ich gestern direkt bei Google Workspace Support nachgefragt, und die Antwort war: „Anwendungspasswörter unterstützen IMAP, POP und alle SMTP-Konfigurationen.“
Der zweite Satz drängte weiterhin auf die Einführung von OAuth. Das würde ich auch gern tun, aber die wiederkehrenden Kosten für Sicherheitsprüfungen sind für eine kleine SaaS-App wie unsere nicht tragbar, daher werden wir glücklicherweise weiterhin App-Passwörter verwenden.
Das betrifft Workspace-Konten; für normale Gmail-Konten wurde diese Änderung schon vor einigen Jahren umgesetzt.
Ich greife mit einem privaten Gmail-Konto auf dem iPhone in Mail.app noch immer über die Microsoft-Exchange-Option zu und bekomme auf diese Weise Push-Benachrichtigungen, ohne an Fetch gebunden zu sein.
Das funktioniert, weil die Verbindung zu Google Sync, die ich mit meinem privaten Konto vor dem Abschaltdatum vor etwa zehn Jahren eingerichtet hatte, weiterhin besteht und gewissermaßen als „Bestandsschutz“ anerkannt wird.
Damit es funktioniert, muss man also die Exchange-GUID des iPhones auf die GUID des Telefons ändern, mit dem man sich damals vor dem Stopp neuer Logins bei Google Sync angemeldet hatte.
Zum Glück lässt sich diese GUID ändern, indem man ein iPhone-Backup erstellt, die plist-Datei darin bearbeitet und das Backup anschließend wiederherstellt.
Ich nutze Mail.app und Push-Benachrichtigungen für mein privates Gmail-Konto auch jetzt noch auf einem iPhone 14 Pro.
Nach meinem Verständnis bleiben App-Passwörter laut Ankündigung vorerst erhalten. Wenn Google aber irgendwann auch App-Passwörter abschafft, dürfte die Nutzung von Drittanbieter-Clients mit GMail stark eingeschränkt werden, weil OAuth-Clients auf eigene Kosten eine Sicherheitsprüfung durchlaufen müssen.
E-Mail ist noch immer eines der letzten weithin genutzten „offenen Messaging-Protokolle“, bei dem man den Client wählen kann; eine solche Entwicklung wäre traurig.
In der Firma beschäftigen wir uns mit Microsofts Umstellung auf OAuth, und das war ziemlich mühsam.
Ein Teil des Problems ist, dass alles so undurchsichtig ist. Wenn man ein Token sendet, antwortet der Server ohne weitere Erklärung nur mit „nein“.
Ich habe Tage damit verbracht herauszufinden, warum der Client-Credentials-Flow nicht funktioniert, und fand schließlich tief in einem Hilfeforum die Antwort: „Ach ja, der Client-Credentials-Flow wird noch nicht unterstützt.“ Inzwischen wird er für IMAP/POP unterstützt, aber soweit ich mich erinnere noch nicht für SMTP. Allerdings ist OAuth für SMTP bislang auch noch nicht verpflichtend.
Als Nächstes ging es darum, den richtigen Scope herauszufinden; damals war das nicht besonders gut dokumentiert. Auch die Fehlermeldungen des Servers waren überhaupt nicht hilfreich.
Sind die Mailserver von Google da besser?
Leider kann es sich ein Server nicht leisten, nicht authentifizierten Clients „hilfreiche“ Informationen zu geben.