Cách chuyển hoàn toàn sang không mật khẩu

1. Giới thiệu: Tại sao triển khai passkey không phải là đích đến cuối cùng#

Việc triển khai passkey đại diện cho một bước tiến vĩ đại trong bảo mật xác thực, nhưng đó chưa phải là toàn bộ hành trình. Nếu bạn đã triển khai passkey, bạn có thể đang ăn mừng vì các chỉ số bảo mật được cải thiện, nhưng làm thế nào để bạn thực sự chuyển đổi từ việc có passkey sang đạt được xác thực hoàn toàn không mật khẩu?

Passkey cung cấp những lợi thế bảo mật quan trọng thông qua thiết kế chống phishing sử dụng mật mã khóa công khai gắn kết với các tên miền cụ thể, khiến những kẻ tấn công không thể lừa người dùng xác thực vào các trang web gian lận. Chúng loại bỏ việc tái sử dụng thông tin xác thực vì mỗi passkey là duy nhất cho một dịch vụ cụ thể, có nghĩa là việc một dịch vụ bị xâm phạm sẽ không ảnh hưởng đến các dịch vụ khác. Hơn nữa, chúng cung cấp khả năng miễn nhiễm đối với các cuộc tấn công brute-force bằng cách thay thế các bí mật cần ghi nhớ bằng các khóa mật mã không thể bị đoán hoặc bẻ khóa.

Tuy nhiên, những lợi thế mạnh mẽ này sẽ tan biến ngay khi người dùng có thể bỏ qua xác thực passkey và thay vào đó đăng nhập bằng mật khẩu. Điều này đặt ra một câu hỏi quan trọng: Tại sao chỉ riêng passkey là chưa đủ để bảo mật hoàn toàn? Câu trả lời nằm ở việc hiểu rằng chừng nào cánh cửa mật khẩu vẫn còn mở, những kẻ tấn công sẽ cố gắng đi qua nó. Thậm chí còn quan trọng hơn là câu hỏi, điều gì làm cho việc khôi phục tài khoản trở thành lỗ hổng tiềm ẩn có thể phá hoại toàn bộ quá trình triển khai passkey của bạn? Các vụ vi phạm dữ liệu đình đám gần đây đã chỉ ra rằng những kẻ tấn công ngày càng nhắm mục tiêu vào các luồng khôi phục thay vì xác thực chính.

Bài viết này sẽ hướng dẫn bạn qua toàn bộ hành trình từ triển khai passkey đến đạt được bảo mật không mật khẩu thực sự, giải quyết từng câu hỏi quan trọng này bằng các giải pháp thực tế và ví dụ trong thế giới thực.

"Không mật khẩu" (Passwordless) thực sự có nghĩa là gì?#

Xác thực không mật khẩu thực sự có nghĩa là loại bỏ hoàn toàn mật khẩu khỏi kiến trúc bảo mật của bạn. Trong một hệ thống không mật khẩu, người dùng không thể đặt, đặt lại hoặc sử dụng mật khẩu tại bất kỳ thời điểm nào trong hành trình xác thực của họ. Thay vào đó, xác thực hoàn toàn dựa vào các phương pháp mật mã như passkey.

Nhiều tổ chức tuyên bố là "không mật khẩu" trong khi vẫn duy trì mật khẩu chạy ngầm như một tùy chọn dự phòng. Đây không phải là không mật khẩu thực sự, mà đúng hơn chỉ là tùy-chọn-mật-khẩu (password-optional). Sự phân biệt này rất quan trọng bởi vì chừng nào mật khẩu vẫn tồn tại ở bất cứ đâu trong hệ thống của bạn, bao gồm cả các luồng khôi phục, chúng vẫn là một lỗ hổng có thể bị khai thác mà những kẻ tấn công sẽ nhắm tới.

2. Hai cửa hậu phá hoại bảo mật passkey#

Bảo mật không mật khẩu thực sự đòi hỏi vừa loại bỏ mật khẩu khỏi xác thực chính VÀ đảm bảo các quy trình khôi phục cũng có khả năng chống phishing tương đương.

2.1 Tại sao mật khẩu với vai trò tùy chọn dự phòng lại gây ra rủi ro bảo mật đáng kể#

