Google ngừng hỗ trợ Google Sync và các ứng dụng chỉ dùng mật khẩu
(workspaceupdates.googleblog.com)- Google Workspace chấm dứt phương thức Less Secure Apps (LSA), cho phép đăng nhập chỉ bằng tên người dùng và mật khẩu, và sẽ yêu cầu đăng nhập dựa trên OAuth cho việc đồng bộ email, lịch và danh bạ
- Lịch dừng hỗ trợ ban đầu bắt đầu theo 2 giai đoạn vào ngày 15 tháng 6 năm 2024 và 30 tháng 9 năm 2024, nhưng sau khi tạm dừng và khởi động lại quá trình rollout, LSA sẽ không còn được hỗ trợ từ ngày 1 tháng 5 năm 2025
- Các kết nối CalDAV, CardDAV, IMAP, SMTP, POP và Google Sync chỉ dùng mật khẩu sẽ bị ảnh hưởng, và cả người dùng Google Sync mới lẫn hiện tại đều nằm trong diện phải chuyển đổi
- Quản trị viên cần chia sẻ hướng dẫn chuyển sang OAuth cho người dùng bị ảnh hưởng, đồng thời các hồ sơ cấu hình dựa trên mật khẩu từng được triển khai qua MDM cũng phải đổi sang cách thêm lại Google Account bằng OAuth
- Người dùng không thực hiện thay đổi trước hạn sẽ không thể đăng nhập do lỗi sai tổ hợp tên người dùng-mật khẩu, và nhà phát triển cần cập nhật phương thức kết nối ứng dụng sang OAuth 2.0 để duy trì tương thích với Workspace
Chấm dứt phương thức đăng nhập chỉ dùng mật khẩu
- Google Workspace sẽ không còn hỗ trợ phương thức đăng nhập trong đó ứng dụng hoặc thiết bị bên thứ ba yêu cầu trực tiếp tên người dùng và mật khẩu Google
- Phương thức này được gọi là Less Secure Apps (LSA), và vì phải chia sẻ thông tin xác thực tài khoản Google với ứng dụng và thiết bị bên thứ ba nên làm tăng rủi ro truy cập trái phép vào tài khoản
- Phương án thay thế là Sign in with Google, sử dụng OAuth, phương thức xác thực tiêu chuẩn của ngành đã được đa số ứng dụng và thiết bị bên thứ ba hỗ trợ
- Google đã công bố thay đổi này từ năm 2019 và sau đó công bố lại lịch áp dụng
Lịch dừng hỗ trợ và các lần trì hoãn
- Việc chấm dứt truy cập LSA ban đầu gồm 2 giai đoạn
- Từ ngày 15 tháng 6 năm 2024, thiết lập LSA trong Admin Console bị gỡ bỏ và không thể thay đổi nữa
- Người dùng đã được bật trước đó vẫn có thể tiếp tục kết nối, nhưng người dùng đã bị tắt sẽ không thể truy cập LSA
- Bao gồm các ứng dụng bên thứ ba dựa trên CalDAV, CardDAV, IMAP, SMTP, POP truy cập Gmail, Google Calendar và Contacts chỉ bằng mật khẩu
- Thiết lập bật/tắt IMAP trong phần cài đặt Gmail của người dùng cũng bị gỡ bỏ
- Người dùng đã dùng LSA trước thời điểm này ban đầu vẫn có thể tiếp tục dùng đến ngày 30 tháng 9 năm 2024
- Từ ngày 30 tháng 9 năm 2024, đã có kế hoạch tắt truy cập LSA cho toàn bộ tài khoản Google Workspace
- CalDAV, CardDAV, IMAP, POP và Google Sync sẽ không còn hoạt động nếu đăng nhập chỉ bằng mật khẩu
- Để tiếp tục sử dụng, cần đăng nhập bằng OAuth, phương thức truy cập an toàn hơn
- Sau đó lịch trình đã được điều chỉnh nhiều lần
- Ở bản cập nhật ngày 15 tháng 10 năm 2024, rollout bị tạm dừng đến cuối năm và đổi sang kế hoạch nối lại vào tháng 1 năm 2025
- Ở bản cập nhật ngày 27 tháng 1 năm 2025, rollout được nối lại và việc vô hiệu hóa hoàn toàn được lên kế hoạch vào tháng 3 năm 2025
- Ở bản cập nhật ngày 12 tháng 2 năm 2025, ngày kết thúc hỗ trợ LSA được đổi thành ngày 14 tháng 3 năm 2025
- Ở bản cập nhật ngày 29 tháng 4 năm 2025, LSA sẽ không còn được hỗ trợ từ ngày 1 tháng 5 năm 2025
Những điểm cần kiểm tra với tổ chức đang dùng Google Sync
- Thay đổi lần này cũng bao gồm cả việc chấm dứt Google Sync
- Lịch dừng Google Sync ban đầu như sau
- Từ ngày 15 tháng 6 năm 2024, người dùng mới sẽ không thể kết nối với Google Workspace qua Google Sync
- Từ ngày 30 tháng 9 năm 2024, cả người dùng Google Sync hiện tại cũng sẽ không thể kết nối với Google Workspace
- Có thể kiểm tra việc sử dụng Google Sync trong tổ chức ở Admin Console
- Đường dẫn: Devices > Mobile & Endpoints > Devices
- Bộ lọc: Type: Google Sync
Tác động tới quản trị viên và cấu hình MDM
- Quản trị viên cần hướng dẫn người dùng cuối chuyển sang phương thức truy cập dựa trên OAuth để tiếp tục dùng ứng dụng với tài khoản Google Workspace
- Thông tin về người dùng bị ảnh hưởng sẽ được gửi tới tổ chức qua email trong vài tháng tới
- Các tổ chức dùng nhà cung cấp MDM để cấu hình hồ sơ IMAP, CalDAV, CardDAV, POP, Exchange ActiveSync (Google Sync) cũng bị ảnh hưởng
- Từ ngày 15 tháng 6 năm 2024, việc đẩy cấu hình MDM cho IMAP, CalDAV, CardDAV, SMTP, POP, Exchange ActiveSync (Google Sync) dựa trên mật khẩu sẽ không hoạt động với khách hàng lần đầu kết nối vào LSA
- Nếu dùng Google Endpoint Management, sẽ không thể bật thiết lập Custom Push Configuration cho CalDAV và CardDAV
- Từ ngày 30 tháng 9 năm 2024, việc đẩy cấu hình IMAP, CalDAV, CardDAV, SMTP, POP dựa trên mật khẩu cho người dùng hiện tại sẽ không còn hoạt động
- Quản trị viên cần dùng nhà cung cấp MDM để đẩy Google Account, cách này sẽ thêm lại tài khoản Google trên thiết bị iOS bằng OAuth
- Việc đẩy Exchange ActiveSync (Google Sync) dựa trên mật khẩu cũng sẽ không còn hoạt động với người dùng hiện tại
- Các thiết lập “Custom push configuration-CalDAV” và “Customer push configuration-CardDAV” trong Google Endpoint Management sẽ mất hiệu lực
Cách chuyển đổi theo thiết bị, ứng dụng và nhà phát triển
- Nếu máy quét hoặc thiết bị khác gửi email qua SMTP hoặc LSA, cần một trong các cách sau
- Cấu hình để dùng OAuth
- Dùng phương thức thay thế
- Cấu hình mật khẩu ứng dụng cho thiết bị đó
- Các ứng dụng truy cập tài khoản Google chỉ bằng tên người dùng và mật khẩu cần thực hiện chuyển đổi
- Nếu không thay đổi trước hạn, sẽ xuất hiện lỗi cho biết tổ hợp tên người dùng-mật khẩu không chính xác và không thể đăng nhập
- Hành động cần làm theo từng ứng dụng email
- Outlook 2016 hoặc cũ hơn cần chuyển sang Microsoft 365, Outlook for Windows hoặc Outlook for Mac, vì các ứng dụng này hỗ trợ truy cập bằng OAuth
- Một lựa chọn khác là dùng Google Workspace Sync for Microsoft Outlook
- Thunderbird hoặc các ứng dụng email khác cần thêm lại tài khoản Google và cấu hình IMAP bằng OAuth
- Nếu đang đăng nhập vào ứng dụng Mail trên iOS hoặc macOS, hoặc Outlook for Mac chỉ bằng mật khẩu, cần xóa tài khoản rồi thêm lại và chọn “Sign in with Google”
- Các ứng dụng lịch và danh bạ cũng phải chuyển sang phương thức có hỗ trợ OAuth
- Ứng dụng lịch CalDAV dựa trên mật khẩu phải chuyển sang phương thức có hỗ trợ OAuth, và Google khuyến nghị ứng dụng Google Calendar
- Nếu đang đăng nhập vào ứng dụng lịch trên iOS hoặc macOS chỉ bằng mật khẩu, cần xóa tài khoản rồi thêm lại và chọn “Sign in with Google”
- Nếu đang đồng bộ danh bạ qua CardDAV trên iOS hoặc macOS và đăng nhập chỉ bằng mật khẩu, cần xóa tài khoản rồi thêm lại và chọn “Sign in with Google”
- Nếu trên nền tảng hoặc ứng dụng khác đang chỉ dùng CardDAV và mật khẩu, cần chuyển sang phương thức có hỗ trợ OAuth
- Ứng dụng không hỗ trợ OAuth cần được thay bằng ứng dụng có hỗ trợ OAuth hoặc tạo mật khẩu ứng dụng để truy cập
- Nhà phát triển cần cập nhật phương thức kết nối ứng dụng sang OAuth 2.0 để duy trì khả năng tương thích với tài khoản Google Workspace
Tài khoản Google cá nhân và phạm vi áp dụng
- Với người dùng tài khoản Google cá nhân, nút bật/tắt IMAP trong phần cài đặt Gmail sẽ bị gỡ bỏ
- Truy cập IMAP trên tài khoản cá nhân luôn được bật thông qua OAuth và các kết nối hiện tại sẽ không bị ảnh hưởng
- Người dùng tài khoản Google cá nhân không cần thực hiện hành động riêng
- Thay đổi này áp dụng cho tất cả khách hàng Google Workspace
1 bình luận
Ý kiến trên Hacker News
Đọc bài này mà tôi giật mình trong chốc lát — vì tôi có khá nhiều script và công cụ tích hợp với Gmail
Nhưng có vẻ vẫn ổn. Mật khẩu ứng dụng dường như vẫn tiếp tục hoạt động, và thay đổi lần này gần hơn với việc loại bỏ hỗ trợ cho Less Secure Apps dùng tên người dùng/mật khẩu thông thường của tài khoản
Chỉ nghĩ đến việc sẽ có bao nhiêu quy trình tự động hóa chết đi nếu Google thật sự xóa bỏ mọi thứ ngoài OAuth cũng đã thấy rùng mình
Tôi ghét sự phức tạp của OAuth, và thích cách tài liệu của mô-đun Perl này phân tích cấu trúc đó. Rõ ràng là do một người bực bội như tôi viết ra: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...
Tôi cũng từng gặp vấn đề tương tự, và trên một Workspace thì mật khẩu ứng dụng bị chặn. Chỉ cần lấy token OAuth bằng một script Python nhỏ rồi dùng nó như mật khẩu: https://github.com/google/gmail-oauth2-tools/blob/master/pyt...
Xem ví dụ tại https://github.com/lefcha/imapfilter/issues/186
Hiện tại tôi vẫn phải bật công tắc LSA chỉ để tài khoản Gmail chính có thể gửi SMTP bằng thông tin xác thực của nhiều tài khoản Gmail khác. Tôi không hiểu vì sao trong mắt các tài khoản Gmail khác thì Gmail lại là LSA
Nó gồm 16 ký tự chữ thường, chia cách bằng khoảng trắng mỗi 4 ký tự, không có số cũng không có ký tự đặc biệt
Keepass đánh giá đây là mật khẩu yếu với khoảng 65 bit entropy khi bỏ các khoảng trắng
Tôi không hiểu đây cải thiện ở chỗ nào
Nếu không thể chuyển sang OAuth, bạn có thể dùng proxy của tôi để các client IMAP/POP/SMTP không hỗ trợ trực tiếp OAuth 2.0 vẫn dùng được với các nhà cung cấp email “hiện đại”: https://github.com/simonrob/email-oauth2-proxy
Client hoàn toàn không cần biết gì về OAuth
Nếu bạn không thể chuyển sang OAuth thì chỉ cần tạo mật khẩu ứng dụng và tiếp tục dùng nó như mật khẩu IMAP như bình thường
Vì IMAP, SMTP, POP cấp quyền truy cập đáng kể vào tài khoản Google và đời sống nói chung, nhưng lại không có cách nào để dùng xác thực hai yếu tố, và cũng không cung cấp xác minh chống bot
Điều đó khiến các cuộc tấn công nhồi thông tin xác thực trở nên rất dễ dàng, và ở quy mô của Google thì kiểu tấn công đó có thể phá hỏng cuộc sống của rất nhiều người
Đây là một thay đổi tốt và lẽ ra nên làm từ vài năm trước. Thực ra Google đã làm phần nào rồi bằng cách mặc định tắt truy cập IMAP/POP/SMTP, và phần lớn người dùng được bảo vệ nhờ vậy. Lần này là biện pháp dành cho số còn lại
Trong Dovecot, chỉ cần chọn mô-đun xác thực bạn muốn rồi sửa để nó đọc mật khẩu đầu vào dưới dạng
pwd+otp code. Nếu người dùng đã bật xác thực hai yếu tố thì đọc 6 ký tự cuối và so với TOTPNếu khớp thì cho phép IP đó trong x phút hoặc áp dụng bất kỳ chính sách nào bạn muốn
Nó hoạt động tốt một cách đáng ngạc nhiên
Địa chỉ đó không phải Gmail và là nơi vẫn tiếp tục cho phép IMAP/POP. Đây không phải thuốc chữa bách bệnh, nhưng có thể là giải pháp vòng chấp nhận được cho một số trường hợp sử dụng
Đây là cách lôi người dùng khỏi các ứng dụng mail native tuyệt vời để dồn họ sang ứng dụng của chính Google.
Nếu không có gmail.app hoặc Google Sync sắp bị khai tử, sẽ không thể nhận được thông báo email theo thời gian thực. Ghét thật. Dù đang trả tiền cho Workspace thì vẫn ghét. Trên desktop thì Mimestream vẫn còn hoạt động, nhưng có vẻ rồi nó cũng sẽ bị nhắm tới
JMAP là một giao thức chuẩn tốt, nhưng tỷ lệ chấp nhận lại thấp vô lý vì bài toán con gà - quả trứng giữa nhà cung cấp email và ứng dụng mail. Nếu Gmail hỗ trợ JMAP, điều đó có thể thúc đẩy các bên triển khai hỗ trợ ở khắp nơi. JMAP cũng hỗ trợ thông báo và nhiều tính năng khác
OAuth cho email đã nằm trong nhiều RFC liên quan đến xác thực email và đã tồn tại từ nhiều năm trước.
Thunderbird và nhiều ứng dụng di động khác hỗ trợ Gmail rất tốt bằng OAuth. Vấn đề lớn hơn là nhiều ứng dụng desktop có vẻ đã ngừng triển khai các thay đổi cho IMAP và SMTP từ khoảng 10 năm trước.
Nếu là ứng dụng email không còn được bảo trì nữa, thì có thể dùng mật khẩu ứng dụng như Google hướng dẫn trong bài liên kết. Chúng vẫn tiếp tục hoạt động. Thứ biến mất là kiểu tên người dùng/mật khẩu được mã cứng cho tài khoản chính.
Đây sẽ là nỗi đau đầu lớn với người dùng Office 2016. Ngày 30 tháng 9 vẫn còn sớm hơn khoảng 9 tháng so với thời điểm Outlook hết hỗ trợ. Nhưng với đa số người dùng, có lẽ đây là bản sửa khá dễ
Email vốn là bất đồng bộ, nên biết tin nhắn đến sau 10 phút cũng không phải vấn đề. Nếu là email đang chờ, đằng nào cũng sẽ bấm làm mới liên tục cho đến khi nó tới.
Gấp hơn thì nhắn tin là được. Mong là đừng gọi điện. Tôi ghét điện thoại
Có đoạn mô tả rằng: “Mật khẩu ứng dụng là mật mã gồm 16 ký tự cho phép ứng dụng hoặc thiết bị kém an toàn hơn truy cập vào Tài khoản Google, và chỉ có thể dùng với tài khoản đã bật xác minh 2 bước”: https://support.google.com/mail/answer/185833
Chẳng phải khá buồn cười sao khi “ứng dụng hoặc thiết bị kém an toàn hơn” có thể gần như tương đương ứng dụng hỗ trợ OAuth về mặt bảo mật chỉ bằng cách dùng các cơ chế phía máy chủ mà Google lẽ ra đã có thể khuyến khích từ trước. Về mặt kỹ thuật, điều này thậm chí còn có vẻ không phải là chức năng của ứng dụng.
Tất nhiên, cũng có thể nói rằng việc đơn giản hóa như vậy là hợp lý vì nếu gọi nó là “ứng dụng có quy trình an toàn nhưng kém tiện hơn” thì sẽ khó truyền đạt hơn. Vấn đề lớn hơn là Google có xu hướng luôn diễn giải các lo ngại bảo mật theo cách có lợi cho nghị trình của mình, và mẩu này cũng không ngoại lệ
Giờ họ chỉ mới bắt buộc điều đó với các ứng dụng không thể cập nhật để hỗ trợ OAuth
Mật khẩu ứng dụng về mặt chức năng gần như là cho phép tất cả hoặc chặn tất cả, còn với OAuth thì có thể cấu hình các quyền như đọc, chỉnh sửa, thay đổi cài đặt
Điều khó chịu nhất của Google OAuth2 trên Android là nếu muốn đăng nhập bằng tài khoản Google vào ứng dụng email hay lịch, thì toàn bộ điện thoại phải được liên kết với tài khoản Google đó.
Ngoài ra tài khoản Google đó còn có quyền chính sách thiết bị. Theo tôi thì điều này hoàn toàn vô lý.
Việc dùng OAuth2 trong WebView bên trong ứng dụng cũng khó lách trên Android vì Google có thể dễ dàng hạn chế điều đó
Đáng tiếc là không có nhiều ứng dụng email đáng tin cậy. Khá nhiều cái sẽ gửi thông tin xác thực lên máy chủ từ xa.
Sửa: k9 đã hỗ trợ OAuth cho IMAP rồi.
https://docs.k9mail.app/en/6.400/accounts/incoming_imap/
Câu chữ hơi mơ hồ, nhưng có vẻ mật khẩu dành riêng cho ứng dụng sẽ vẫn tiếp tục hoạt động.
Trong đoạn trích có nói rằng máy quét và thiết bị gửi email qua SMTP hoặc LSA phải được cấu hình để dùng OAuth, hoặc dùng phương án thay thế, hoặc thiết lập mật khẩu ứng dụng cho thiết bị.
Cũng có nói rằng các ứng dụng không hỗ trợ OAuth thì nên đổi sang ứng dụng có hỗ trợ OAuth hoặc tạo mật khẩu ứng dụng để truy cập
Vì thế hôm qua tôi đã hỏi trực tiếp Google Workspace Support, và câu trả lời là “mật khẩu ứng dụng hỗ trợ IMAP, POP, và mọi cấu hình SMTP”.
Câu thứ hai là nội dung tiếp tục thúc đẩy việc áp dụng OAuth. Tôi cũng muốn làm vậy, nhưng chi phí đánh giá bảo mật lặp đi lặp lại vượt quá khả năng của một ứng dụng SaaS nhỏ như bên tôi, nên may là chúng tôi vẫn sẽ tiếp tục dùng mật khẩu ứng dụng.
Đây là nội dung liên quan đến tài khoản Workspace, và với tài khoản Gmail thông thường thì đây là thay đổi đã được áp dụng từ vài năm trước
Tôi vẫn đang truy cập tài khoản Gmail cá nhân trên Mail.app của iPhone bằng tùy chọn Microsoft Exchange, không bị ràng buộc vào Fetch và vẫn nhận thông báo đẩy theo cách này
Nó vẫn hoạt động vì kết nối Google Sync được tạo cho tài khoản cá nhân trước ngày ngừng hỗ trợ khoảng 10 năm trước vẫn còn được duy trì và được công nhận theo kiểu “được giữ đặc quyền cũ”
Vì vậy, để làm nó hoạt động, chỉ cần sửa Exchange GUID của iPhone thành GUID của chiếc điện thoại đã từng đăng nhập Google Sync trước khi việc đăng nhập mới bị chặn
May là có thể thay đổi GUID này bằng cách tạo bản sao lưu iPhone, chỉnh sửa tệp plist trong bản sao lưu rồi khôi phục lại
Hiện tại tôi vẫn đang dùng Mail.app và thông báo đẩy cho tài khoản Gmail cá nhân trên iPhone 14 Pro
Theo nội dung thông báo, tôi hiểu là mật khẩu ứng dụng sẽ còn được duy trì trong một thời gian. Nhưng nếu một ngày nào đó Google loại bỏ cả mật khẩu ứng dụng, thì việc dùng ứng dụng khách bên thứ ba với GMail sẽ bị hạn chế rất nhiều, vì cấu trúc hiện tại buộc các OAuth client phải tự bỏ tiền để được đánh giá bảo mật
Email vẫn là một trong những “giao thức nhắn tin mở” cuối cùng còn được dùng rộng rãi và người dùng vẫn có thể chọn ứng dụng khách, nên nếu đi theo hướng đó thì thật đáng buồn
Ở công ty tôi đang xử lý việc chuyển đổi sang OAuth của Microsoft, và đó là một việc khá đau đầu
Một phần vấn đề là mọi thứ quá thiếu minh bạch. Bạn gửi token lên, rồi máy chủ chỉ trả lời “không” mà không có giải thích thêm
Tôi đã mất vài ngày để tìm hiểu vì sao luồng Client Credentials không hoạt động, và cuối cùng mới thấy câu trả lời ở sâu trong diễn đàn trợ giúp: “à, client credentials flow hiện vẫn chưa được hỗ trợ”. Hiện tại có vẻ nó được hỗ trợ cho IMAP/POP, nhưng theo tôi nhớ thì có lẽ vẫn chưa cho SMTP. Dù vậy, với SMTP thì OAuth vẫn chưa phải là bắt buộc
Sau đó là chuyện tìm ra phạm vi (scope) chính xác, mà vào thời điểm đó tài liệu gần như không ghi chép rõ ràng. Thông báo lỗi từ máy chủ cũng hoàn toàn không giúp ích gì
Máy chủ thư của Google có khá hơn không?
Đáng tiếc là máy chủ không thể cung cấp thông tin “hữu ích” cho các ứng dụng khách chưa được xác thực