Passkey vẫn còn vấn đề

 (fy.blackhats.net.au)
7 điểm bởi GN⁺ 2025-12-19 | 4 bình luận | Chia sẻ qua WhatsApp
  • Tính đến năm 2025, passkey vẫn còn vướng các vấn đề về trải nghiệm người dùng và sự phụ thuộc vào nhà cung cấp giữa những tranh luận về bảo mật và tính tiện lợi
  • FIDO Credential Exchange mới được đưa vào giúp có thể di chuyển giữa các nhà cung cấp, nhưng ma sát xuyên nền tảng và tình trạng phân mảnh vẫn còn tồn tại
  • Nguy cơ không thể sao lưu và bị khóa tài khoản bởi các nhà quản lý nền tảng như Apple, Google, Microsoft vẫn tiếp diễn, đồng thời thiết kế UI hạn chế lựa chọn của người dùng cũng bị chỉ trích
  • Khái niệm passkey khó hiểu cùng với cách truyền thông dễ gây hiểu lầm của các dịch vụ làm suy giảm niềm tin của người dùng phổ thông
  • Để bảo vệ các tài khoản cốt lõi, việc dùng Credential Manager có thể tự kiểm soát và khóa phần cứng như Yubikey là rất quan trọng

TL;DR tóm tắt

  • Passkey vẫn còn những khiếm khuyết, và người dùng cần hiểu rõ để sử dụng theo điều kiện phù hợp với mình
    • Chỉ dùng Credential Manager của nhà cung cấp nền tảng (Apple, Google, Microsoft) sẽ có rủi ro không thể sao lưu và bị khóa
    • Khuyến nghị dùng Credential Manager có thể sao lưu như Bitwarden, Vaultwarden
    • Cần đồng bộ định kỳ sang Credential Manager bên ngoài thông qua FIDO Credential Exchange
    • Với các tài khoản quan trọng như email, nên dùng Yubikey làm nơi lưu passkey và duy trì mật khẩu mạnh + TOTP làm phương án bổ trợ
    • Nếu không thể truy cập Credential Manager, cần kiểm tra trước đường khôi phục

Những thay đổi trong 1 năm qua

  • Thay đổi lớn nhất là việc đưa vào đặc tả FIDO Credential Exchange
    • Nhờ đó, thông tin xác thực có thể được di chuyển giữa các nhà cung cấp passkey
  • Tuy vậy, ma sát giữa các nền tảng và sự chia cắt hệ sinh thái vẫn còn
    • Passkey giữa các thiết bị khác nhau có thể bị phân mảnh, và người dùng có thể không nhận ra điều đó
    • Passkey trên thiết bị Apple không thể đồng bộ sang thiết bị không phải Apple, trong khi Google và Microsoft có hỗ trợ một phần
    • Người dùng Apple có thể cảm nhận mức độ phụ thuộc mạnh hơn

Khái niệm passkey khó hiểu

  • Mật khẩu là “thứ tôi biết”, còn SMS 2FA là “thứ tôi có thể nhận”, nên có thể hiểu một cách trực quan
  • Ngược lại, passkey là yếu tố xác thực vô hình, người dùng không thể trực tiếp kiểm tra hay in ra
  • Cần có quá trình tin tưởng Credential Manager, nhưng passkey khiến bước xây dựng niềm tin đó bị bỏ qua
  • Ngay cả chuyên gia bảo mật cũng có thể nhầm lẫn về cách passkey hoạt động, cho thấy rào cản hiểu biết là rất cao

‘Thought leadership’ và vấn đề giáo dục người dùng

  • Một số nhân vật trong ngành cho rằng “việc phải học cách quản lý mật khẩu là thất bại của cả ngành”, nhưng thực tế passkey cũng đòi hỏi phải hiểu Credential Manager
  • Những người dùng thích mật khẩu và TOTP có thể không phải vì kiêu ngạo, mà vì vấn đề về tính khả dụng
  • Niềm tin rằng passkey có thể hoạt động mà không cần giáo dục người dùng là cách nhìn xa rời thực tế
  • Nếu sau khi đã hiểu đầy đủ mà người dùng vẫn chọn cách khác thay vì passkey, thì passkey đã thất bại với chính người dùng đó

