Vì sao giấc mơ về Passkeys tan vỡ
Giấc mơ
- Năm 2019, tác giả bắt đầu phát triển thư viện Webauthn cho Rust
- Khi đó, đã có sự lạc quan rằng công nghệ này có thể thay thế mật khẩu
- Kỳ vọng có thể hỗ trợ xác thực hai bước, xác thực không cần mật khẩu và xác thực không cần tên người dùng
- Thư viện do tác giả phát triển đã tạo ảnh hưởng lớn trong ngành
Dấu hiệu cảnh báo
- Chrome đang thống trị thị trường, nên nếu Chrome không hỗ trợ thì sẽ nảy sinh vấn đề là bị loại khỏi tiêu chuẩn
- Authenticator Selection Extension là một ví dụ tiêu biểu
- Việc các quyết định quan trọng được đưa ra tại các cuộc họp trực tiếp tổ chức ở Mỹ cũng là một vấn đề
- Dẫn đến tình trạng những người tham gia quốc tế bị loại trừ
Xu hướng đi xuống
- Năm 2022, Apple công bố Passkeys
- Ban đầu trông có vẻ được thiết kế tốt, nhưng sau đó qua phát biểu của lãnh đạo, Passkey được định nghĩa là Resident Key
- Điều này dẫn đến việc loại trừ các security key có dung lượng lưu trữ nhỏ
- Sau đó, Passkey bị biến chất thành một công cụ để khóa người dùng trong nền tảng
Tình hình ngày càng xấu đi
- Chrome và Safari ép buộc dùng caBLE thay vì security key
- Đây là cách có trải nghiệm sử dụng rất kém
- Android chặn việc dùng security key trên các website hỗ trợ Passkey
- Các ví dụ dành cho nhà phát triển cũng dẫn dắt theo hướng chỉ dùng Google Passkey
- Người dùng đang gặp rất nhiều khó khăn khi sử dụng Passkey
- Phát sinh các vấn đề như lỗi, quy trình phức tạp và mất khóa
- Việc Passkey bị xóa khỏi Apple Keychain xảy ra khá thường xuyên
Triển vọng
- Tác giả dự đoán Passkey sẽ thất bại với người tiêu dùng phổ thông
- Việc doanh nghiệp theo đuổi lợi ích đã làm tổn hại trải nghiệm người dùng
- Thậm chí đối tác của tác giả còn nói rằng cách dùng mật khẩu tốt hơn Passkey
- Trong doanh nghiệp, security key vẫn cần thiết, nhưng vấn đề về tính dễ dùng vẫn còn
- Tác giả sẽ tiếp tục duy trì dự án webauthn-rs, nhưng đang tìm kiếm các phương án khác thay vì Passkey
Ý kiến của GN⁺
- Việc Passkey đi theo hướng loại bỏ security key và làm sâu sắc thêm sự phụ thuộc vào nền tảng là một điểm đáng lo ngại. Việc hạn chế quyền lựa chọn của người dùng có vẻ không mong muốn.
- Có vẻ cần vừa phát triển công nghệ vừa cải thiện tính dễ sử dụng. Có lẽ không nên để nó trở nên quá phức tạp hoặc quá hạn chế.
- Việc ảnh hưởng của một số ít công ty ngày càng lớn và gây ra vấn đề trong quá trình tiêu chuẩn hóa cũng có vẻ là điều cần được giải quyết khẩn cấp. Có lẽ cần xây dựng một cơ chế ra quyết định cởi mở và minh bạch hơn.
- Các phương án như chứng chỉ thiết bị hoặc smart card được nêu ra như lựa chọn thay thế có vẻ khá thú vị. Chúng có thể là cách vượt qua giới hạn của Passkey hiện tại đồng thời cải thiện tính dễ sử dụng.
- Vì hiện vẫn đang ở giai đoạn chuyển tiếp, có vẻ vẫn cần tiếp tục phát triển công nghệ và tiếp thu phản hồi từ người dùng trong tương lai. Hy vọng nhiều bên liên quan sẽ hợp tác để xây dựng một hệ thống xác thực tốt hơn.
3 bình luận
Tương lai không mật khẩu đang đến
Giới thiệu Passkey trên Chrome
Ý kiến trên Hacker News
Vấn đề lớn nhất của Passkeys là không thể tin tưởng các công ty cung cấp chúng. Vì lý do bảo mật, chúng bị khóa vào nền tảng, nhưng trong nhiều trường hợp rất khó phân biệt với việc bị khóa chặt hệ sinh thái. Nếu tạo Passkey trên thiết bị Apple thì nó sẽ không bao giờ rời khỏi thiết bị đó, và không có cách nào để thay đổi điều này. Điều này an toàn trước phishing, nhưng nếu Apple xóa khóa hoặc nếu muốn bỏ iPhone thì không rõ phải làm sao.
Trong các cuộc thảo luận dài về Passkeys, có vẻ như có một sự né tránh kỳ lạ đối với phần bảo mật là "thứ bạn biết". Ở Mỹ, tòa án và cơ quan thực thi pháp luật có thể hợp pháp yêu cầu tên người dùng, dấu vân tay, quét võng mạc, Face ID, v.v., nhưng họ không có quyền trích xuất thứ gì đó từ não bạn. Passkeys thích thay thế "thứ bạn biết" bằng "thứ bạn có", và đó là cơn ác mộng đối với bảo mật.
Ý kiến ngược lại: rất thích Passkeys. Dùng trình duyệt Firefox và trình quản lý 1Password, và trên iPhone thì dùng 1Password + Firefox. Xem passkeys.directory rồi chuyển đăng nhập GitHub, Google, Microsoft, v.v. sang Passkeys. Những cụm như "đăng nhập bằng Passkey" thay vì "đăng nhập bằng Touch ID" gây nhầm lẫn. 1Password đồng bộ Passkeys giữa các thiết bị. Nếu cần đăng nhập trên máy tính công cộng thì có thể bất tiện, nhưng không phải làm việc đó thường xuyên.
Vẫn đang tránh Passkeys vì chưa có một mô hình tư duy rõ ràng về nó. Hiện đang dùng mật khẩu ngẫu nhiên do trình quản lý mật khẩu hiện có tạo ra nên không thấy cần phải chuyển đổi. Tên người dùng/email + mật khẩu thì dễ hiểu, nhưng nhớ lại sự đau đớn của "mật khẩu dành riêng cho ứng dụng" nên lo rằng một số công cụ mã nguồn mở/CLI có thể không tích hợp tốt với Passkeys; có lẽ tốt hơn là chờ cho đến khi tình hình ổn định.
Đã đầu tư hoàn toàn vào hệ sinh thái Apple Keychain và có nhiều thiết bị Apple, nên Passkeys rất tuyệt. Với tư cách lập trình viên, hằng ngày đều thấy giới hạn của SMS 2FA yếu kém. Người dùng rất dễ bị social engineering để đọc mã 2FA cho người khác. Passkeys cung cấp giải pháp an toàn hơn, để lập trình viên không phải lo người dùng gọi lên bộ phận CS rồi đọc to mã cho họ. Passkey không bị xâm phạm bởi SIM swapping, và cũng không thể chia sẻ Passkey với kẻ lừa đảo.
Với tư cách người làm kỹ thuật, vẫn chưa thực sự hiểu Passkeys hoạt động thế nào, tốt hơn ở điểm nào, và chính xác nó là gì. Nếu một tính năng bảo mật không đơn giản như việc nhớ tên người dùng và mật khẩu rồi lưu chúng ở nơi an toàn, thì nó sẽ không hoạt động. Có nhắc đến khóa trên thiết bị, nhưng khi vừa dùng điện thoại vừa dùng PC thì truy cập bằng cách nào, ban đầu có cần tên người dùng/mật khẩu không, và có cần một khóa vật lý phải cắm vào thiết bị hay không?
Usernameless có vẻ là tối ưu hóa quá mức. Việc người dùng dùng tên người dùng khi đăng nhập là hợp lý và tốt. Nó giúp họ nhớ lại mình đang dùng tên người dùng nào. Có thể xảy ra tình huống người dùng truy cập dịch vụ bằng Usernameless Passkey, rồi vì lý do nào đó làm mất Passkey và cũng quên luôn tên người dùng cho dịch vụ đó, dẫn đến không thể bắt đầu quy trình khôi phục tài khoản.
Với những ai không biết Passkeys hoạt động kỹ thuật ra sao, có thể tham khảo hướng dẫn triển khai sau: https://webauthn.guide/ Không hiểu vì sao lại ghét Passkeys đến vậy. Việc chuyển sang cơ chế thách thức bằng khóa công khai để xác thực là một bước tiến lớn cho bảo mật web. Mỗi trình duyệt/HĐH đều bảo vệ và sao lưu khóa riêng tư. Kể cả khi mất khóa, vẫn có thể dùng luồng "quên mật khẩu" để đặt lại thông tin xác thực.
Để cân nhắc dùng Passkeys, các yêu cầu sau phải được đáp ứng:
Chưa kiểm tra xem việc triển khai WebAuthn trên Firefox hay Chrome trên Linux có đáp ứng các yêu cầu này hay không.
Đang cố theo dõi sự phát triển của không gian 2FA, và Passkeys là thứ gây bối rối nhất. Đã thấy rất nhiều quảng bá thổi phồng rằng Passkeys là công nghệ thế hệ tiếp theo, nhưng rất khó tìm được lời giải thích thực sự về nó là gì và hoạt động thế nào. Khi biết đó là các khóa được lưu trên security key thì thấy thất vọng. Ý tưởng tạo khóa tức thời dựa trên tên miền nghe hấp dẫn. Ưu điểm của Passkeys là không cần nhớ tên người dùng dùng trên website, nhưng đó chỉ là lợi ích nhỏ.
Câu trả lời cho một câu hỏi liên quan về tên gọi chính thức của công nghệ (dựa trên FIDO2? dựa trên WebAuthn?) tính toán và tái tạo khóa tức thời dựa trên tên miền có thể tìm thấy tại: https://fy.blackhats.net.au/blog/… Ở đó, khóa được tái tạo tức thời được gọi là "non-resident credential".