Việc duy trì mật khẩu như một tùy chọn dự phòng bảo tồn mọi véc-tơ tấn công mà passkey được thiết kế để loại bỏ. Những kẻ tấn công chỉ cần xoay trục các chiến dịch phishing của chúng để nhắm vào việc nhập mật khẩu, trong khi các cuộc tấn công nhồi thông tin xác thực (credential stuffing) và rải mật khẩu (password spraying) tiếp tục sử dụng thông tin xác thực bị đánh cắp từ các vụ vi phạm khác. Kỹ nghệ xã hội vẫn có hiệu quả vì người dùng vẫn có thể bị lừa tiết lộ mật khẩu cho các nhân viên hỗ trợ giả mạo.

Chừng nào mật khẩu còn tồn tại, chúng vẫn là mắt xích yếu nhất, một điểm xâm nhập duy nhất hoàn toàn lách qua sự bảo mật chống phishing của passkey.

2.2 Cửa hậu khôi phục tài khoản#

Chỉ nhìn vào trải nghiệm đăng nhập là chưa đủ. Một véc-tơ tấn công quan trọng nhưng thường bị bỏ qua là luồng khôi phục tài khoản. Ngay cả các tổ chức đã triển khai passkey cũng có thể vẫn bị tổn thương nếu quy trình khôi phục của họ dựa vào các phương pháp dễ bị phishing như OTP qua SMS hoặc magic link qua email.

Hãy xem xét vụ rò rỉ dữ liệu đình đám tại MGM Resorts vào năm 2023, nơi những kẻ tấn công không nhắm mục tiêu vào hệ thống xác thực chính mà đã khai thác quy trình khôi phục tài khoản thông qua kỹ nghệ xã hội, vượt qua mọi biện pháp bảo mật chính. Tương tự, vụ xâm nhập hệ thống hỗ trợ của Okta đã chứng minh cách các luồng khôi phục có thể trở thành mắt xích yếu nhất, cho phép kẻ tấn công đặt lại thông tin xác thực và truy cập trái phép vào môi trường của khách hàng.

Những sự cố này nhấn mạnh một sự thật cốt lõi: triển khai passkey mà không bảo mật luồng khôi phục giống như lắp một cánh cửa thép nhưng lại để mở cửa sổ.

3. Hành trình không mật khẩu#

Đạt được xác thực không mật khẩu thực sự không phải là một bước đi đơn lẻ - đó là một hành trình chiến lược đòi hỏi lập kế hoạch cẩn thận, thiết kế sản phẩm và chiến lược kỹ lưỡng, triển khai theo từng giai đoạn và liên tục tối ưu hóa:

3.1 Giai đoạn 1: Thêm Passkey#

Giai đoạn đầu tiên tập trung vào việc giới thiệu passkey như một phương thức xác thực bổ sung trong khi vẫn duy trì các tùy chọn hiện tại làm phương án dự phòng. Giai đoạn xây dựng nền tảng này cho phép người dùng có thời gian hiểu và tin tưởng công nghệ mới trong khi vẫn giữ các phương thức quen thuộc sẵn có để giảm bớt ma sát.

Các bước triển khai chính:

• Tích hợp xác thực bằng passkey vào luồng xác thực hiện có của bạn
• Kích hoạt tạo passkey cho cả người dùng mới và người dùng hiện tại
• Duy trì mật khẩu và các phương thức xác thực khác làm lựa chọn thay thế
• Theo dõi tỷ lệ tạo passkey và các kiểu mẫu sử dụng

Chỉ số đo lường thành công:

• Tỷ lệ người dùng đã tạo ít nhất một passkey đạt trên 50%
• Tỷ lệ tạo passkey thành công trên 95%
• Việc sử dụng passkey ban đầu cho xác thực đạt 20-30%

3.2 Giai đoạn 2: Nâng cao tỷ lệ áp dụng passkey#

Khi passkey đã sẵn sàng, trọng tâm chuyển sang việc thúc đẩy áp dụng và biến passkey thành phương thức xác thực ưa thích. Giai đoạn này chuyển passkey từ một lựa chọn thay thế thành sự lựa chọn xác thực chính thông qua sự tương tác người dùng có tính chiến lược và tối ưu hóa.

Các bước triển khai chính:

• Đặt xác thực bằng passkey làm tùy chọn mặc định trong các luồng đăng nhập
• Triển khai intelligent prompts để khuyến khích việc tạo passkey sau các lần đăng nhập bằng mật khẩu thành công
• Giáo dục người dùng về những lợi ích bảo mật và tiện lợi thông qua tin nhắn trong ứng dụng
• Cung cấp các động lực khuyến khích để áp dụng passkey (thanh toán nhanh hơn, tính năng độc quyền)
• Thử nghiệm A/B với các cách tiếp cận giao diện UI và thông điệp khác nhau để tối đa hóa chuyển đổi
• Triển khai các chính sách truy cập có điều kiện yêu cầu sử dụng passkey cho các thao tác nhạy cảm

