Passkey không phải là cái bẫy: Vì sao bạn nên tiếp tục sử dụng

Trong vài ngày gần đây, một bài viết mang tựa đề "Passkeys are a trap. Do not use them" (Passkey là một cái bẫy. Đừng dùng chúng) đã lan truyền mạnh mẽ, leo lên vị trí cao trên Hacker News và được chia sẻ rộng rãi trong giới công nghệ. Nhiều người đã gửi bài viết này cho chuyên gia bảo mật Scott Helme kèm theo câu hỏi: "Liệu điều này có đúng không?". Bài phân tích dưới đây của chính Helme sẽ giải thích vì sao những lo ngại trong bài viết gốc phần lớn xuất phát từ sự hiểu nhầm về cách passkey vận hành.

Passkey và bảo mật tài khoản trực tuyến

Lập luận chính của bài viết gây tranh cãi

Bài viết gốc được viết cho "những công dân phi kỹ thuật của web", với lời khuyên chính là hãy ngừng dùng passkey và quay lại với mật khẩu truyền thống cùng mã TOTP.

Tác giả đưa ra một luận điểm trung tâm: passkey hỗ trợ một cơ chế gọi là attestation (chứng thực), cho phép website yêu cầu bằng chứng mã hóa về thiết bị và phần mềm đã tạo ra passkey đó. Tác giả gọi đây là một "núm xoay ẩn" và lập luận rằng các trang web sẽ dần dần vặn chặt nó, cho đến khi bạn chỉ có thể đăng nhập bằng phần mềm được phê duyệt trên hệ điều hành được phê duyệt — không cho phép tùy chỉnh, không có LineageOS, và không thể chia sẻ mật khẩu Netflix.

Kết hợp thêm các chi tiết như uBlock Origin, danh sách thành viên FIDO Alliance và đề xuất quét hình ảnh của Vương quốc Anh, bài viết đi đến kết luận rằng passkey "không được thiết kế để ưu tiên lợi ích của bạn". Đây là một câu chuyện hấp dẫn — nhưng nó không khớp với cách mọi thứ thực sự vận hành.

Passkey của bạn không hề chứng thực

Điểm mấu chốt cần làm rõ: passkey mà hầu hết mọi người đang sử dụng là passkey đồng bộ (synced passkey), được lưu trong iCloud Keychain, Google Password Manager, 1Password, Bitwarden hoặc phần mềm khác do bạn chọn.

Những passkey này hoàn toàn không cung cấp tuyên bố attestation nào cho website. Dù site có yêu cầu, thứ nhận về cũng chỉ là "không có gì". Helme khẳng định điều này dựa trên kinh nghiệm trực tiếp: ông từng viết một thư viện passkey mã nguồn mở và chia sẻ rộng rãi.

Nếu một website tiêu dùng quyết định rằng từ mai họ chỉ chấp nhận passkey có attestation, họ sẽ ngay lập tức khóa đường đăng nhập của gần như toàn bộ người dùng. Không một nền tảng nào dám làm điều đó. Hơn nữa, hướng dẫn dành cho các site tiêu dùng trong nhiều năm nay đã là: thậm chí đừng yêu cầu attestation.

Attestation không phải như bạn tưởng

Bài viết gốc mô tả attestation là cơ chế chứng minh "rằng một trình quản lý passkey, hệ điều hành và firmware đã được phê duyệt đang được sử dụng". Điều này đơn giản là không đúng.

Khi xuất hiện, attestation trong WebAuthn chỉ cho website biết nhà sản xuất và kiểu mẫu của thiết bị xác thực, được nhận diện qua mã AAGUID, kèm theo chuỗi chứng chỉ từ nhà cung cấp để xác nhận. Nó không nói gì về hệ điều hành của bạn, trình duyệt, tiện ích mở rộng, việc điện thoại đã root hay jailbreak, phiên bản firmware — thậm chí cả màu sắc thiết bị.

Nghịch lý khi khuyên dùng YubiKey

Đây là phần khiến tác giả bài phân tích bất ngờ nhất. Với những người muốn bảo mật mạnh hơn, bài viết gốc khuyên dùng khóa bảo mật phần cứng như YubiKey, lý do là nó "tránh được attestation trên toàn hệ điều hành".

