- Trong bối cảnh việc dùng MFA ngày càng tăng, Microsoft Authenticator có thể khiến người dùng bị khóa vì tài khoản TOTP mới được thêm bằng mã QR ghi đè tài khoản hiện có
- Mấu chốt của xung đột nằm ở thiết kế chỉ dùng label để phân biệt tài khoản, thay vì dùng cả issuer và label như Google Authenticator, Okta và các ứng dụng khác
- Việc ghi đè không lộ ra ngay, nên người dùng có thể chỉ gặp tình trạng không thể truy cập khi cố truy cập tài khoản hiện có sau vài tuần hoặc vài tháng
- Cách tránh là dùng ứng dụng xác thực khác hoặc nhập Secret Key thủ công, nhưng với người dùng phổ thông trong môi trường doanh nghiệp thì tính thực tế thấp
- Microsoft nói đây là hành vi có chủ đích và có cung cấp thông báo cảnh báo; sau đó hãng viện dẫn việc một số bên phát hành thiếu issuer, chỉ để ngỏ khả năng cải thiện trong tương lai
Cách quét QR ghi đè tài khoản MFA hiện có
- Khi thêm tài khoản mới bằng quét QR, Microsoft Authenticator có thể ghi đè một tài khoản hiện có có cùng tên người dùng
- Tên người dùng thường là địa chỉ email, nên việc các tài khoản MFA của nhiều dịch vụ cùng chia sẻ một label là tình huống phổ biến
- Google Authenticator và hầu hết các ứng dụng xác thực khác dùng kèm tên issuer như ngân hàng hoặc hãng xe để tránh xung đột
- Microsoft Authenticator không dùng kèm issuer mà chỉ định danh tài khoản bằng tên người dùng
- Sau khi ghi đè, cả tài khoản mới tạo lẫn tài khoản hiện có bị ghi đè đều có thể gặp vấn đề xác thực
Tình trạng bị khóa khó nhận ra nguyên nhân
- Khi bị khóa, người dùng có thể hiểu nhầm rằng vấn đề nằm ở công ty cung cấp xác thực hơn là Microsoft Authenticator
- Kết quả là helpdesk doanh nghiệp phải mất thời gian xử lý một tình huống không phải do chính họ tạo ra
- Rất khó dễ dàng xác định tài khoản nào đã bị ghi đè
- Việc tài khoản hiện có biến mất có thể không lộ ra cho đến khi người dùng cần dùng lại tài khoản đó
- Thời điểm này có thể là vài tuần hoặc vài tháng sau
Cách tránh và những phàn nàn đã tồn tại từ lâu
- Cách tránh dễ nhất là dùng ứng dụng xác thực khác thay cho Microsoft Authenticator
- Có thể tránh vấn đề bằng cách không quét mã QR mà nhập Secret Key thủ công
- Vấn đề này dường như không xuất hiện với các tài khoản xác thực thuộc tài khoản Microsoft
- CSO Online đã truy vết được các phàn nàn về vấn đề này từ năm 2020, và bản thân vấn đề có vẻ đã tồn tại từ khi Microsoft Authenticator ra mắt vào tháng 6/2016
- Năm 2020, một người dùng đã đề cập đến cách tránh bằng cách nhập thủ công Secret Key của Identity Provider, nhưng cho rằng cách để người dùng cuối trung bình trong môi trường doanh nghiệp xử lý chuỗi ngẫu nhiên như vậy là không hữu ích
Việc ghi đè được tái hiện tại hiện trường
- Brett Randall, một tư vấn IT tại Úc, đã chứng kiến trong một buổi đào tạo của nhà cung cấp việc người tham dự quét mã QR MFA bằng Microsoft Authenticator và ghi đè khóa TOTP của ứng dụng khác
- Theo Randall, mã QR MFA tạo ra một chuỗi chứa nhiều giá trị, và các ứng dụng khác kết hợp label với issuer để tạo ID duy nhất cho khóa đó
- Thay vì hành vi tiêu chuẩn này, Microsoft Authenticator chỉ dùng label, mà label đó thường là địa chỉ email
- Khóa TOTP cuối cùng dùng cùng địa chỉ email có thể bị ghi đè bằng khóa mới
- Randall mô tả việc khiến Microsoft nhận thức và xử lý vấn đề này là gần như bất khả thi
Phản ứng của các chuyên gia bảo mật và IT
- CSO Online đã yêu cầu nhiều chuyên gia bảo mật và IT tái hiện vấn đề, và tất cả đều làm được
- Gary Longsine, fractional CTO của IllumineX, xem đây là lỗi thiết kế và nói ông sẽ không khuyến nghị Microsoft Authenticator
- Tim Erlin, VP sản phẩm của Wallarm, nói rằng khi thêm mục thứ hai dùng cùng địa chỉ email thì xung đột xảy ra, và sau khi ghi đè thì không thể biết tài khoản nào đã bị ghi đè
- Erlin đề cập khả năng vấn đề này ít được biết đến hơn thực tế vì người dùng có thể không biết nguyên nhân
- David Meltzer, chief product officer của Netography, sau khi tự tái hiện, cho rằng đây là một lỗi rõ ràng và là vấn đề tương đối đơn giản để Microsoft sửa
- Người phát ngôn Google Kimberly Samra trả lời rằng Google Authenticator không ghi đè mã, và đây là một quyết định có chủ ý
Lập trường của Microsoft và nội dung cảnh báo
- Microsoft xác nhận vấn đề nhưng nói đây không phải lỗi mà là hành vi có chủ đích
- Trong phản hồi bằng văn bản đầu tiên, hãng giải thích rằng khi người dùng quét mã QR, họ sẽ nhận được thông báo xác nhận trước một thao tác có thể ghi đè thiết lập tài khoản
- Nội dung cảnh báo thực tế là “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
- Câu này hướng dẫn người dùng tiếp tục nếu chính họ đã khởi tạo thao tác và nguồn là đáng tin cậy
- Nếu người dùng tự bắt đầu quét QR từ một dịch vụ hợp pháp như ngân hàng hoặc khách sạn, hai điều kiện này hầu như đều được đáp ứng
- Nếu làm theo hướng dẫn và tiếp tục, việc ghi đè tài khoản có thể xảy ra
- Hộp cảnh báo không cung cấp cách nào để tránh ghi đè ngoài việc từ bỏ nỗ lực xác thực
Tranh cãi trách nhiệm quanh việc thiếu issuer
- Sau đó, trong phản hồi thứ hai dài hơn, Microsoft giải thích rằng một số site hoặc nhà cung cấp không đưa issuer, tức tên site hoặc tên Identity Provider, vào label
- Nếu đã có tài khoản hiện có có cùng label, ứng dụng có thể cố ghi đè tài khoản hiện có bằng tài khoản TOTP mới quét
- Microsoft nói trong tình huống như vậy, người dùng luôn nhận được thông báo xác nhận ghi đè và có thể chọn có tiếp tục hay không
- Câu “chúng tôi tiếp tục cải thiện sản phẩm và sẽ cân nhắc điều này để áp dụng vào các cải tiến trong tương lai” là phần duy nhất cho thấy khả năng Microsoft sẽ sửa vấn đề này
So sánh với các ứng dụng xác thực khác
- Randall cho rằng có hai cách để ngăn người dùng cuối vô tình ghi đè khóa của ứng dụng khác
- Kiểm tra otpauth của mọi ứng dụng và thuyết phục từng công ty sửa phần họ triển khai sai
- Microsoft sửa một lần để sau này không còn phải lo về vấn đề tương tự
- Randall nói ông đã thử nghiệm cùng hành vi xung đột trên 14 ứng dụng xác thực khác, nhưng không ứng dụng nào có hành vi giống Microsoft Authenticator
- Các ứng dụng được thử nghiệm gồm Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth, Authenticator 2FA Sentinel
1 bình luận
Các ý kiến trên Hacker News
Đây thực sự là một ví dụ nhỏ nhưng rất thấm về vấn đề lớn của bảo mật thiếu tính khả dụng
Hãy nghĩ đến những chuyện vô lý mà ta phải chịu dưới danh nghĩa “bảo mật”: bắt buộc đổi mật khẩu định kỳ, các quy tắc mật khẩu điên rồ, những yêu cầu không được ghi tài liệu phải tự mò qua thử-sai, thông báo lỗi phức tạp đầy thuật ngữ bảo mật, những “câu hỏi bí mật” mà chính mình cũng không nhớ câu trả lời, v.v.
Thế nhưng bảo mật của chính các hệ thống này lại thủng lỗ chỗ như cái rây. Rò rỉ dữ liệu và lộ thông tin gần như ngày nào cũng lên tin tức, và tôi thường tự hỏi làm sao chuyện đó cứ tiếp tục được cho qua như vậy
Trong nhiều tháng, mỗi lần đăng nhập tôi đều phải dùng “tìm tài khoản của tôi”, rồi lần nào cũng đặt lại tên người dùng thành địa chỉ email. Điều đó là hiển nhiên, vì gần 10 năm qua đó vẫn là thông tin đăng nhập của tôi
Giới hạn không được dùng
@hay.trong tên người dùng chưa từng được áp dụng cho đến lúc đăng nhập, và cuối cùng phải mất vài tháng tôi mới phát hiện ra rằng mình cần đổi sang giá trị khácTài khoản ban đầu là ING Direct, sau đó thành Capital One 360 rồi được tích hợp hoàn toàn vào đống hỗn loạn còn lại của Capital One, và tôi cho rằng vấn đề tên người dùng này cũng liên quan đến việc đó
Trang web: “Hãy chọn một mật khẩu phức tạp dài ít nhất 8 ký tự, có ký tự đặc biệt và chữ số”
Tôi mở trình quản lý mật khẩu, tạo một mật khẩu ngẫu nhiên 128 ký tự và thấy khá tự hào
Lần truy cập sau, trang web: “Hãy nhập ký tự thứ 31, 98 và 102 trong mật khẩu của bạn”
Đó là một trang web cho vay thế chấp nhà ở của Anh
Giờ nghĩ lại, để làm được việc này thì họ hoặc đang lưu mật khẩu dạng văn bản thuần, hoặc ít nhất là mã hóa chứ không băm, để có thể giải mã bất cứ lúc nào
Tôi nghĩ có thể đó là mật khẩu tạo bằng phiên bản thuật toán cũ nên thử lại, vẫn thất bại. Cuối cùng bấm đặt lại mật khẩu, nhận email, nhấp vào liên kết, rồi nhập mật khẩu do thuật toán tạo làm mật khẩu mới thì hiện “không được dùng ký tự đặc biệt đó”
Khi theo quy tắc của tôi đổi ký tự đặc biệt đó sang ký tự kế tiếp, lần này lại hiện “không thể đặt lại bằng mật khẩu hiện tại”
Theo trí nhớ của tôi thì có “cấm dùng từ”, “không được tái sử dụng 24 mật khẩu gần nhất”, “loại trừ một số ký tự đặc biệt”, “5 câu hỏi bảo mật”, cùng nhiều yêu cầu mật khẩu khác
Không ai biết câu hỏi bảo mật có phân biệt chữ hoa chữ thường hay không
Thậm chí còn có câu rằng bạn phải xác nhận thông tin tạo tài khoản là đúng sự thật và bạn đúng là người đó, và nếu cung cấp thông tin sai hoặc gây hiểu nhầm thì có thể bị phạt tiền, phạt tù, hoặc cả hai
Dùng từ 4 từ trong từ điển trở lên là có thể có bảo mật mật khẩu rất tốt, và cũng có thể dùng cách tương tự cho câu trả lời câu hỏi bảo mật. Cũng có nhiều trình quản lý mật khẩu miễn phí và trả phí giúp giải quyết vấn đề phải nhớ mọi giá trị bí mật. Chúng cũng hữu ích để sao lưu bí mật xác thực hai bước
Nếu “thông báo lỗi phức tạp” là lỗi mà người dùng được kỳ vọng tự sửa, thì tốt hơn là trả về một lỗi chung kèm ID duy nhất và yêu cầu liên hệ bộ phận hỗ trợ. Việc dội bom thuật ngữ chuyên môn rất khó chịu, nhưng có vẻ giống kiểu con người thường bất lực trong việc giải thích lỗi hơn là một vấn đề riêng của bảo mật
Phần lớn tổ chức, dù toàn bộ hoạt động kinh doanh có thành công, vẫn đồng thời làm hỏng rất nhiều việc, và bảo mật là một trong số đó. Tôi cho rằng với một tổ chức đủ lớn, việc có người kém năng lực làm những việc kém năng lực là điều khó tránh
Chuyện này khó hiểu ở nhiều tầng. Có nghĩa là Microsoft Authenticator lưu các mục chỉ dựa trên nhãn thôi sao? Nó không tạo cả khóa nội bộ hay thứ gì tương tự à?
Rồi họ lại cho rằng vấn đề là trang web đưa issuer vào nhãn thay vì trường issuer vốn phải dùng sao?
Tôi tự hỏi liệu ở Microsoft có ai thực sự dùng Authenticator của họ không. Nếu tôi không bỏ sót điều gì, thì ngay khi dùng email cho một trang, sẽ không thể thêm email đó cho trang khác, nên có vẻ gần như không dùng được với hầu hết ứng dụng
Trong khi đó bản iOS lại có ô tìm kiếm. Tôi thật không hiểu vì sao
Trong kho Piper khổng lồ chắc hẳn đã có một thư viện tìm kiếm cục bộ có thể nhét vào chỉ bằng một changelist, dù đúng là nó không phải mô hình ngôn ngữ lớn
Và tôi nghĩ rất nhiều người hoàn toàn không dùng nó
Tuy nhiên, tôi đã tìm thấy một vấn đề UI có thể khiến người dùng nhìn thấy mã sai. Mã của vài tài khoản đầu tiên hiển thị trên màn hình được làm mới mỗi 30 giây, nhưng mã của các tài khoản nằm ngoài màn hình thì không được làm mới
Khi cuộn để đưa các mã ngoài màn hình vào, bạn sẽ thấy mã cũ; trong một trường hợp, mã hiển thị bị trễ 4 vòng so với mã đúng
Kỳ lạ là tôi nhận được một email từ Microsoft trông giống phishing nhưng có vẻ không phải
Nội dung là “Cần hành động: Hãy bật xác thực đa yếu tố cho tenant của bạn trước ngày 15/10/2024”, nói rằng tôi nhận được vì là “quản trị viên toàn cục”, nhưng không có tên tổ chức, chỉ ghi một UUID
Email hướng dẫn rằng từ ngày 15/10/2024, việc đăng nhập vào Azure Portal, trung tâm quản trị Microsoft Entra và trung tâm quản trị Intune sẽ cần MFA, nên hãy bật MFA trước thời điểm đó. Nếu không làm được thì hãy xin hoãn ngày áp dụng
Vấn đề là tôi không quản lý bất kỳ tổ chức nào trên Microsoft cả. Tôi chỉ có thứ như tài khoản Office365 Family cá nhân, và tài khoản đó đã thiết lập xác thực 2 bước rồi
Email không có tên tôi, cũng không có tên tổ chức supposed nào, chỉ có ID nên tôi hoàn toàn không hiểu đang nói gì. Dù vậy, đúng là email đến từ Microsoft
Sau khi tạo tài khoản Gmail rồi đổi quốc gia và máy tính, tôi đã mất vài tài khoản. Khi cố đăng nhập, Google nói mật khẩu đúng nhưng thiết bị và IP thì lạ
Tôi không nhớ chính xác vì sao khôi phục qua địa chỉ khôi phục lại không được, nhưng dù vẫn truy cập được địa chỉ email khôi phục, việc khôi phục vẫn thất bại. Có lẽ Google yêu cầu tôi nói địa chỉ email khôi phục là gì, và có thể tôi đã dùng một hậu tố
+ngẫu nhiên cho địa chỉ khôi phụcTrước đây tôi dùng Google Authenticator cho tài khoản Gmail, nhưng trong tình huống Google gần như không đưa ra cách cứu vãn nào, tôi sợ lại thêm một điểm có thể hỏng nên đã tắt đi
Mật khẩu có entropy hơn khoảng 96 bit; tôi lấy 256 bit từ
/dev/urandom, biến thành số nguyên đa độ chính xác rồi dùngdivmodđể chọn mỗi loại một ký tự từ chữ số, chữ thường, chữ hoa và ký hiệu, phần còn lại chọn từ toàn bộ bảng chữ cái, sau đó dùng lượng entropy còn dư để chạy Fisher-Yates shuffle nhằm tránh việc ký tự đầu luôn là chữ sốĐó là mật khẩu riêng cho từng trang, được lưu trong trình quản lý mật khẩu dựa trên gpg mà tôi tự viết từ đầu những năm 2000
Xác thực đa yếu tố có ích đối với một số cuộc xâm nhập chủ động đang diễn ra, nhưng không giúp gì với các vụ rò rỉ cơ sở dữ liệu dẫn đến dump hash mật khẩu. Việc biết mật khẩu mà vẫn không khôi phục được qua địa chỉ email khôi phục thật sự rất khổ sở
Nếu tôi không đăng nhập ở đâu trong vài tháng và có mật khẩu đúng, thì ít nhất họ nên gửi liên kết hoặc mã xác minh tới địa chỉ khôi phục, thay vì bắt tôi phải nói địa chỉ khôi phục là gì. Không cần nói cho tôi biết họ gửi đến đâu, nhưng biến địa chỉ khôi phục thành một mật khẩu khác phải ghi nhớ thì thật sự rất bực
Giờ tôi không còn tin Google hơn những dữ liệu tôi đã đưa cho họ và những dữ liệu bắt buộc phải đưa nữa
Vì sắp di cư quốc tế, tôi phải đẩy nhanh việc chuyển đời sống email sang Proton Mail, một tài khoản trả phí mà tôi đang thử nghiệm, trước khi có vấn đề nghiêm trọng xảy ra
Hồi Gmail còn trông có vẻ ngây thơ, khi hành chính trực tuyến bắt đầu, tôi bắt đầu dùng Gmail làm địa chỉ liên hệ cho những nơi như thuế, y tế, cơ quan công quyền. Việc đó hoạt động tốt, và qua nhiều lần di cư quốc tế, Gmail đã trở thành một công cụ hành chính quan trọng
Tôi cũng có các tài khoản không hoạt động rải rác ở nhiều nơi, nhưng vẫn còn những việc quan trọng có thể một ngày nào đó cần đến. Ví dụ như các giấy phép du lịch Úc có hiệu lực trong vài năm
Ngay cả sau khi giám sát đại trà tăng tốc, Gmail vẫn trông khá vô hại, và ngoài việc tôi giao dịch với tổ chức nào, hầu như không có bí mật thật sự hay chuyện cá nhân sâu sắc nào
Nhưng giờ hành chính trực tuyến gần như là bắt buộc, còn các phương thức khác chỉ còn ở mức tối thiểu, Gmail đã trở thành trung tâm đến mức khó chịu. Những điều đáng lo mà bot tự động có thể làm với người dùng vô tội, không có lòng khoan dung hay quyền kháng cáo, đã buộc tôi phải bắt đầu chuyển đi
Nó phổ biến quá rộng nên tôi không đủ thời gian để tìm hết, còn các tài khoản bị quên thì phải đào bới ký ức mờ nhạt, như tra tấn vậy. Nhưng vẫn phải làm
Tôi không muốn khi hai cô con gái sinh đôi của mình đến tuổi cần email cho các việc công, chúng phải phó mặc cho lòng khoan dung của bot Google
toCó lẽ tôi có thể nói với quản trị viên để đặt lại, nhưng việc gần như giữ tài khoản làm con tin cho đến khi tôi giao thông tin cá nhân thì khá khó chịu
Tôi vẫn dùng đồ của Microsoft vì tài khoản công việc. Dù sao nó cũng đã ăn sâu vào Office365, nên chẳng có lý do gì để không dùng
Tôi chưa từng thấy hộp thoại kiểu đó, và các tài khoản đã thêm cũng không gặp vấn đề gì. Vì là tài khoản công việc nên 99% trường hợp tôi dùng email công ty làm tên tài khoản
Vậy có nghĩa là tôi may mắn vì các trang tôi dùng đều cung cấp nhãn đủ độc nhất sao? Tôi có cảm giác mình vẫn chưa hiểu hoàn toàn vấn đề chính xác là gì
Cuối cùng thời gian cứ trôi, và đây không phải việc kiếm sống cho gia đình mà chỉ là chuyện phiền phức phải đào bới xem cần làm gì để đăng nhập, nên tôi quyết định dùng đồ MS mà công ty cũ từng bắt dùng
Tôi đã lãng phí quá nhiều thời gian mày mò những thứ này chỉ để dùng tài khoản online, thay vì làm việc gì có ý nghĩa
Toàn bộ việc xác minh danh tính online cực kỳ không đáng tin cậy, đầy những lỗ hổng lớn và rủi ro còn lớn hơn, vậy mà chúng ta đang xây cả cuộc đời mình trên đó
Suốt nhiều thập kỷ đã có thiệt hại nghiêm trọng vì điểm yếu của mật khẩu nhưng chúng ta vẫn dùng mật khẩu, rồi cố vá víu bằng băng cá nhân hay sơn phủ lên
Hầu như tuần nào cũng có hệ thống online nào đó làm rò rỉ lượng lớn thông tin cá nhân dễ bị khai thác, nhưng chúng ta vẫn ngồi đó như meme con chó uống cà phê giữa căn phòng đang cháy, nói “ổn mà, ổn mà”
Chúng ta tự nhủ rằng nếu dùng mật khẩu khác nhau, dài hơn 8 ký tự cho mọi hệ thống thì sẽ an toàn, rồi tin là mọi chuyện sẽ ổn
Nếu kỳ vọng như vậy thì sản phẩm của Microsoft chắc sẽ tự đưa issuer vào nhãn, nên không gặp vấn đề
Vấn đề phát sinh khi dùng nhà cung cấp khác: họ dùng cùng email làm định danh, nhưng lại đặt issuer vào trường issuer, vốn sinh ra để lưu issuer. Nghe như bị xem là làm điều kỳ quặc vậy
Safari cũng có một lỗi tương tự, khiến passkey bị ghi đè mà không có cảnh báo nào, làm người dùng bị khóa hoàn toàn khỏi tài khoản. Sau đó lỗi đã được sửa, nhưng vì chuyện này tôi đã mất quyền truy cập GitHub
https://bugs.webkit.org/show_bug.cgi?id=270553
Safari hiện vẫn còn lỗi không thể phân biệt các website được host trên các subdomain khác nhau, ngoài các ngoại lệ hard-code, và sẽ ghi đè mật khẩu của một subdomain bằng mật khẩu của subdomain khác. Tôi gặp chuyện này hằng tháng
Nhưng tôi không biết sự ngớ ngẩn này còn đi sâu hơn nữa
Đây chính là lý do xác thực đa yếu tố qua SMS vẫn được người dùng ưa chuộng dù có lỗ hổng bảo mật
Thường thì nó đủ ổn miễn là bạn không trở thành mục tiêu của tấn công SIM swap. Phần lớn mọi người không phải mục tiêu, nhưng khả năng gặp vấn đề vì mất khóa xác thực đa yếu tố thì khá cao
Đây cũng là lý do các phương thức an toàn hơn như YubiKey không phổ biến được với đại chúng. Phiền phức và dễ gây rối
Giờ tôi chỉ dựa vào mật khẩu được tạo ngẫu nhiên
Khi cần đăng nhập đâu đó, bạn lấy thẻ khỏi ví rồi chạm vào điện thoại hoặc laptop
Nó phải đủ rẻ đến mức với một công ty có khách hàng trả tiền, việc gửi thẻ vật lý qua bưu điện khi khách không có thẻ còn hợp lý hơn là hỗ trợ các phương thức xác thực thay thế
Với đa số dịch vụ, có khi thậm chí không cần lớp xác thực thứ hai. Ai đó trộm ví của bạn thì liệu họ thật sự quan tâm đến cả tài khoản Reddit của bạn không?
Tôi đã thử kiểm tra và không có xung đột giữa nhiều tài khoản dùng cùng tên tài khoản/email
Mỗi mục đều hiện đúng biểu tượng issuer, và issuer được đăng ký trong từng mục
Tôi dùng MS Authenticator đã vài năm và chưa từng gặp vấn đề kiểu này; dĩ nhiên tôi luôn dùng cùng một email làm tên tài khoản hoặc tên người dùng
Tôi chỉ ghi lại kết quả thử nghiệm thôi. Chắc điều này sẽ không làm thay đổi suy nghĩ của ai về Authenticator hay Microsoft
Chuyện này cũng xảy ra với tôi khi tôi cập nhật MS Authenticator sau một thời gian không cập nhật
Toàn bộ dữ liệu bị xóa và tôi bị khóa khỏi mọi tài khoản. MS Authenticator không phải là một sản phẩm được làm cẩn thận
Khoảng 1 năm trước tôi cũng gặp chuyện tương tự khi ứng dụng Google Authenticator tự động cập nhật lên phiên bản mới
Trong quá trình cập nhật, tôi mất tất cả tài khoản, và chắc chắn đã rút ra được vài bài học