Chỉ số đo lường thành công:

• Hơn 60% người dùng hoạt động có ít nhất một passkey
• Hơn 80% số lần đăng nhập sử dụng passkey đối với các tài khoản đã bật passkey
• Tỷ lệ thất bại khi tạo passkey dưới 2%

3.3 Giai đoạn 3: Chuyển sang không mật khẩu#

Đây là lúc quá trình chuyển đổi bảo mật thực sự diễn ra: loại bỏ hoàn toàn mật khẩu đối với những người dùng liên tục sử dụng passkey. Giai đoạn này loại trừ véc-tơ tấn công chính bằng cách vô hiệu hóa mật khẩu cho những người dùng đã chứng minh việc áp dụng passkey thành công.

Các bước triển khai chính:

• Phân tích các mô hình xác thực của người dùng bằng cách sử dụng hệ thống giám sát thông minh
• Xác định những người dùng chỉ sử dụng passkey với nhiều thiết bị đã sẵn sàng passkey
• Cung cấp tính năng vô hiệu hóa mật khẩu kèm theo thông điệp rõ ràng về lợi ích bảo mật
• Xác minh sự khả dụng của passkey dự phòng (được đồng bộ hóa trên đám mây hoặc nhiều thiết bị)

Chỉ số đo lường thành công:

• Hơn 30% người dùng đủ điều kiện tự nguyện loại bỏ mật khẩu
• Không có sự gia tăng trong tỷ lệ khóa tài khoản (account lockout)
• Duy trì hoặc cải thiện điểm hài lòng của người dùng

3.4 Giai đoạn 4: Khôi phục chống phishing#

Giai đoạn cuối cùng giải quyết lỗ hổng cuối cùng: biến khôi phục tài khoản thành một quy trình chống phishing. Giai đoạn này đảm bảo các luồng khôi phục khớp với cấp độ bảo mật của xác thực chính, ngăn ngừa các cuộc tấn công qua cửa hậu (backdoor).

Các bước triển khai chính:

• Triển khai xác thực đa yếu tố với ít nhất một yếu tố có khả năng chống phishing
• Các yếu tố chống phishing sẵn có:
  • Passkey dự phòng (Backup Passkeys): Các passkey khôi phục được lưu trữ trên các thiết bị phụ hoặc dịch vụ đám mây cung cấp bằng chứng danh tính bằng mật mã (lựa chọn phổ biến nhất hiện nay)
  • Digital Credentials API: Tiêu chuẩn W3C cho các khẳng định danh tính được xác minh bằng mật mã từ các nhà cung cấp tin cậy (công nghệ đang nổi, chưa phổ biến)
  • Khóa bảo mật phần cứng (Hardware Security Keys): Các token FIDO2 vật lý được đăng ký làm các yếu tố khôi phục không thể bị phishing hoặc sao chép (yêu cầu người dùng mua và bảo quản thiết bị vật lý)
  • Xác minh tài liệu danh tính bằng nhận diện thực thể (Liveness Detection): Quét ID Chính phủ kết hợp với các hành động sinh trắc học theo thời gian thực để chứng minh sự hiện diện vật lý

Lưu ý về các tùy chọn khôi phục: Mặc dù Digital Credentials API và Khóa bảo mật phần cứng cung cấp bảo mật mạnh mẽ, chúng vẫn chưa được áp dụng rộng rãi. Cái trước vẫn là công nghệ mới nổi và cái sau đòi hỏi người dùng phải mua các thiết bị vật lý.

Khi không có passkey dự phòng, xác minh tài liệu danh tính kèm theo nhận diện thực thể trở thành một phương án thay thế khả thi. Bất chấp những cách lách luật tiềm ẩn nhằm qua mặt kiểm tra nhận diện thực thể mà không cần quyền sở hữu vật lý của một giấy tờ tùy thân, các phương pháp này vẫn cung cấp bảo mật mạnh mẽ hơn đáng kể so với mã OTP truyền thống, vốn có thể dễ dàng bị chặn thông qua phishing, hoán đổi SIM hoặc các cuộc tấn công trung gian (man-in-the-middle).

Chỉ số đo lường thành công:

• 100% các luồng khôi phục bao gồm các yếu tố chống phishing
• Không có bất kỳ vụ chiếm đoạt tài khoản nào thành công thông qua các quy trình khôi phục
• Tỷ lệ hoàn thành khôi phục duy trì trên 90%