Nhưng thực tế ngược lại hoàn toàn: YubiKey chính là thiết bị xác thực có attestation. Mỗi chiếc YubiKey đều đi kèm chứng chỉ attestation do Yubico cấp, và attestation cấp doanh nghiệp tồn tại chính là để các tổ chức có thể yêu cầu dùng khóa phần cứng được phê duyệt.

Nói cách khác, nếu attestation là điều bạn lo ngại, thì chính khuyến nghị trong bài viết gốc lại đẩy bạn về phía attestation chứ không phải tránh xa nó. Dĩ nhiên, YubiKey vẫn là thiết bị tuyệt vời và chính Helme cũng dùng chúng — vấn đề nằm ở lập luận thiếu nhất quán.

TOTP là bước thụt lùi

Bài viết gốc ca ngợi TOTP như một giải pháp "đã đủ tốt". TOTP chắc chắn tốt hơn mật khẩu đơn thuần, nhưng nó có một điểm yếu lớn: bạn có thể gõ mã vào nhầm website.

Các bộ công cụ lừa đảo như Evilginx đứng ở giữa, chuyển tiếp mật khẩu và mã của bạn đến trang thật theo thời gian thực, rồi đánh cắp phiên đăng nhập. Đây không phải giả thuyết — đó là cách hàng loạt vụ chiếm đoạt tài khoản diễn ra ngày nay, và đã có đầy đủ bằng chứng.

Đây chính là vấn đề mà passkey giải quyết. Một passkey được gắn chặt với tên miền mà nó được tạo ra, nên trình duyệt sẽ đơn giản là không dùng passkey của example.com trên examp1e.com. Không có mã để đọc ra, không có gì để người dùng làm sai.

Đáng chú ý, ngay cả tác giả bài viết gốc cũng thừa nhận trong phần bổ sung rằng passkey gắn với tên miền và chống lại tấn công man-in-the-middle — nhưng vẫn khuyên độc giả tránh chúng. Đánh đổi một thông tin xác thực chống lừa đảo lấy một thông tin có thể bị lừa đảo là một sự đánh đổi rất tồi.

Vậy bạn nên làm gì?

Lời khuyên rõ ràng: hãy tiếp tục sử dụng passkey. Ở bất cứ đâu một trang web cung cấp passkey, hãy dùng nó và lưu vào trình quản lý mật khẩu/passkey mà bạn tin tưởng. Nếu bạn muốn có thể di chuyển thông tin xác thực giữa các nền tảng, hãy chọn nhà cung cấp hỗ trợ điều đó.

Nếu bạn lo ngại attestation sẽ len lỏi vào đăng nhập tiêu dùng, điều đó hoàn toàn đáng để lên tiếng phản đối — nếu nó xảy ra. Nhưng hiện tại nó chưa xảy ra, các nhà cung cấp lớn không hỗ trợ nó, và việc tránh passkey hôm nay để chờ đợi một điều chưa đến sẽ không bảo vệ bạn khỏi bất cứ điều gì. Nó chỉ khiến bạn dễ bị lừa đảo hơn.

Passkey hiện là giải pháp tốt nhất chúng ta có để bảo vệ tài khoản. Và chúng không phải là một cái bẫy.

Bối cảnh từ tác giả

Scott Helme không phải người ngoài cuộc trong lĩnh vực này. Ông đã tạo WhyNoPasskeys.com để theo dõi mức độ sẵn có của passkey trên web, tự tay triển khai hỗ trợ passkey cho công ty SaaS của mình, xây dựng thư viện passkey riêng và đưa qua kiểm định bảo mật, đồng thời công khai thừa nhận những hạn chế của việc không dùng attestation. Thư viện passkey của ông được mở mã nguồn cho tất cả mọi người sử dụng.

Với độc giả Việt Nam, đây là bài học đáng lưu tâm: làn sóng chuyển đổi sang passkey đang diễn ra tại các nền tảng lớn như Google, Apple và Microsoft, và việc nắm đúng bản chất công nghệ sẽ giúp bạn đưa ra quyết định bảo mật sáng suốt thay vì chạy theo những lập luận giật gân nhưng thiếu chính xác.