Cách cơn sốt Passkeys biến khóa bảo mật thành đồ vô dụng
(fy.blackhats.net.au)- Nếu xu hướng định nghĩa Passkeys là resident key rồi yêu cầu mặc định lan rộng, các khóa bảo mật như Yubikey, Feitian, Nitrokey sẽ nhanh chóng chạm giới hạn do không gian lưu trữ có hạn
- non-resident credential hoạt động theo cấu trúc trong đó khóa bảo mật giải mã credential ID do Relying Party cung cấp để lấy khóa riêng theo từng RP, nên bên trong thiết bị chỉ lưu master key
- Ngược lại, resident/discoverable credential lưu chính khóa riêng trên khóa bảo mật, nên mỗi tài khoản chiếm một slot; Nitrokey hỗ trợ 8 slot, còn Yubikey thường chỉ khoảng 20–32 slot
- Khóa bảo mật CTAP2.0 không thể xóa riêng từng resident key mà phải reset toàn bộ; khi đó master key cũng thay đổi, khiến cả non-resident key cũ cũng không còn hoạt động
- Nếu dịch vụ và thư viện mặc định yêu cầu resident key, người dùng có hơn 150 tài khoản sẽ phải quản lý nhiều khóa bảo mật cùng khóa dự phòng, làm giảm khả năng tự do chọn authenticator mong muốn
Vì sao resident key là tâm điểm của vấn đề
- Cốt lõi của lo ngại rằng kỳ vọng quá mức vào Passkeys có thể biến khóa bảo mật thành thiết bị lỗi thời nằm ở resident key
- Nhận thức rằng khóa bảo mật có thể hỗ trợ số lượng tài khoản gần như “không giới hạn” trong nhiều trường hợp dựa vào mô hình non-resident credential
- Resident key thực sự tiêu tốn không gian lưu trữ bên trong khóa bảo mật, nên khi số tài khoản tăng lên thì giới hạn thiết bị sẽ lộ ra ngay
Cách hoạt động của non-resident credential
- Trong non-resident credential, khi xác thực, Relying Party gửi credential ID tới khóa bảo mật thông qua trình duyệt
- Credential ID là một blob được mã hóa mà chỉ khóa bảo mật mới có thể giải mã, và kết quả giải mã là khóa riêng dành riêng cho Relying Party đó
- Khóa bảo mật dùng khóa riêng đã giải mã để ký challenge, rồi trả chữ ký về cho trình duyệt và Relying Party
- Trong cấu trúc này, khóa riêng không thường trú trong secure enclave, và bên trong khóa bảo mật chỉ có master key
- Credential ID được mã hóa bằng AES-128 và áp dụng HMAC, nên bị đánh giá là khó bị sửa đổi hay giải mã từ bên ngoài
- Có so sánh rằng nếu AES-128 bị phá để có thể giải mã khóa riêng mà không cần khóa bảo mật, thì TLS hay SSH cũng sẽ ở mức có thể bị tấn công tương tự
Khác biệt của resident/discoverable credential
- Resident key hoặc discoverable credential là cách mà khóa riêng được lưu bên trong khóa bảo mật
- Khi Relying Party gửi danh sách credential ID rỗng, khóa bảo mật sẽ tìm khóa có thể dùng cho RP đó, chọn một khóa rồi ký
- Cấu trúc này không phụ thuộc vào việc nhận credential ID từ bên ngoài rồi giải mã bằng master key
- Đổi lại, mỗi credential sẽ chiếm không gian bên trong khóa bảo mật, nên số slot resident key trở thành giới hạn thực tế của số lượng tài khoản
userVerification tách biệt với resident key
- Có sự nhầm lẫn rằng credential muốn ép buộc userVerification thì bắt buộc phải là resident, nhưng hai khái niệm này tách biệt nhau
- Khóa bảo mật không chỉ xác nhận presence bằng thao tác chạm, mà còn có thể xác minh PIN hoặc sinh trắc học bên trong để kiểm tra đó có thật sự là người dùng hay không
- Hành vi này được điều khiển bằng userVerification flag, và hoạt động độc lập với key residency
- Vì vậy, ngay cả khi không phải resident key, thiết bị vẫn có thể tự hoạt động như một yếu tố xác thực mạnh
Dung lượng lưu trữ và các ràng buộc của CTAP
- Vì resident key được lưu trong thiết bị, số slot của khóa bảo mật là yếu tố quan trọng
- Nitrokey hỗ trợ 8 resident key
- Yubikey thường hỗ trợ 20–32
- Một số khóa thậm chí không hỗ trợ resident key
- Chuẩn CTAP mà khóa bảo mật triển khai cũng ảnh hưởng lớn đến khả năng quản lý
- CTAP2.1 và CTAP2.1PRE có thể quản lý, cập nhật và xóa riêng từng resident key
- CTAP2.0 yêu cầu reset toàn bộ thiết bị nếu muốn xóa resident key
- Việc reset thiết bị CTAP2.0 cũng reset luôn master key, nên cả non-resident key cũ cũng sẽ không còn hoạt động
- Nhiều khóa bảo mật có khả năng đang dùng CTAP2.0; riêng với Yubico, phiên bản CTAP còn phụ thuộc vào phiên bản firmware
Tên gọi passkeys và sự lan rộng của định nghĩa resident key
- Năm 2022, Apple công bố tính năng passkeys trên macOS/iOS, dùng Touch ID và Face ID như một WebAuthn authenticator
- Tên gọi passkeys được xem là thân thiện với người dùng hơn so với “webauthn authenticator” hay “security key”
- Sau đó, khi ý nghĩa của passkeys chưa được cố định rõ ràng, đã xuất hiện nhiều cách hiểu khác nhau
- Thư viện Rust WebAuthn và các bên triển khai Relying Party định nghĩa passkeys là tên gọi cho mọi authenticator mà người dùng có thể chọn
- Một số thành viên cộng đồng gọi passkeys là credential được đồng bộ giữa nhiều thiết bị
- Tại hội nghị FIDO Authenticate, đã xuất hiện định nghĩa “passkey là resident key”, và sau đó FIDO cũng dùng định nghĩa này trong FAQ
- Một trong những lý do định nghĩa resident key được chú ý là vì nó gắn với tính năng sắp có của trình duyệt là conditional UI
- Nếu credential là resident key, có thể tự động điền tên người dùng và WebAuthn credential
- Điều này mang lại trải nghiệm không cần người dùng tự nhập tên người dùng
Các vấn đề người dùng do yêu cầu resident key tạo ra
- Nếu thư viện WebAuthn thúc đẩy mọi lượt đăng ký đều phải dùng resident key, các khóa bảo mật có dung lượng lưu trữ hạn chế sẽ đầy rất nhanh
- Ví dụ, nếu có hơn 150 mật khẩu được lưu trong trình quản lý mật khẩu, việc chuyển tất cả sang resident key sẽ cần ít nhất 5 Yubikey
- Nếu tính cả dự phòng, có thể phải quản lý 10–15 Yubikey
- Đây là trải nghiệm rất tệ với người dùng đã chọn khóa bảo mật, và yêu cầu resident key của passkeys có thể khiến chính việc dùng khóa bảo mật trở nên khó khăn
- Trong marketing cho khóa xác thực FIDO thường có các thông điệp như “unlimited key pair storage” hoặc “không giới hạn số tài khoản đăng ký”, nhưng điều đó chỉ đúng với non-resident key và xung đột với yêu cầu resident key
- Một trong những mục tiêu của WebAuthn Work Group là để người dùng có thể tự do chọn authenticator mình muốn mà không bị bất lợi, nhưng việc ép buộc resident key lại đi ngược mục tiêu này
- Các loại authenticator được nêu là có thể hoạt động đúng trong môi trường passkey gồm Apple passkeys, Android passkeys, trình quản lý mật khẩu hỗ trợ WebAuthn, Windows dùng TPM 2.0, và các trình duyệt nền Chromium trên macOS dùng Touch ID như TPM
Các hướng ứng phó khả thi
- Có phương án thay đổi hành vi rk=preferred để không tạo resident key trên khóa bảo mật
- Hiện tại, Relying Party có thể chỉ định mức yêu cầu resident key là
discouraged,preferred, hoặcrequired - Hiện tại
rk=preferredvẫn tạo resident key cả trên roaming authenticator như Yubikey, nên trên thực tế hoạt động gần giốngrk=required - Nếu nới
preferredthành “chỉ tạo resident key khi dung lượng lưu trữ là không giới hạn”, thì Android/iOS vẫn sẽ tạo resident key, còn dung lượng khóa bảo mật sẽ không bị tiêu tốn - WebAuthn WG hiện vẫn chưa ủng hộ thay đổi này, và nếu trình duyệt muốn tự triển khai riêng thì thực tế sẽ phụ thuộc vào quyết định của nhóm Chrome
- Hiện tại, Relying Party có thể chỉ định mức yêu cầu resident key là
- Một cách khác là yêu cầu thư viện passkey dùng rk=discouraged
rk=requiredcó thể loại bỏ khóa bảo mật khỏi lựa chọnrk=discouragedcó thể khiến người dùng Android không có được conditional UI- Nhưng vì tên người dùng vốn đã có các cách tự động điền khác, nên điều này vẫn tốt hơn việc loại bỏ khóa bảo mật
- Cũng có đề xuất yêu cầu FIDO coi dung lượng lưu resident key là một tiêu chí chứng nhận
- Hiện FIDO không bắt buộc mức dung lượng lưu trữ với thiết bị xác thực
- Nếu FIDO muốn thúc đẩy resident key, thì thiết bị được chứng nhận cần phải lưu được hàng nghìn resident key
Kết luận
- Xu hướng quá nhiệt khi xem passkeys là resident key có thể ngăn cản, hoặc khiến trở nên cực kỳ khó khăn, việc người dùng khóa bảo mật chọn authenticator mình muốn trên Internet
- Vấn đề không nằm ở bản thân passkeys, mà ở việc áp một cách đồng loạt yêu cầu resident key lên các khóa bảo mật có dung lượng lưu trữ và khả năng quản lý hạn chế
1 bình luận
Các ý kiến trên Hacker News
Hơi khác với chuyện mã hóa, nhưng mẹ tôi đã gọi điện trong trạng thái hoảng loạn vì không vào được Gmail. Hóa ra Google đã tự động đăng ký chiếc điện thoại Android mới làm passkey, rồi đổi nó thành phương thức đăng nhập mặc định, trong khi giao diện lại quá khó hiểu
Tôi nghĩ kỳ vọng người dùng phải bấm vào tùy chọn thứ hai để đăng nhập bằng mật khẩu, hoặc phải hiểu passkey là gì, là quá đáng. Họ nói “đã gửi passkey tới Android”, nhưng điện thoại không hề có thông báo, và nhìn suốt 30 phút vẫn không giải quyết được. Cũng không thể xóa passkey được tự động đăng ký, hay tắt luồng xác thực mặc định. UX của Google thật tệ hại, và việc tin cậy biến thể Android trên điện thoại Samsung giá rẻ làm nền tảng cho một hệ thống xác thực quy mô lớn trông như một quyết định ngu ngốc
Đây chỉ là một trong nhiều vấn đề gần đây tôi gặp với Google. Trước đây tôi chỉ lờ mờ tránh họ vì quyền riêng tư, còn giờ thì đang dốc toàn lực giảm tối đa việc dùng Google. Một doanh nghiệp của tôi bị gỡ khỏi Google Maps mà không có lý do, mất 2 tuần mới đăng ký lại được, và không thể nói chuyện với người thật. Mỗi email hỗ trợ đều đưa số điện thoại, nhưng đó là số hỗ trợ quảng cáo nên không làm được gì với tài khoản doanh nghiệp bị đình chỉ, và họ thậm chí còn không muốn tin rằng đội Google Business lại đưa số đó làm số hỗ trợ. Tôi phải lặp đi lặp lại câu hỏi suốt 30 phút mới khiến nhân viên hỗ trợ Google Ads thừa nhận rằng không có cách nào nói chuyện với người liên quan đến Google Business. Giờ thì tôi đã trở thành một người truyền giáo chống Google đúng nghĩa
Nếu điện thoại hết pin thì sao? Nếu bạn làm mất điện thoại và cần khôi phục thông tin đăng nhập dịch vụ định vị bằng cách gửi đặt lại mật khẩu qua email, nhưng lại không đăng nhập được email thì sao? Từ lúc đó quy trình “trả lời câu hỏi” bắt đầu. Một thuật toán ẩn danh vô trách nhiệm nào đó đánh giá ungoogled chromium trên Linux là đáng ngờ, và nếu bạn nhớ sai câu trả lời cho những câu kiểu “bạn đang dùng bao nhiêu phần trăm dung lượng lưu trữ hiện có?”, thì việc khôi phục quyền truy cập chỉ còn trông vào may mắn. Nói thêm là tôi là người dùng Google trả phí
Dù vậy tôi hoàn toàn hiểu ý chính. UX lẫn thuật ngữ đều gây rối. Ngay cả khi mỗi bước đều có giải thích, việc đó cũng không giúp được nhiều, vì mọi người đã được huấn luyện để bỏ qua các đoạn giải thích nhỏ và bấm nút to, màu mè nhất, nhất là khi đang vội. Đây thực sự là một bài toán rất khó trong thiết kế UX
Chừng nào người dùng chưa bỏ đi, Google sẽ không quan tâm, và cũng không cần quan tâm. Nếu muốn thứ khác, bạn cần một dịch vụ không do nhà quảng cáo trả tiền. Nếu Google bóc lột người dùng theo một cách, thì Apple chỉ bóc lột theo cách khác; chọn loại độc nào không phải là một lựa chọn
Vì Apple thực ra không định nghĩa rõ, những người thích suy luận đã lấp vào khoảng trống cho các người dùng muốn biết “rốt cuộc passkey là gì?”
Tôi vẫn hiểu rằng Apple đã định nghĩa passkey là một cặp khóa được đồng bộ qua iCloud Keychain. Trong bài trình bày WWDC 2021, họ cũng phân biệt passkey với khóa bảo mật vì passkey “luôn mang theo bên mình”, tức là nhờ đồng bộ giữa thiết bị, và “có thể khôi phục”. Về sau có vẻ định nghĩa này đã mở rộng sang các cách đồng bộ đám mây khác. Tôi cho rằng bài viết này đang đưa ra sự đánh đổi sai. Khóa bảo mật không quan trọng[1], vì chỉ có rất ít người dùng kỹ thuật và một số ít công ty thật sự coi trọng bảo mật dùng chúng. Muốn nâng cao an toàn trên web thì phải đưa mọi người rời khỏi mật khẩu, và 99% dân số sẽ không dùng khóa bảo mật trừ khi bị ép. Passkey có nhiều khả năng thay thế mật khẩu, đặc biệt nhờ tích hợp sâu vào hệ điều hành. Không nên tối ưu hóa xác thực theo hướng phục vụ nhóm dưới 1% người dùng bị thiếu slot khóa thường trú. [1] Tôi đang sở hữu 3 Yubikey, 3 khóa bảo mật Yubico và 1 SoloKey
Người dùng có thể chọn dùng nhà cung cấp passkey có khả năng sao lưu/khôi phục, và bên tin cậy sẽ nhận được tín hiệu đó. Dựa trên tín hiệu này, họ cũng có thể quyết định có nên đề xuất loại bỏ tùy chọn đăng nhập bằng mật khẩu hay không
Theo tiêu chuẩn FIDO, passkey thay thế mật khẩu, giúp người dùng đăng nhập vào website và ứng dụng trên nhiều thiết bị của mình nhanh hơn, dễ hơn và an toàn hơn. Khác với mật khẩu, passkey luôn mạnh và chống phishing. https://fidoalliance.org/passkeys/
Không hiểu vì sao
rk=requiredlại tồn tại. Ngay từ đầu nó không nên là một tùy chọnChính vì những chuyện như thế này mà tôi vẫn luôn lo ngại và hoài nghi về passkey cùng những bên liên quan. Họ có trách nhiệm thiết kế giao thức sao cho nó không trở thành công cụ thuận tiện cho đủ loại thực tiễn thị trường ác ý của các tập đoàn lớn như Microsoft, vốn có thể làm hỏng nghiêm trọng bảo mật và khả năng tương thích, đồng thời bóp chết cạnh tranh. Thế nhưng thái độ họ liên tục thể hiện trong các bài viết và bài đăng lại gần như là “kệ các người, chúng tôi sẽ làm cho việc lạm dụng dễ hơn”. Đây không chỉ là vấn đề của resident key; chẳng hạn cách xử lý attestation cũng có thể dễ dàng bị lạm dụng để giết chết các công ty
Nếu một dịch vụ đặt
rk=requiredmà nền tảng không muốn bật, không muốn hỗ trợ hoặc không thể hỗ trợ, thì quy trình có vẻ sẽ luôn thất bại, thậm chí không đăng ký được. Nếu mục tiêu là onboarding người dùng và phát triển kinh doanh, đó có vẻ là tự bắn vào chân mìnhTôi hoàn toàn không phải người làm về bảo mật hay mật mã nên bài này rất khó theo dõi, và tôi nghĩ những người khác cũng vậy
Với người có đủ kiến thức nền thì có thể đây là những câu hỏi kỳ lạ, nhưng cứ một hai câu là tôi lại bị khựng. Tôi không hiểu “cuối cùng quy về một thứ, resident key” là như thế nào và vì sao, cũng không hiểu liên hệ với passkey hay HSM. Câu “cần hiểu discoverable/resident key là gì” khá mơ hồ: nó có nghĩa mọi resident key đều là discoverable key, hay mọi discoverable key đều là resident key, hay cả hai? Câu “hẳn bạn đã thấy phần lớn key hỗ trợ số tài khoản ‘không giới hạn’” thì không rõ key ở đây là passkey, key lưu trong HSM, hay cả hai. Câu “gửi key được bọc bằng key tới security key” cũng làm tôi bối rối: có phải ý là HSM có thể áp dụng cho số tài khoản không giới hạn vì nó có thể bọc và lưu một key bằng một key khác không
Điện thoại có thể lưu 10.000 passkey mà không vấn đề gì, nhưng một hardware key hiện đại có thể chỉ lưu tổng cộng 25 passkey trong phần flash khả dụng. Lý do cần dung lượng này là khả năng discoverable. Ví dụ, trên trang đăng nhập GitHub.com, nếu bấm hỗ trợ passkey mới thì có thể đăng nhập mà thậm chí không cần nhập tên tài khoản. Trình duyệt cung cấp trải nghiệm giống trình quản lý mật khẩu, và passkey cũng trở thành bản ghi cục bộ của tài khoản trên trang, giống như mật khẩu trong trình quản lý mật khẩu. Nhưng WebAuthn còn có nhiều chế độ không phải passkey. Credential không discoverable cần được cung cấp danh sách handle cho một tài khoản người dùng cụ thể, và các handle này là thứ key đã cung cấp khi đăng ký. Khi xác thực, chỉ những credential khớp với handle mới được đưa ra làm lựa chọn. Hardware security key tận dụng điểm này để lưu ngay trong handle bản ghi cần thiết cho các phép toán mật mã sau này, và chế độ này không dùng dung lượng flash. Khi người dùng nhập tên người dùng, một API nào đó trả về danh sách handle, rồi áp dụng danh sách đó lên security key để xác thực mà không bị giới hạn dung lượng lưu trữ. Tuy nhiên nhiều trang có chính sách không tiết lộ liệu tài khoản có tồn tại hay không. Ta từng thấy các quy trình khôi phục kiểu “nếu tài khoản này tồn tại, bạn sẽ sớm nhận được email”. Việc quy trình đăng nhập cung cấp API cho biết có tài khoản gắn với tên người dùng hoặc email hay không, và đã ghi nhận bao nhiêu credential, có thể là điều khó chấp nhận đối với các trang. Rốt cuộc, thay vì các trang áp dụng rộng rãi quy trình này và tác động tới giới hạn phần cứng hiện nay, có vẻ khả năng cao hơn là sẽ xuất hiện security key có dung lượng lưu trữ lớn gấp 10 lần
rk=requiredtrong giao thức WebAuthN là có hại. Lý do là nhiều phần cứng TPM vì thế không thể hoạt động như ví/cơ sở dữ liệu passkeyPhần lớn bình luận có lẽ sẽ đồng ý với điểm này. Nhưng điều đó không biện minh cho sự rối rắm mà tác giả tạo ra khi dành nửa bài để tranh luận định nghĩa passkey
Passkey được triển khai trên FIDO2, đặc biệt tận dụng chức năng resident key trong đặc tả FIDO2. Thiết bị xác thực phần cứng FIDO2 không chính xác là HSM nhưng tương tự, và cũng có thiết bị vừa là HSM vừa là thiết bị xác thực FIDO2 như Yubikey. Trong FIDO2, “resident key” và “discoverable key” là từ đồng nghĩa. Đặc tả dùng “resident key”, nhưng “discoverable key” cũng thường được dùng, và đây là một trong những thuật ngữ gây rối mà FIDO tạo ra. “Key” không chỉ passkey hay key lưu trong HSM, mà chỉ thiết bị xác thực phần cứng FIDO2 như Yubikey, thường được gọi là “security key”. Thiết bị xác thực phần cứng FIDO2, miễn là không dùng resident key, về thực chất là không có trạng thái và không lưu gì, nên có thể được đăng ký với số tài khoản không giới hạn. Khi đăng ký vào tài khoản, thiết bị tạo một cặp khóa như EdDSA nhưng không lưu lại, mà mã hóa khóa riêng bằng khóa chủ tích hợp, ví dụ khóa AES256. Sau đó nó gửi khóa công khai dạng rõ và khóa riêng đã mã hóa cho relying party như google.com để lưu trữ. Khi xác thực, khóa riêng đã mã hóa, tức key “được bọc”, được truyền tới thiết bị xác thực, được giải mã bên trong thiết bị rồi dùng để tạo chữ ký số. Tuy nhiên FIDO2 không thực sự quy định cách triển khai non-resident key; wrapped key chỉ là một phương pháp. FIDO2 chỉ yêu cầu khóa riêng phải có thể được dẫn xuất an toàn từ credential ID, còn credential ID là dữ liệu tùy ý, có thể là wrapped key hoặc không
Có vẻ như đang nhìn nhận tình hình quá khắt khe. Nếu muốn hưởng lợi từ một chuẩn xác thực mới giúp loại bỏ mật khẩu yếu và việc tái sử dụng mật khẩu, qua đó ngăn 99% các vụ xâm phạm tài khoản hằng ngày, cũng có thể xem là bạn cần bỏ Yubikey đời cũ đã cầm cự từ năm 2013 và chi 30 đô la để nâng cấp
Không rõ mẫu Bio FIDO thì thế nào, nhưng nếu cũng tương tự thì YubiCo có thể không có sản phẩm nào phù hợp với số lượng lớn khóa resident. Sửa: Bio cũng có cùng giới hạn 25 cái
Khóa resident được chia sẻ không nên tồn tại, ngoại trừ sử dụng tạm thời ngắn hạn. Nó là gánh nặng trách nhiệm, là rủi ro bảo mật và khuyến khích các thực hành bảo mật xấu. Ví dụ điển hình nhất là TOTP, vốn có nhiều khiếm khuyết từ góc độ bảo mật. Ta không nên muốn chia sẻ hoặc sao lưu bí mật dùng chung sang nhiều thiết bị, nhưng vì điều đó có thể làm được, cộng với các triển khai xác thực 2 bước lỏng lẻo đã trở thành chuẩn mực thay vì ngoại lệ, nên trên thực tế người dùng bị buộc phải làm vậy. Nhìn xu hướng hiện nay, passkey có vẻ cũng sẽ đi theo cùng hướng đầy khiếm khuyết và thù địch với người dùng
Xác thực dựa trên “thứ bạn có nhưng cũng có thể làm mất” về cơ bản là hỏng. Nếu mất thiết bị thì bạn mất quyền truy cập, hoặc nếu không thì điểm yếu nhất phải nằm ở chỗ khác, khiến mức bảo mật vượt trội đó trở nên vô nghĩa
Kết quả rồi sẽ chứng minh, nhưng nếu passkey được chấp nhận rộng rãi, tôi nghĩ với đa số người dùng, việc bị khóa tài khoản sẽ ít phổ biến hơn chứ không phải nhiều hơn
Tôi thắc mắc vì sao dung lượng lưu trữ của khóa phần cứng lại bị giới hạn đến vậy. Sẽ tốn thêm bao nhiêu chi phí để đưa vào trong khóa một thiết bị lưu trữ dung lượng lớn mà bộ xử lý bảo mật có thể truy cập
Thiết bị lưu trữ dung lượng lớn này tất nhiên sẽ được bộ xử lý bảo mật mã hóa mạnh, và khi mọi thứ bị xóa thì khóa đó cũng bị xóa theo là được
Từ góc độ bảo mật, thậm chí có thể nói khóa bảo mật tốt nhất là khóa bảo mật có dung lượng lưu trữ bằng 0. Các giao thức không dẫn xuất token bảo mật từ bí mật dùng chung mà tiêm và lưu chúng vào khóa bảo mật, vùng bảo mật, v.v. nhìn chung từng có những khiếm khuyết nghiêm trọng. Đôi khi là khiếm khuyết bảo mật mang tính nền tảng như TOTP, đôi khi là khiếm khuyết về độ phức tạp. Tương tự, bạn tuyệt đối không nên muốn chia sẻ khóa bảo mật dùng cho HSK/xác thực 2 bước trên nhiều thiết bị. Điều đó có nghĩa là nếu một thiết bị bị lộ thì tất cả đều hỏng. Thay vào đó, mỗi thiết bị nên có một khóa riêng, và với nhà cung cấp đăng nhập hoặc phía máy chủ, phần overhead này trong bức tranh tổng thể là không đáng kể
Dung lượng lưu trữ nhỏ cũng có ưu điểm là dễ kiểm toán hơn một chút. Tất nhiên theo tiêu chuẩn ngày nay, ngay cả kích thước nhỏ đó cũng có thể đã đẩy sát giới hạn có thể kiểm toán thực tế
Nhìn vào TPM, mỗi lần ký thứ gì đó, đầu vào là dữ liệu cần ký và khóa riêng đã được niêm phong. Khóa đã niêm phong là khóa riêng do TPM tạo ra, được mã hóa đối xứng bằng khóa tích hợp trong TPM. Khóa đã niêm phong này được lưu trong thiết bị lưu trữ dung lượng lớn và được cung cấp cho TPM trong mỗi thao tác ký. Nhờ thiết kế này, bạn có thể có nhiều khóa đến mức thiết bị lưu trữ dung lượng lớn cho phép
Khi cắm khóa bảo mật vào khe, USB nhớ cung cấp dung lượng lưu trữ cho khóa bảo mật và trước máy tính thì nó trông như một khóa bảo mật. Khi không cắm khóa bảo mật, nó hoạt động như USB nhớ thông thường. Bình thường cứ cắm sẵn khóa bảo mật, khi cần thêm dung lượng thì mua mô-đun lưu trữ lớn hơn, rút khóa bảo mật khỏi mô-đun cũ, cắm mô-đun cũ vào máy tính để sao chép các tệp đã mã hóa sang mô-đun mới, rồi cắm lại khóa bảo mật là được
Ngay từ đầu tôi cũng không chắc việc dùng khóa bảo mật vật lý làm passkey có phải ý hay không. Passkey được thiết kế như thứ thay thế mật khẩu, và để làm được vậy, có vẻ cần thuộc tính 2 yếu tố mà điện thoại hoặc máy tính để bàn cung cấp: ngoài “thứ bạn có”, còn yêu cầu “thứ bạn biết” hoặc “chính bạn” để mở khóa
Tôi nghĩ khóa bảo mật vật lý nên được giữ lại như xác thực 2 bước dùng thêm bên cạnh passkey trong các ngữ cảnh cần bảo mật cao nhất định. Đặc biệt là khi khả năng chống sao chép là chức năng cốt lõi. Với mục đích đó, khi đã tới bước thứ hai thì ta đã biết tài khoản đang muốn đăng nhập, nên không cần khóa thường trú. Ngoài ra, tôi nghĩ chức năng tự động điền mà khóa thường trú cung cấp là quan trọng với UX của passkey. Hy sinh nó chỉ để duy trì tương thích ngược với một số ít khóa mà chỉ dân mê bảo mật dùng thì không hợp lý. Tất nhiên nếu có cách giữ UX đó mà không cần khóa thường trú thì ổn
Tin rằng trình quản lý mật khẩu mình chọn an toàn hơn thì dễ hơn là giả định mọi dịch vụ trên đời cho phép tạo tài khoản đều an toàn hoặc không thể bị phishing. Vì vậy, tới lúc dùng passkey, ta thường đã ở trong một ngữ cảnh an toàn hơn, nơi danh tính đã được thiết lập với hệ điều hành hoặc trình quản lý mật khẩu sở hữu passkey, v.v. Ngoài ra, những nơi hiện nay hoặc cho tới gần đây vẫn chưa hỗ trợ khóa phần cứng thì rất có khả năng cũng sẽ không hỗ trợ trong tương lai gần. Ngược lại, giải pháp passkey dễ triển khai hơn nhiều vì chi phí áp dụng chỉ ở mức hỗ trợ phần mềm, nên khả năng hiệu quả trên đầu tư cao hơn. Tất nhiên chuyện này chủ yếu áp dụng cho website, và passkey gần giống “khóa SSH được chuẩn hóa” cho website. Khóa phần cứng có vẻ hữu ích hơn như yếu tố bước 2 để thực sự mở két chứa passkey, và lúc đó cũng có thể cần mật khẩu đi kèm. Có lẽ vòng đời của khóa phần cứng vẫn còn một thời gian nữa. Khi thử dùng làm phương thức mặc định trên GitHub, Gmail, v.v., luồng đăng nhập bằng passkey thật sự rất tốt
Trình duyệt chỉ cần có một HATEOAS API đơn giản để trình quản lý mật khẩu có thể kết nối, còn web app chỉ cần phơi ra HTML kích hoạt trình duyệt. Khi đó trình quản lý mật khẩu sẽ quyết định cách xác thực người dùng, tức là cách người dùng muốn, rồi tự động chèn giá trị bí mật của website đó để người dùng được đăng nhập tự động. Nếu có vấn đề thì dùng đặt lại qua email. Tôi hiểu rằng từ phía các website muốn “bảo mật thật hào nhoáng” thì họ sẽ muốn thứ gì đó phức tạp hơn. Nhưng người dùng phải có thể tùy chọn bật mức bảo mật cao hơn. Ví dụ, với hầu hết website, nếu giả định trình quản lý mật khẩu dùng mật khẩu ngẫu nhiên thì băm mật khẩu đơn giản là đủ. Bất kỳ website nào cũng có thể triển khai, mọi trình quản lý mật khẩu đều có thể triển khai, và nó tốt hơn cách 99% người dùng phổ thông đang dùng mật khẩu hiện nay. Cứ lấy đó làm phương thức xác thực mặc định. Sau đó nếu muốn TOTP, OIDC, mã hóa khóa công khai, v.v. thì máy chủ quảng bá và client tùy chọn tham gia để tiếp tục xác thực. Không cần mọi site và mọi người dùng đều dùng phương pháp an toàn nhất. Trước hết hãy làm cho việc nâng đường cơ sở bảo mật trở nên dễ dàng, rồi để bảo mật mạnh hơn được chọn dần dần
Nếu ai đó đánh cắp token phần cứng của tôi thì cũng không có vẻ là vấn đề lớn. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
Khi dùng mật khẩu, giao diện xác thực là bàn phím, và không có bảo đảm thực sự rằng người gõ mật khẩu chính là người họ tự nhận. Mật khẩu dựa vào tri thức có thể truyền đạt dễ dàng, nên có thể bị trích xuất theo nhiều cách. Chuyển giao diện xác thực sang thiết bị với thiết bị thì tốt hơn nhiều. Thay vì giả định rằng tri thức dễ truyền đạt đã không bị truyền đi, ta giả định rằng thực thể sinh học có thể quản lý thiết bị xác thực, mà con người vốn khá giỏi những việc như vậy. Cũng có thể tăng số kênh xác thực để làm nó vững chắc hơn, và có thể giới hạn việc xác thực giữa thực thể sinh học với thiết bị sẽ dùng để xác thực hệ thống từ xa, như FaceID. Về cốt lõi, việc giả định rằng một thiết bị như điện thoại hay khóa chính là người đó có vẻ tự nhiên. Ở nhà, chúng tôi không chỉ chia sẻ mật khẩu Netflix mà còn chia sẻ cả một thẻ tín dụng. Vì lý do thực dụng, chúng tôi để một thẻ tín dụng cùng chìa khóa dự phòng, ai cần mua đồ cho nhà thì cứ lấy dùng. Chúng tôi tin nhau sẽ dùng thẻ đúng cách, mọi người đều biết PIN nhưng thanh toán không tiếp xúc phổ biến nên hầu như không cần đến. Việc đó tự nhiên hơn nhiều so với theo dõi chi phí rồi sau này quyết toán với nhau. Có lẽ việc này là bất hợp pháp, và nếu ngân hàng biết thì họ sẽ hủy thẻ, nhưng là vậy. Hệ thống IT rất cần vận hành theo cách tương tự thế giới thực và tiến gần hơn tới hành vi của con người. Vì tôi làm việc với hệ thống IT nên phần lớn còn chịu được, nhưng những người không quen công nghệ thì gặp khó ngay cả với các vấn đề thường ngày như mật khẩu iPhone là gì, mật khẩu iCloud là gì, mật khẩu Gmail là gì, tại sao phải nhập mã vào WhatsApp. Thật ra chính tôi cũng không hiểu Mastadon. Tôi nghĩ mình sẽ hoàn toàn không phòng bị trước phishing trên Mastadon, và màn hình bảo nhập gì thì chắc tôi sẽ nhập cái đó
Passkey, đúng như tên gọi, bám vào tiêu chuẩn FIDO2 U2F vốn được phát triển như một yếu tố thứ hai. Khóa thường trú là để xác thực hai bước ngay trên thiết bị kèm PIN, và là phương án thay thế về mặt chức năng cho smartcard. Có ai đó, có lẽ là Apple, dường như đã nghĩ rằng chỉ riêng WebAuthn cũng đủ để trở thành yếu tố xác thực duy nhất. Không có khóa thường trú, không có ràng buộc phần cứng, khóa thì di chuyển qua iCloud, nhưng trên thiết bị lại được bảo vệ bằng TouchID/FaceID — đại loại như vậy. Và họ đã gắn thương hiệu cho nó là passkey. Bản thân xác thực hai bước không phải là mục tiêu. Mục tiêu là xác thực người dùng an toàn trước phishing, brute-force và tấn công nhồi thông tin đăng nhập, nhưng không khó triển khai như smartcard. FIDO2 làm được điều đó. Vấn đề với các triển khai của Apple, Google, Microsoft không phải là bảo mật ở cấp giao thức giữa website xác thực và thiết bị người dùng thấp hơn. Giao thức đó vẫn giống nhau. Vấn đề là giờ đây website phải tin vào tài khoản nền tảng cá nhân của người dùng, tin rằng người dùng đã thiết lập đúng, và tin rằng nền tảng sẽ luôn hành xử đúng trong tương lai để xử lý thỏa đáng các cuộc tấn công nhắm vào tài khoản cá nhân của người dùng.
Bổ sung thêm bối cảnh: tôi đang điều hành một công ty xác thực không mật khẩu được YC hậu thuẫn và đã triển khai nó cho các tổ chức lớn. Có vẻ rõ ràng rằng passkey sẽ là câu trả lời cho xác thực không mật khẩu dành cho người tiêu dùng, nhưng điều đó dường như vẫn chưa được phản ánh trong môi trường doanh nghiệp
Passkey rất tuyệt cho người tiêu dùng. Lý do là chúng nhằm cho phép người dùng tự tạo quyền truy cập khẩn cấp bằng cách sao lưu thông tin xác thực sang các thiết bị khác, theo cách như sao lưu mặc định của iCloud hoặc AirDrop. Về mặt kỹ thuật, các thiết bị được chia sẻ thông tin xác thực này không thể cung cấp attestation. Attestation là “bằng chứng” rằng cặp khóa đã được tạo trên một thiết bị cụ thể như Yubikey hoặc thiết bị Apple. Các nhà sản xuất như Yubico xuất xưởng khóa với cặp khóa/chứng chỉ không thể trích xuất được nhúng sẵn trong khóa; vì không có giao diện bên ngoài nào để truy cập cặp khóa này, quản trị viên có thể có mức độ tin cậy cao rằng đó là Yubikey thật. Khi không có attestation và khóa có thể được chia sẻ, có thể thấy vấn đề bắt đầu từ đâu. Doanh nghiệp không muốn gánh rủi ro rằng thông tin xác thực có thể AirDrop sẽ làm lộ quyền truy cập vào tài khoản nhân viên đặc quyền. Với Yubikey, nguy cơ bị đánh cắp kỹ thuật số gần như không tồn tại. Rốt cuộc, passkey cũng không thể dùng để mở khóa thiết bị hoặc máy chủ. FIDO2, và quan trọng hơn là các nhà phát triển hệ điều hành, vẫn còn một chặng đường dài nếu muốn chấm dứt hoàn toàn mật khẩu. Hiện tại, trong phần lớn thị trường doanh nghiệp, Yubikey đang lấp khoảng trống này, và một số nơi đã chi hàng triệu đô la cho phần cứng. Passkey ở trạng thái hiện nay sẽ rất khó bán
Apple hỗ trợ passkey, Android và Chrome cũng vậy, Microsoft cũng vậy, và Yubikey cũng hỗ trợ passkey. Nhưng các tính năng và ràng buộc như quy trình xác thực để xác minh người dùng và khả năng sao chép có thể rất khác nhau. Cơ quan chính phủ có thể hỗ trợ passkey, nhưng chỉ cho phép khi chúng được cung cấp bởi thiết bị xác thực được chứng nhận FIPS đáp ứng yêu cầu AAL2. Ít nhất hiện tại, đó không phải là thứ đến từ Apple hay Google. Doanh nghiệp có thể chọn hỗ trợ passkey được tạo bằng phần mềm/cấu hình do sản phẩm quản lý MDM cung cấp, và Apple đã công bố hỗ trợ beta cho việc này. Tuy nhiên, trong các dịch vụ chính phủ dành cho công dân, nếu cố bắt buộc một thiết bị xác thực phần cứng cụ thể thì có thể sẽ gặp rất nhiều khó khăn. Bởi vì khó thuyết phục công dân mua phần cứng giá trên 80 đô la, và công nghệ web được xây dựng xoay quanh lựa chọn của người dùng, nên WebAuthn API và trải nghiệm người dùng cũng khó có khả năng được tối ưu theo hướng hỗ trợ hạn chế lựa chọn của người dùng
Từ góc độ bảo mật, tôi thấy đây là một giải pháp thật sự tệ hại
Đây là một cấu trúc như trong mơ để chính phủ và các công ty như Apple, Google kiểm soát đời sống số. Khi dùng mật khẩu, nó gần như là một dạng phi trạng thái: ngay cả khi bạn băng qua biên giới với tài khoản email cá nhân hoặc tài khoản nào đó, không ai có thể biết bạn sở hữu tài khoản đó, và họ khó có thể ép bạn giao quyền truy cập, trích xuất yếu tố truy cập từ phần cứng, hoặc khóa bạn vì mất quyền truy cập thiết bị. Dù khóa chính hay các thứ tương tự được lưu trong TPM hoặc phần tử bảo mật, một số chính phủ vẫn có thể truy cập được, nên chỉ còn là vấn đề vài năm và năng lực tính toán. Trong hầu hết trường hợp, bản thân điều đó cũng là bằng chứng rằng bạn có thông tin xác thực của một tài khoản cụ thể. Nhà sản xuất thiết bị hoặc hệ điều hành có thể dễ dàng bị chính quyền ép cung cấp quyền truy cập vào vùng bảo mật, dù tự nguyện hay không