Sự phụ thuộc vào nhà cung cấp vẫn còn nguyên

  • Dù đã có FIDO Credential Exchange, ma sát trong quá trình sử dụng thực tế và thiết kế UI điều hướng lựa chọn vẫn làm tăng chi phí chuyển đổi
  • Hộp thoại tạo passkey của Apple mặc định điều hướng người dùng dùng Apple Keychain, còn các lựa chọn khác (khóa bảo mật, Android, v.v.) bị ẩn dưới mục ‘Other Options’
  • Lựa chọn của người dùng không được ghi nhớ, và mỗi lần đều quay lại mặc định
  • Google Chrome cũng có cấu trúc tương tự, khuyến khích người dùng ở lại trong hệ sinh thái nền tảng
  • Đây không chỉ là vấn đề nơi lưu trữ, mà dẫn tới sự phụ thuộc trên toàn bộ trải nghiệm người dùng

Mất dữ liệu keychain đám mây

  • Vẫn có các trường hợp passkey biến mất khỏi Apple Keychain, hoặc không thể tạo hay sử dụng trên thiết bị Android
  • Trong một số trường hợp, ngay cả việc đặt lại thiết bị cũng không thể khôi phục, khiến quyền truy cập tài khoản của người dùng bị chặn hoàn toàn
  • Những vấn đề như vậy làm suy giảm độ tin cậy của passkey

Bị nhà cung cấp khóa tài khoản

  • Trong các trường hợp tài khoản Apple bị khóa, toàn bộ passkey rơi vào trạng thái không thể khôi phục và biến mất
  • Các trường hợp tương tự cũng tồn tại với Google và Microsoft
  • Chỉ một hành động trên tài khoản duy nhất cũng có thể tạo ra rủi ro phá hủy toàn bộ thông tin xác thực

Cách truyền thông dễ gây hiểu lầm từ các dịch vụ xác thực

  • Một số dịch vụ giải thích rằng “passkey gửi dữ liệu khuôn mặt hoặc vân tay”
  • Trên thực tế, dữ liệu sinh trắc học không rời khỏi thiết bị, nhưng người dùng phổ thông có thể hiểu nhầm rằng “khuôn mặt/vân tay của tôi bị gửi qua internet”
  • Cách giải thích như vậy gây ra sự mất lòng tin và cảm giác e ngại với passkey
  • UI của các nhà cung cấp nền tảng cũng không giải quyết được những hiểu lầm này

Các dịch vụ xác thực hạn chế lựa chọn của người dùng

  • Một số website vẫn chỉ cho phép một passkey duy nhất, hoặc dùng tùy chọn authenticatorAttachment để ép buộc chỉ dùng passkey phụ thuộc nền tảng
  • Điều này chặn việc dùng khóa bảo mật hoặc Credential Manager không thuộc nền tảng
  • Một số website còn có hành vi thiếu đạo đức như tự động thử đăng ký passkey khi đăng nhập mà không có sự đồng ý trước

Kết luận và khuyến nghị

  • Phần lớn vấn đề phát sinh từ cấu trúc quản lý passkey lấy nhà cung cấp nền tảng làm trung tâm
  • Người dùng nên thông qua Credential Manager có thể tự kiểm soát để
    giảm rủi ro bị khóa tài khoản, mất dữ liệu và thực hiện sao lưu định kỳ
  • Yubikey (firmware 5.7 trở lên) có thể lưu tối đa 150 passkey
    • Với một số tài khoản, nó có thể thay thế Credential Manager phần mềm
  • Tài khoản email là trọng tâm của đường khôi phục, vì vậy cần kết hợp khóa phần cứng + mật khẩu mạnh + TOTP và duy trì bản sao lưu ngoại tuyến
  • Các nền tảng như Apple, Google cần ghi nhớ lựa chọn của người dùng và
    cung cấp khóa bảo mật cùng nhà cung cấp khác một cách ngang hàng trong UI
  • Nhà phát triển nên tránh lọc trước bằng WebAuthn API, và
    chỉ tiến hành đăng ký passkey sau khi đã thông báo rõ ràng cho người dùng
  • Nguyên tắc cốt lõi là đảm bảo quyền kiểm soát và sự đồng ý (consent) của người dùng

Bài viết liên quan

4 bình luận

 
roxie 2025-12-19

Tôi thích passkey,,
 
yeobi222 2025-12-19

Nếu người dùng không hiểu cấu trúc của hệ thống bảo mật thì chỉ càng làm gia tăng sự bất tín mà thôi
Nói rằng bản thân tính dễ dùng là tốt thì cũng hơi khó
 