4. Ví dụ về các công ty bắt đầu loại bỏ mật khẩu#

Phong trào không mật khẩu đang thu hút động lực trong toàn ngành công nghệ, với các công ty hàng đầu chuyển dịch ra khỏi mật khẩu.

4.1 Các tổ chức không mật khẩu hoàn toàn#

Một số công ty đã đạt được việc loại bỏ mật khẩu hoàn toàn trong các hoạt động nội bộ của họ. Okta, Yubico và Cloudflare đã thực sự đạt mức không sử dụng mật khẩu (zero password) trong nội bộ và các luồng đăng nhập của họ sẽ không chấp nhận mật khẩu chút nào.

4.2 Các công ty đang trong quá trình chuyển đổi tích cực#

Các gã khổng lồ công nghệ Google, Apple, Microsoft và X đang tích cực loại bỏ dần mật khẩu nhưng vẫn chưa loại bỏ chúng hoàn toàn. Cách tiếp cận của họ cân bằng giữa việc cải thiện bảo mật với quyền lựa chọn của người dùng trong giai đoạn chuyển đổi.

Google đã áp dụng một lập trường quyết liệt bằng cách bật mặc định tùy chọn "Bỏ qua mật khẩu khi có thể" (Skip password when possible) cho tất cả các tài khoản, biến passkey thành phương thức xác thực ưu tiên trong khi vẫn cho phép người dùng chọn không tham gia (opt out) nếu cần thiết. Cách tiếp cận opt-out này tạo ra động lực mạnh mẽ hướng tới không mật khẩu trong khi vẫn duy trì sự linh hoạt cho những người dùng chưa sẵn sàng chuyển đổi.

Microsoft tiến thêm một bước nữa bằng cách cho phép người dùng loại bỏ hoàn toàn mật khẩu khỏi tài khoản của họ ngay hôm nay, với kế hoạch "cuối cùng sẽ loại bỏ hoàn toàn tính năng hỗ trợ mật khẩu" trong tương lai. Lộ trình rõ ràng này báo hiệu cho người dùng rằng mật khẩu đang sắp hết thời, khuyến khích việc áp dụng sớm các phương pháp không mật khẩu.

Apple đã tích hợp passkey trên toàn bộ hệ sinh thái của mình và tích cực thúc đẩy việc sử dụng chúng, mặc dù mật khẩu Apple ID vẫn có sẵn dưới dạng tùy chọn dự phòng. Cách tiếp cận của họ tận dụng việc đồng bộ hóa liền mạch trên khắp các thiết bị Apple để làm cho việc áp dụng passkey trở nên trơn tru nhất có thể.

Những công ty này không ép buộc thay đổi ngay lập tức nhưng đang gửi đi một thông điệp rõ ràng: mật khẩu sẽ biến mất một khi sự áp dụng đạt đến mức độ đủ lớn (critical mass). Chiến lược của họ bao gồm việc biến passkey thành mặc định, giáo dục người dùng về những lợi ích và giảm dần các chức năng của mật khẩu.

5. Khi nào bạn nên bắt đầu loại bỏ mật khẩu?#

Quyết định loại bỏ mật khẩu không nên vội vàng hoặc áp dụng đại trà. Thay vào đó, hãy áp dụng một cách tiếp cận dựa trên dữ liệu, mang tính dần dần trong đó xem xét hành vi người dùng, khả năng của thiết bị và các hồ sơ rủi ro.

5.1 Ai nên bắt đầu hành trình không mật khẩu của mình ngay lập tức#

Các lĩnh vực rủi ro cao đang hứng chịu các cuộc tấn công phishing nghiêm trọng hiện nay nên bắt đầu chuyển đổi sang không mật khẩu ngay lập tức, nhưng vẫn tuân theo quy trình triển khai chiến lược và có từng bước:

