Google menghentikan dukungan untuk Google Sync dan aplikasi khusus kata sandi
(workspaceupdates.googleblog.com)- Google Workspace menghentikan metode Less Secure Apps (LSA), yaitu login dengan hanya membagikan nama pengguna dan kata sandi, dan mewajibkan login berbasis OAuth untuk sinkronisasi email, kalender, dan kontak
- Jadwal penghentian dimulai dalam 2 tahap pada 15 Juni dan 30 September 2024, tetapi setelah rollout dijeda dan dilanjutkan kembali, LSA tidak lagi didukung mulai 1 Mei 2025
- Koneksi CalDAV, CardDAV, IMAP, SMTP, POP yang hanya memakai kata sandi serta Google Sync terdampak, dan baik pengguna baru maupun pengguna Google Sync yang sudah ada termasuk dalam target migrasi
- Admin harus membagikan panduan migrasi ke OAuth kepada pengguna terdampak, dan profil berbasis kata sandi yang didistribusikan melalui MDM juga harus diubah menjadi metode menambahkan ulang Google Account dengan OAuth
- Pengguna yang tidak mengambil tindakan hingga tanggal penghentian tidak akan bisa login karena error kombinasi nama pengguna-kata sandi, dan developer harus memperbarui metode koneksi aplikasi ke OAuth 2.0 demi kompatibilitas dengan Workspace
Penghentian metode login khusus kata sandi
- Google Workspace tidak lagi mendukung metode login ketika aplikasi atau perangkat pihak ketiga meminta langsung nama pengguna dan kata sandi Google
- Metode ini disebut Less Secure Apps (LSA), dan meningkatkan risiko akses tanpa izin ke akun karena kredensial Google Account harus dibagikan kepada aplikasi dan perangkat pihak ketiga
- Alternatifnya adalah Sign in with Google, yang menggunakan OAuth, metode autentikasi standar industri yang sudah dipakai oleh sebagian besar aplikasi dan perangkat pihak ketiga
- Google mengumumkan perubahan ini pada 2019, lalu kemudian kembali memublikasikan jadwal penerapannya
Jadwal penghentian dan riwayat penundaan
- Penghentian akses LSA awalnya terdiri dari dua tahap
- Mulai 15 Juni 2024, setelan LSA di Admin Console dihapus sehingga tidak bisa lagi diubah
- Pengguna yang sudah diaktifkan masih bisa terus terhubung, tetapi pengguna yang dinonaktifkan tidak bisa mengakses LSA
- Ini mencakup aplikasi pihak ketiga berbasis CalDAV, CardDAV, IMAP, SMTP, POP yang mengakses Gmail, Google Calendar, dan Contacts hanya dengan kata sandi
- Setelan untuk mengaktifkan/menonaktifkan IMAP di setelan Gmail pengguna juga dihapus
- Pengguna yang sudah memakai LSA sebelum tanggal ini semula masih bisa terus menggunakannya hingga 30 September 2024
- Mulai 30 September 2024, akses LSA dijadwalkan dimatikan untuk semua akun Google Workspace
- CalDAV, CardDAV, IMAP, POP, Google Sync tidak lagi berfungsi saat login hanya dengan kata sandi
- Untuk terus menggunakannya, pengguna harus login dengan metode akses yang lebih aman, yaitu OAuth
- Setelah itu jadwal disesuaikan beberapa kali
- Dalam pembaruan 15 Oktober 2024, rollout dijeda hingga akhir tahun, dan dijadwalkan dilanjutkan pada Januari 2025
- Dalam pembaruan 27 Januari 2025, rollout dilanjutkan, dan penonaktifan final direncanakan pada Maret 2025
- Dalam pembaruan 12 Februari 2025, tanggal penghentian dukungan LSA diubah menjadi 14 Maret 2025
- Dalam pembaruan 29 April 2025, LSA tidak lagi didukung mulai 1 Mei 2025
Poin pemeriksaan untuk organisasi yang menggunakan Google Sync
- Perubahan ini juga mencakup penghentian Google Sync
- Jadwal penghentian Google Sync semula adalah sebagai berikut
- Mulai 15 Juni 2024, pengguna baru tidak bisa terhubung ke Google Workspace melalui Google Sync
- Mulai 30 September 2024, pengguna Google Sync yang sudah ada juga tidak bisa terhubung ke Google Workspace
- Apakah organisasi memakai Google Sync dapat diperiksa di Admin Console
- Jalur: Devices > Mobile & Endpoints > Devices
- Filter: Type: Google Sync
Dampak terhadap admin dan konfigurasi MDM
- Admin harus mengarahkan pengguna akhir untuk beralih ke metode akses berbasis OAuth agar mereka dapat terus memakai aplikasi dengan akun Google Workspace
- Informasi pengguna yang terdampak akan diberikan kepada organisasi melalui email dalam beberapa bulan mendatang
- Organisasi yang mengonfigurasi profil IMAP, CalDAV, CardDAV, POP, Exchange ActiveSync (Google Sync) melalui penyedia MDM juga terdampak
- Mulai 15 Juni 2024, push MDM untuk IMAP, CalDAV, CardDAV, SMTP, POP, Exchange ActiveSync (Google Sync) berbasis kata sandi tidak berfungsi bagi pelanggan yang pertama kali mencoba terhubung ke LSA
- Jika menggunakan Google Endpoint Management, setelan Custom Push Configuration untuk CalDAV dan CardDAV tidak dapat diaktifkan
- Mulai 30 September 2024, push IMAP, CalDAV, CardDAV, SMTP, POP berbasis kata sandi untuk pengguna yang sudah ada tidak berfungsi
- Admin harus menggunakan penyedia MDM untuk melakukan push Google Account, dan metode ini menambahkan kembali akun Google ke perangkat iOS dengan OAuth
- Push Exchange ActiveSync (Google Sync) berbasis kata sandi juga tidak berfungsi untuk pengguna yang sudah ada
- Setelan “Custom push configuration-CalDAV” dan “Customer push configuration-CardDAV” di Google Endpoint Management tidak lagi berlaku
Cara migrasi berdasarkan perangkat, aplikasi, dan developer
- Jika scanner atau perangkat lain mengirim email melalui SMTP atau LSA, salah satu hal berikut diperlukan
- Mengonfigurasi penggunaan OAuth
- Menggunakan metode alternatif
- Mengonfigurasi app password untuk perangkat tersebut
- Aplikasi yang mengakses Google Account hanya dengan nama pengguna dan kata sandi memerlukan tindakan migrasi
- Jika tidak mengambil tindakan hingga tanggal penghentian, akan muncul error bahwa kombinasi nama pengguna-kata sandi tidak benar dan pengguna tidak bisa login
- Tindakan berdasarkan aplikasi email
- Outlook 2016 atau versi sebelumnya harus berpindah ke Microsoft 365, Outlook for Windows, atau Outlook for Mac, yang mendukung akses OAuth
- Sebagai alternatif, Google Workspace Sync for Microsoft Outlook dapat digunakan
- Thunderbird atau klien email lain harus menambahkan ulang akun Google dan mengonfigurasi IMAP dengan OAuth
- Jika sedang login hanya dengan kata sandi di aplikasi Mail iOS atau macOS, atau Outlook for Mac, hapus akun lalu tambahkan kembali dan pilih “Sign in with Google”
- Aplikasi kalender dan kontak juga harus beralih ke metode yang mendukung OAuth
- Aplikasi kalender CalDAV berbasis kata sandi harus diganti dengan metode yang mendukung OAuth, dan Google merekomendasikan aplikasi Google Calendar
- Jika sedang login hanya dengan kata sandi di aplikasi Kalender iOS atau macOS, hapus akun lalu tambahkan kembali dan pilih “Sign in with Google”
- Jika menyinkronkan kontak dengan CardDAV di iOS atau macOS dan sedang login hanya dengan kata sandi, hapus akun lalu tambahkan kembali dan pilih “Sign in with Google”
- Jika hanya memakai CardDAV dan kata sandi di platform atau aplikasi lain, harus beralih ke metode yang mendukung OAuth
- Aplikasi yang tidak mendukung OAuth harus diganti dengan aplikasi yang menyediakan OAuth, atau akses harus dilakukan dengan membuat app password
- Developer harus memperbarui metode koneksi aplikasi ke OAuth 2.0 agar tetap kompatibel dengan akun Google Workspace
Google Account pribadi dan cakupan penerapan
- Untuk pengguna Google Account pribadi, toggle untuk mengaktifkan/menonaktifkan IMAP di setelan Gmail akan dihapus
- Akses IMAP untuk akun pribadi selalu aktif melalui OAuth, dan koneksi saat ini tidak terdampak
- Pengguna Google Account pribadi tidak perlu mengambil tindakan tambahan
- Perubahan ini berlaku untuk semua pelanggan Google Workspace
1 komentar
Opini Hacker News
Saat membaca tulisan ini, saya sempat panik sesaat — karena ada beberapa skrip dan alat yang terhubung dengan Gmail
Tapi sepertinya tidak apa-apa. Sandi aplikasi tampaknya tetap berfungsi, dan perubahan kali ini lebih mendekati penghapusan dukungan Less Secure Apps yang memakai nama pengguna/sandi umum akun
Membayangkan berapa banyak otomasi yang akan mati kalau Google benar-benar menghapus semua selain OAuth saja sudah membuat ngeri
Saya tidak suka kompleksitas OAuth, dan saya suka cara dokumentasi modul Perl ini menguraikan strukturnya. Jelas tampak ditulis oleh orang yang sama kesalnya seperti saya: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
Saya pernah mengalami masalah serupa, dan di satu Workspace sandi aplikasi diblokir. Cukup ambil token OAuth dengan skrip Python kecil lalu gunakan itu seperti sandi: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Lihat contoh di https://github.com/lefcha/imapfilter/issues/186
Saat ini saya harus tetap menyalakan saklar LSA agar akun Gmail utama bisa mengirim lewat SMTP dengan kredensial beberapa akun Gmail lain. Saya tidak mengerti kenapa Gmail terlihat sebagai LSA di mata akun Gmail lain
Panjangnya 16 huruf kecil, dipisahkan spasi tiap 4 karakter, tanpa angka maupun karakter khusus
Keepass menilainya sebagai sandi lemah dengan entropi 65 bit setelah spasinya dihapus
Saya tidak tahu bagaimana ini bisa disebut peningkatan
Jika tidak bisa beralih ke OAuth, proxy saya memungkinkan klien IMAP/POP/SMTP yang tidak mendukung OAuth 2.0 secara langsung tetap digunakan dengan penyedia email “modern”: https://github.com/simonrob/email-oauth2-proxy
Klien sama sekali tidak perlu tahu tentang OAuth
Jika tidak bisa beralih ke OAuth, buat saja sandi aplikasi dan terus gunakan seperti biasa sebagai sandi IMAP
Karena IMAP, SMTP, dan POP memberikan akses yang cukup besar ke Akun Google dan kehidupan secara keseluruhan, tetapi tidak ada cara untuk melakukan autentikasi 2 langkah, dan juga tidak menyediakan verifikasi anti-robot
Akibatnya serangan credential stuffing menjadi sangat mudah, dan pada skala Google serangan seperti itu bisa menghancurkan hidup banyak orang
Ini perubahan yang baik dan seharusnya dilakukan beberapa tahun lalu. Sebenarnya, sampai batas tertentu ini sudah dilakukan dengan menonaktifkan akses IMAP/POP/SMTP secara default, dan sebagian besar pengguna terlindungi oleh itu. Langkah kali ini untuk pengguna yang tersisa
Di Dovecot, pilih modul autentikasi yang disukai lalu ubah agar membaca sandi input sebagai
pwd+otp code. Jika pengguna mengaktifkan autentikasi 2 langkah, baca 6 digit terakhir dan bandingkan dengan TOTPJika cocok, izinkan IP tersebut selama x menit atau terapkan kebijakan apa pun yang diinginkan
Ternyata bekerja cukup baik
Alamat itu bukan Gmail dan merupakan tempat yang masih mengizinkan IMAP/POP. Bukan obat mujarab, tetapi untuk sebagian kasus penggunaan bisa menjadi solusi memutar yang dapat diterima
Ini adalah upaya untuk menarik pengguna dari aplikasi mail native yang bagus dan menggiring mereka ke aplikasi Google sendiri.
Tanpa gmail.app atau Google Sync yang akan segera dihentikan, kita tidak bisa menerima notifikasi email real-time. Saya tidak suka. Bahkan meski saya membayar Workspace, tetap tidak suka. Di desktop, Mimestream masih berfungsi, tetapi rasanya itu juga akan segera menjadi target.
JMAP adalah protokol standar yang bagus, tetapi tingkat adopsinya sangat rendah karena masalah ayam-dan-telur antara penyedia email dan aplikasi email. Jika Gmail mendukung JMAP, itu bisa mendorong para implementer di mana-mana untuk ikut mendukungnya. JMAP juga mendukung notifikasi dan fitur lainnya.
OAuth untuk email sudah tercakup dalam beberapa RFC terkait autentikasi email dan sudah ada selama bertahun-tahun.
Thunderbird dan berbagai aplikasi mobile mendukung Gmail dengan baik memakai OAuth. Masalah yang lebih besar adalah banyak aplikasi desktop tampaknya berhenti mengimplementasikan perubahan IMAP dan SMTP sejak sekitar 10 tahun lalu.
Jika itu aplikasi email yang sudah tidak dipelihara lagi, gunakan kata sandi khusus aplikasi seperti yang dijelaskan Google di artikel tertaut. Itu akan tetap berfungsi. Yang hilang adalah metode username/password yang di-hardcode untuk akun utama.
Ini akan menjadi sakit kepala besar bagi pengguna Office 2016, karena 30 September masih sekitar 9 bulan sebelum dukungan Outlook berakhir. Namun bagi sebagian besar pengguna, sepertinya perbaikannya cukup mudah.
Email itu asinkron, jadi seharusnya tidak masalah kalau kita baru tahu 10 menit setelah pesan datang. Kalau memang sedang menunggu email, toh kita akan terus menekan refresh sampai email itu tiba.
Kalau lebih mendesak, kirim SMS saja. Tolong jangan telepon. Saya tidak suka telepon.
Ada penjelasan bahwa “kata sandi aplikasi adalah kode sandi 16 digit yang memberi aplikasi atau perangkat yang kurang aman akses ke Akun Google, dan hanya dapat digunakan pada akun yang mengaktifkan Verifikasi 2 Langkah”: https://support.google.com/mail/answer/185833
Bukankah lucu bahwa “aplikasi atau perangkat yang kurang aman” bisa menjadi hampir setara secara keamanan dengan aplikasi yang mendukung OAuth jika hanya memakai mekanisme sisi server yang sebenarnya sudah bisa lama didorong Google? Secara teknis, ini bahkan tidak terlihat seperti fitur aplikasinya.
Tentu saja, orang bisa mengatakan penyederhanaan itu bisa dibenarkan karena menyebutnya “aplikasi dengan workflow yang aman tetapi kurang nyaman” tidak akan sekomunikatif itu. Masalah yang lebih besar adalah Google cenderung selalu menafsirkan kekhawatiran keamanan dengan cara yang menguntungkan agendanya sendiri, dan potongan ini juga bukan pengecualian.
Sekarang mereka hanya mewajibkannya untuk aplikasi yang tidak bisa diperbarui agar mendukung OAuth.
Kata sandi aplikasi secara fungsional hampir seperti izinkan semua atau blokir semua, sedangkan di OAuth izin seperti membaca, mengubah, dan mengubah setelan bisa dikonfigurasi.
Hal paling menjengkelkan tentang Google OAuth2 di Android adalah, untuk login ke klien email atau kalender dengan akun Google, seluruh ponsel harus dikaitkan dengan akun Google itu.
Selain itu, akun Google tersebut juga mendapatkan izin kebijakan perangkat. Menurut saya ini benar-benar tidak masuk akal.
Menggunakan OAuth2 di WebView internal aplikasi pun mudah dibatasi Google di Android, jadi sulit juga untuk mengakalinya.
Sayangnya tidak banyak klien email yang bisa dipercaya. Banyak yang malah mengirim kredensial ke server jarak jauh.
Edit: k9 ternyata sudah mendukung OAuth untuk IMAP.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
Redaksinya agak ambigu, tetapi kata sandi khusus aplikasi tampaknya akan tetap berfungsi.
Kutipannya mengatakan scanner dan perangkat yang mengirim email melalui SMTP atau LSA harus dikonfigurasi untuk memakai OAuth, memakai metode alternatif, atau menetapkan kata sandi aplikasi untuk perangkat.
Juga dikatakan bahwa aplikasi yang tidak mendukung OAuth harus diganti dengan aplikasi yang menyediakan OAuth, atau dibuatkan kata sandi aplikasi untuk akses.
Jadi kemarin saya bertanya langsung ke Google Workspace Support, dan jawabannya adalah “kata sandi aplikasi mendukung konfigurasi IMAP, POP, dan semua SMTP”.
Kalimat kedua tetap mendorong adopsi OAuth. Saya juga ingin begitu, tetapi biaya tinjauan keamanan yang berulang tidak sanggup ditanggung aplikasi SaaS kecil seperti kami, jadi untungnya kami akan terus memakai kata sandi aplikasi.
Ini terkait akun Workspace, dan perubahan ini sudah diterapkan pada akun Gmail biasa beberapa tahun lalu
Saya masih mengakses akun Gmail pribadi di Mail.app iPhone dengan opsi Microsoft Exchange, dan menerima notifikasi push dengan cara ini tanpa terikat pada Fetch
Alasan ini masih berfungsi adalah karena koneksi ke Google Sync yang dibuat dengan akun pribadi sebelum tanggal penghentian sekitar 10 tahun lalu masih dipertahankan dan diakui seperti “hak lama”
Jadi agar bisa berfungsi, GUID Exchange iPhone perlu diubah menjadi GUID ponsel saat dulu login ke Google Sync sebelum login baru dihentikan
Untungnya, perubahan GUID ini bisa dilakukan dengan membuat cadangan iPhone, mengedit file plist di dalam cadangan, lalu memulihkannya
Sampai sekarang saya masih memakai Mail.app dan notifikasi push untuk akun Gmail pribadi di iPhone 14 Pro
Dari pengumumannya, saya memahami bahwa kata sandi aplikasi akan tetap dipertahankan untuk sementara. Namun jika suatu saat Google juga menghentikan kata sandi aplikasi, penggunaan klien pihak ketiga untuk GMail akan sangat dibatasi karena strukturnya mengharuskan klien OAuth menjalani penilaian keamanan dengan biaya sendiri
Email masih merupakan salah satu “protokol pesan terbuka” terakhir yang banyak digunakan, dan kita bisa memilih klien; jika arahnya begitu, itu akan menjadi perkembangan yang menyedihkan
Di perusahaan, kami menangani transisi OAuth Microsoft, dan itu cukup merepotkan
Sebagian masalahnya adalah prosesnya terlalu tidak transparan. Saat token dikirim, server hanya menjawab “tidak” tanpa penjelasan tambahan
Kami menghabiskan beberapa hari untuk mencari tahu mengapa alur Client Credentials tidak berfungsi, dan akhirnya menemukan jawaban jauh di dalam forum bantuan: “oh, client credentials flow belum didukung”. Sekarang sudah didukung untuk IMAP/POP, tetapi seingat saya belum untuk SMTP. Namun OAuth juga belum wajib untuk SMTP
Berikutnya adalah mencari tahu cakupan (scope) yang benar, dan saat itu dokumentasinya tidak terlalu baik. Pesan galat dari server juga sama sekali tidak membantu
Apakah server mail Google lebih baik?
Sayangnya, server tidak punya ruang untuk memberikan informasi yang “membantu” kepada klien yang belum terautentikasi