koxel 2025-12-19

Tôi từng xóa Google Password Manager một lần rồi mất sạch mọi thứ, sau khi phải cấp lại thì đã chuyển sang Bitwarden..
 
GN⁺ 2025-12-19
Ý kiến trên Hacker News

  • Tác giả vẫn còn hiểu nhầm về passkey. Nhiều người nghĩ rằng nếu mất passkey thì không thể khôi phục, nhưng thực tế cũng giống như mất mật khẩu. Hầu hết dịch vụ đều cho phép đặt lại mật khẩu qua email hoặc SMS. Tuy nhiên, với các tài khoản như Apple, Google, Facebook thì quy trình khôi phục phức tạp hơn, nên cần in mã dự phòng và cất giữ an toàn. Ngoài ra cũng nhất thiết phải có mật khẩu cuối cùng để đăng nhập vào password manager hoặc một phương thức bên ngoài như YubiKey

    • Tò mò không biết trước khi áp dụng passkey thì tài khoản Apple và Google đã có vấn đề bị khóa hay chưa. Hiện tại passkey không thể được người dùng tự sao lưu hoặc xuất ra, và việc các kỹ sư bảo mật chỉ tập trung vào ngăn chặn sao chép khóa đã khiến hàng tỷ người đối mặt với nguy cơ bị khóa tài khoản. Cách tiếp cận này có thể tạo ra rủi ro về mặt quản lý
    • Việc passkey có thể được đặt lại hay không phụ thuộc vào cách triển khai của nhà cung cấp dịch vụ. Cũng từng có phàn nàn rằng ở một số nơi chỉ có thể khôi phục qua điện thoại
    • Tài khoản Apple và Google lưu trữ hầu hết các mật khẩu và passkey khác, nên việc mất các tài khoản này là vấn đề nghiêm trọng hơn rất nhiều
    • Passkey tồn tại độc lập trên từng thiết bị, và không cần thiết phải thiết lập trên mọi thiết bị. Trên thiết bị khác chỉ cần đăng nhập bằng mật khẩu là được

  • Tôi muốn passkey được cải thiện ở hai điểm.

    1. Dù chỉ có một thiết bị đã đăng ký, UI vẫn hiển thị những lựa chọn không cần thiết
    2. Ngay từ đầu đáng ra nó nên có tính di động và linh hoạt như khóa SSH. Hiện giờ mức độ phụ thuộc vào nhà cung cấp quá cao
    • Trên Mac, có thể nhấn nút security key trước để bỏ qua bước chọn lựa
    • Không nên ẩn tùy chọn mà nên hiển thị màu xám và ghi “không có khóa nào được đăng ký”. Như vậy người dùng mới xác định được nguyên nhân vấn đề
    • Hệ thống passkey được thiết kế với mục tiêu không thể bị phishing, nên người dùng không thể tự xuất thông tin xác thực. Kết cục là nó trở thành một cấu trúc vendor lock-in. Ví dụ, muốn dùng passkey trong Safari thì bắt buộc phải có iCloud Keychain, nên không thể chỉ dùng cục bộ
    • Với người dùng không rành công nghệ, passkey có thể là một lựa chọn tốt. Tuy vậy, cần giúp họ ghi mã khôi phục ra giấy và cất giữ an toàn

  • Nhìn vào các vấn đề liên quan đến KeePass, có thể thấy áp lực từ ngành đang ngày càng lớn nhằm ngăn người dùng xuất khóa riêng của mình. Xu hướng này đáng lo ngại
    GitHub issue liên quan

    • Tôi là người viết bình luận trong issue đó. Việc mặc định yêu cầu bản sao lưu được mã hóa không phải là ngăn xuất dữ liệu, mà ngược lại còn giúp người dùng trực tiếp kiểm soát khóa của mình

  • Chừng nào nhà cung cấp dịch vụ còn ép buộc cách lưu passkey (phần cứng/phần mềm), hoặc ép dùng MFA như Touch ID, thì tôi vẫn thích tổ hợp mật khẩu + TOTP hơn

    • (1) Điều đó đã không thể rồi. Dịch vụ không thể ép buộc cách lưu passkey
    • (2) Cái đó không phải MFA mà gần với xác minh sinh trắc học (liveness check) hơn. Chỉ đơn giản là một bước chứng minh chính người đó đang đăng nhập
    • Trong tình huống khẩn cấp vẫn cần một phương án dự phòng có thể nhập thủ công. Cuối cùng lại quay về dạng giống mật khẩu

  • Tôi tuyệt đối không dùng passkey vì điểm “nhà cung cấp có thể khóa người dùng”. Đặc biệt, khi người dùng qua đời thì vấn đề người thừa kế không thể truy cập là rất lớn

    • Có các trường hợp liên quan: ca thất bại khi khôi phục Apple ID, thảo luận trên HN
    • Một số password manager cung cấp hệ thống gốc tin cậy ngoại tuyến. Ví dụ, Emergency Kit của 1Password cho phép người thừa kế hoặc người thân truy cập thông qua mã khôi phục được in ra
    • Dù là mật khẩu hay passkey, nếu chính sách của nhà cung cấp giống nhau thì mức độ hạn chế truy cập cũng như nhau
    • Sẽ thật tốt nếu có thể chuyển các thỏa thuận kiểu này thành ủy thác pháp lý (trust), nhưng các công ty có lẽ sẽ không thích điều đó
    • Tôi rất khó chịu với UI dark pattern ép đăng ký passkey. Chỉ dùng cho tài khoản công ty mà vẫn cứ hiện yêu cầu đăng ký. Tôi đã dùng SSO và 2FA rồi, không hiểu tại sao còn bắt dùng thêm passkey

  • UX của passkey rất tệ. Không biết có bao nhiêu cái đang được kích hoạt, và cũng có lúc ứng dụng xác thực quên mất passkey. Chỉ thấy rất rối

  • Tổ hợp Mật khẩu + TOTP vẫn là thực tế nhất. Chỉ cần đăng nhập Bitwarden là có thể di chuyển giữa các thiết bị. Trong khi đó, với passkey thì quy trình khôi phục khi mất thiết bị không rõ ràng. Thậm chí cũng không rõ vì sao passkey thiết lập trên iPhone lại hoạt động được trên desktop Linux. Nó chỉ có lợi cho người dùng một nền tảng duy nhất

    • Nếu đã đăng ký nhiều thiết bị hoặc đã đồng bộ thì có thể khôi phục, còn nếu không thì ngoài quy trình khôi phục tài khoản ra không còn cách nào khác. Cuối cùng không tốt hơn mật khẩu là bao

  • Xét cho cùng, passkey là một thiết kế quá phức tạp. Nếu chấp nhận lock-in thì có thể giảm bớt một số vấn đề, nhưng lại phát sinh ràng buộc mới. TOTP là một phương án thay thế thực tế

    • TOTP thì phiền thật nhưng người dùng có quyền kiểm soát. Vì vậy tôi đã tự làm tiện ích mở rộng Chrome LazyOTP để có thể dùng nó như xác thực một bước

  • Passkey là một giải pháp tuyệt vời cho phần lớn người dùng phổ thông. Nó loại bỏ việc phải quản lý mật khẩu phức tạp hoặc tái sử dụng mật khẩu, đồng thời cũng đơn giản hóa quy trình đăng nhập.
    Ngay cả từ góc nhìn hiểu biết kỹ thuật, tôi cũng thấy trải nghiệm đăng nhập nhanh và mượt tốt hơn nhiều

    • Nhưng nếu làm mất hoặc làm hỏng thiết bị thì quyền truy cập vào mọi tài khoản sẽ bị chặn. Mật khẩu viết ra giấy thì không có vấn đề đó
    • Ưu điểm lớn nhất của passkey là khả năng chống phishing. Không thể gửi thông tin xác thực vào sai tên miền
    • Tuy vậy, quá trình đồng bộ khóa bí mật giữa PC và điện thoại lại không rõ ràng. Cuối cùng có vẻ vẫn là cấu trúc bị trói chặt hoàn toàn vào hệ sinh thái Apple
    • Trên thực tế, tôi vẫn chưa từng thấy một triển khai nào hoạt động hoàn toàn trơn tru giữa nhiều nền tảng

  • Tôi đã chủ động xây dựng sẵn password manager và hệ thống 2FA, nhưng giờ xu hướng lại là chuyển sang passkey, khiến tôi có cảm giác mọi nỗ lực đó trở nên vô nghĩa. Tôi không thích một môi trường công nghệ mà người chuẩn bị trước lại bị thiệt