• Ngân hàng & Tổ chức Tài chính: Mục tiêu hàng đầu cho việc đánh cắp thông tin xác thực. Đối với các ngân hàng châu Âu, passkey cũng phù hợp với các yêu cầu Xác thực khách hàng mạnh (Strong Customer Authentication - SCA) thuộc PSD2, cung cấp MFA chống phishing để đáp ứng tuân thủ quy định trong khi nâng cao trải nghiệm người dùng
• Nhà cung cấp Dịch vụ Thanh toán & Fintech: Quyền truy cập trực tiếp vào tiền của khách hàng khiến họ trở nên hấp dẫn đối với tội phạm mạng có tổ chức
• Các sàn giao dịch Tiền điện tử: Các giao dịch không thể đảo ngược có nghĩa là thông tin xác thực bị đánh cắp sẽ dẫn đến tổn thất vĩnh viễn
• Chăm sóc sức khỏe & Bảo hiểm: Phải đối mặt với cả các yêu cầu tuân thủ và rủi ro an toàn cho bệnh nhân từ hành vi trộm cắp danh tính y tế
• Chính phủ & Cơ sở hạ tầng Trọng yếu: Bị nhắm mục tiêu bởi các tác nhân đe dọa từ quốc gia-nhà nước bằng những chiến dịch spear-phishing tinh vi

Đối với các tổ chức này, hành động ngay lập tức là rất quan trọng, nhưng thành công vẫn đòi hỏi một cách tiếp cận triển khai tuần tự, có phương pháp. Hãy bắt đầu ngay hôm nay, nhưng triển khai một cách chiến lược để đảm bảo tỷ lệ áp dụng cao và tránh tình trạng khóa người dùng (user lockouts).

5.2 Chiến lược triển khai theo giai đoạn#

Bắt đầu với một nhóm nhỏ (Subgroup): Bắt đầu quá trình chuyển đổi không mật khẩu của bạn với những người dùng thể hiện việc sử dụng passkey nhất quán. Những người áp dụng sớm (early adopters) này sẽ giúp bạn xác định các vấn đề tiềm ẩn trước khi triển khai rộng rãi hơn.

Phân tích các mô hình hành vi người dùng:

• Tần suất đăng nhập và phương thức sử dụng
• Loại thiết bị và khả năng tương thích với passkey
• Các nỗ lực xác thực thất bại
• Việc sử dụng luồng khôi phục
• Các mô hình xác thực đa thiết bị (cross-device)

Người dùng đủ điều kiện để vô hiệu hóa mật khẩu dựa trên các mô hình này:

• Xác thực nhất quán thông qua passkey - cho thấy họ đã quen với công nghệ
• Sử dụng passkey trên nhiều thiết bị - chỉ ra rằng họ có các phương pháp truy cập dự phòng
• Đã không sử dụng mật khẩu hoặc các luồng khôi phục trong 30-60 ngày qua - chứng tỏ họ không phụ thuộc vào xác thực dựa trên mật khẩu

6. Corbado có thể giúp gì#

Corbado cung cấp một nền tảng toàn diện để hướng dẫn các tổ chức đi qua cả bốn giai đoạn của hành trình không mật khẩu được mô tả ở trên. Từ việc triển khai passkey ban đầu cho đến khi đạt được việc loại trừ hoàn toàn mật khẩu, giải pháp của Corbado xử lý sự phức tạp về mặt kỹ thuật trong khi cung cấp các công cụ cần thiết cho việc người dùng áp dụng thành công.

Hỗ trợ Giai đoạn 1 & 2: Corbado cung cấp sự tích hợp passkey liền mạch với các ngăn xếp xác thực (authentication stacks) hiện có, các lời nhắc thông minh (intelligent prompts) nhằm tối đa hóa tỷ lệ áp dụng và phân tích chi tiết để theo dõi các mô hình tạo và sử dụng passkey. Tính năng Passkey Intelligence của nền tảng tự động tối ưu hóa trải nghiệm người dùng dựa trên các khả năng của thiết bị và hành vi người dùng, đảm bảo việc làm quen với hệ thống (onboarding) diễn ra suôn sẻ.

Triển khai Giai đoạn 3 & 4: Đối với các tổ chức đã sẵn sàng loại bỏ hoàn toàn mật khẩu, Corbado cho phép vô hiệu hóa mật khẩu theo từng bước dựa trên mức độ sẵn sàng của người dùng trong khi duy trì các luồng khôi phục bảo mật, có khả năng chống phishing.

Bằng cách xử lý khả năng tương thích đa nền tảng, các cơ chế dự phòng và tối ưu hóa trải nghiệm người dùng, Corbado tăng tốc quá trình chuyển đổi sang không mật khẩu từ vài năm xuống còn vài tháng, cho phép các tổ chức tập trung vào hoạt động kinh doanh cốt lõi của họ trong khi vẫn đạt được xác thực chống phishing (phishing-resistant authentication).

Kết luận#

Hành trình tiến tới xác thực không mật khẩu thực sự giải đáp hai câu hỏi quan trọng mà chúng ta đã nêu ở phần đầu:

Tại sao chỉ riêng passkey là chưa đủ để bảo mật hoàn toàn? Bởi vì bảo mật chỉ mạnh bằng mắt xích yếu nhất của nó. Chừng nào mật khẩu vẫn còn sẵn có, ngay cả như một phương án dự phòng, những kẻ tấn công sẽ chỉ đơn giản chuyển hướng sang mục tiêu đó thông qua phishing, nhồi thông tin xác thực hoặc các cuộc tấn công hạ cấp (downgrade attacks). Mỗi mật khẩu trong hệ thống của bạn sẽ làm suy yếu các lợi ích bảo mật chống phishing của passkey.

Điều gì làm cho việc khôi phục tài khoản trở thành lỗ hổng tiềm ẩn? Các luồng khôi phục thường là những cửa hậu (backdoor) bị lãng quên. Như các vụ rò rỉ dữ liệu của MGM Resorts và Okta đã cho thấy, những kẻ tấn công ngày càng qua mặt những bản triển khai passkey mạnh mẽ bằng cách khai thác các phương pháp khôi phục yếu hơn như OTP qua SMS hoặc magic link qua email. Việc này giống như lắp đặt một cánh cửa thép kiên cố nhưng lại để ngỏ các cửa sổ.

Bảo mật không mật khẩu thực sự đòi hỏi phải hoàn thành toàn bộ hành trình: triển khai passkey, thúc đẩy việc áp dụng, loại bỏ hoàn toàn mật khẩu và bảo mật các luồng khôi phục bằng các phương pháp chống phishing. Chỉ bằng cách đóng lại tất cả các cánh cửa mật khẩu, bao gồm cả những thứ ẩn giấu trong quy trình khôi phục, các tổ chức mới có thể đạt được xác thực thực sự an toàn.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Những câu hỏi thường gặp#

Những tín hiệu nào cho thấy người dùng đã sẵn sàng để vô hiệu hóa mật khẩu trong quá trình triển khai không mật khẩu?#

Người dùng đủ điều kiện vô hiệu hóa mật khẩu khi họ liên tục xác thực bằng passkey trên nhiều thiết bị và không sử dụng mật khẩu hoặc luồng khôi phục trong 30 đến 60 ngày qua. Bắt đầu vô hiệu hóa với nhóm này giúp giảm rủi ro và phát hiện sự cố trước khi triển khai rộng rãi. Giai đoạn 3 nhắm mục tiêu 30% trở lên người dùng đủ điều kiện tự nguyện xóa mật khẩu.

Có những tùy chọn chống phishing nào cho việc khôi phục tài khoản khi không có passkey dự phòng?#

Có 4 yếu tố khôi phục chống phishing: passkey dự phòng trên thiết bị phụ, khóa bảo mật phần cứng (token FIDO2 vật lý), Digital Credentials API (tiêu chuẩn W3C đang nổi) và xác minh tài liệu danh tính bằng nhận diện thực thể (liveness detection). OTP qua SMS truyền thống và magic link qua email vẫn dễ bị tấn công phishing, hoán đổi SIM và tấn công trung gian (man-in-the-middle), khiến chúng không đủ an toàn cho các luồng khôi phục.

Tại sao vụ rò rỉ dữ liệu MGM Resorts vẫn thành công ngay cả khi đã có xác thực chính mạnh mẽ?#

Vụ rò rỉ dữ liệu MGM Resorts năm 2023 đã thành công bằng cách nhắm vào quy trình khôi phục tài khoản thông qua kỹ nghệ xã hội (social engineering) thay vì hệ thống đăng nhập chính, vượt qua hoàn toàn mọi biện pháp bảo mật chính. Điều này cho thấy việc triển khai passkey mà không bảo mật luồng khôi phục sẽ để lại một cửa hậu nghiêm trọng, giống như lắp một cánh cửa thép nhưng lại để mở cửa sổ.

Các nhóm cần đạt những chỉ số áp dụng nào trước khi chuyển từ tùy chọn passkey sang loại bỏ mật khẩu hoàn toàn?#

Trước khi bước vào Giai đoạn 3, các nhóm nên đạt 60% trở lên người dùng đang hoạt động có ít nhất một passkey, 80% trở lên các lần đăng nhập sử dụng passkey cho các tài khoản đã bật passkey và tỷ lệ tạo passkey thất bại dưới 2%. Thành công của Giai đoạn 3 được đo bằng việc 30% trở lên người dùng đủ điều kiện tự nguyện xóa mật khẩu mà tỷ lệ khóa tài khoản không tăng.