Khám phá cách passkey tận dụng mã QR và Bluetooth để xác thực đa nền tảng, mang lại trải nghiệm đăng nhập liền mạch, an toàn trên các thiết bị mà không cần mật khẩu.
Vincent
Created: July 1, 2025
Updated: July 6, 2025
Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.
Passkey đang ngày càng thay thế mật khẩu để trở thành tiêu chuẩn thực tế trong việc xác thực người dùng. Không giống như mật khẩu truyền thống, passkey được liên kết với một hệ sinh thái (ví dụ: iCloud Keychain, Google Password Manager, Windows Hello hoặc một trình quản lý mật khẩu như 1Password hoặc Dashlane); chúng không được thiết kế để ghi nhớ mà được xây dựng để tích hợp liền mạch với các thiết bị của bạn, mang lại trải nghiệm người dùng tuyệt vời ngay từ khi sử dụng.
Hãy tưởng tượng bạn đang ở xa máy tính cá nhân của mình, có thể là tại một máy tính công cộng hoặc laptop của bạn bè, và bạn cần đăng nhập vào tài khoản được bảo vệ bằng passkey. Tình huống này khá phổ biến và đòi hỏi một phương thức xác thực vừa an toàn vừa tiện lợi, nhưng với passkey, nhiều người không biết phải làm gì vì passkey của họ không có sẵn ngay lập tức trong tình huống này. Một trong những tính năng của passkey giúp bạn trong tình huống như vậy là khả năng sử dụng passkey của mình trên nhiều thiết bị thông qua việc hỗ trợ của mã QR và công nghệ Bluetooth. Quá trình này được gọi chính thức là vận chuyển lai (hybrid transport) trong đặc tả WebAuthn (trong các phiên bản trước của đặc tả, nó được gọi là Bluetooth Năng lượng Thấp được hỗ trợ bởi đám mây - caBLE).
Quá trình này rất đơn giản: bạn cần một thiết bị đã lưu trữ passkey của mình và có khả năng chụp ảnh, vì vậy rất có thể đó là một chiếc điện thoại thông minh hoặc máy tính bảng. Thiết bị này có thể mở một đường hầm đến thiết bị mới chỉ cho một lần xác thực đó. Điều này không chỉ duy trì tính toàn vẹn của passkey mà còn đảm bảo rằng quyền truy cập vào tài khoản của bạn trên các thiết bị mới có thể được cấp, bất kể bạn đang ở đâu hay muốn sử dụng thiết bị của ai để đăng nhập.
Tuy nhiên, tính năng xác thực đa nền tảng này của passkey lại bị bao quanh bởi những quan niệm sai lầm và sự nhầm lẫn cả về tiện ích lẫn cách triển khai kỹ thuật. Đây là điều tôi nhận thấy gần đây một lần nữa khi tham dự một buổi gặp mặt về an ninh CNTT tại địa phương. Qua bài viết này, chúng tôi mong muốn làm sáng tỏ những phức tạp và cung cấp các khuyến nghị để triển khai luồng xác thực passkey đa nền tảng (vận chuyển lai) này, đảm bảo bạn có thể cung cấp trải nghiệm đăng nhập tốt nhất cho người dùng của mình.
Recent Articles
Passkey là một hình thức xác thực người dùng thay thế mật khẩu truyền thống bằng một cặp khóa công khai-riêng tư mật mã hóa an toàn và tiện lợi hơn. Cặp khóa này là duy nhất cho mỗi người dùng và được sử dụng để xác minh danh tính mà không cần phải nhớ các mật khẩu phức tạp.
Ưu điểm của passkey là rất nhiều so với mật khẩu tiền nhiệm. Chúng giảm đáng kể nguy cơ bị lừa đảo (phishing), vì chúng không thể bị lừa để chia sẻ với một trang web giả mạo. Hơn nữa, chúng miễn nhiễm với các cuộc tấn công brute force và tấn công từ điển, là những phương pháp phổ biến được sử dụng để bẻ khóa mật khẩu. Passkey cũng thân thiện với người dùng hơn, loại bỏ nhu cầu phải nhớ hoặc quản lý một danh sách dài các mật khẩu.
Passkey được đồng bộ hóa trong các tài khoản đám mây, như những tài khoản được quản lý bởi Google Password Manager hoặc Apple iCloud Keychain (Microsoft với Windows Hello sẽ sớm theo sau), hoặc những tài khoản được lưu trữ trong các trình quản lý mật khẩu hiện đại sẵn sàng cho passkey, như 1Password hoặc Dashlane. Tuy nhiên, điều cần thiết là phải biết rằng theo mặc định, passkey được liên kết với hệ sinh thái và việc đồng bộ hóa tài khoản đám mây tương ứng. Các hệ điều hành không cung cấp giao diện để xuất khóa riêng tư và trên hầu hết các thiết bị, có một thành phần phần cứng cung cấp các biện pháp bảo mật bổ sung để tránh mọi truy cập vào khóa riêng tư, ví dụ: Secure Enclave trên các thiết bị iOS hoặc Trusted Platform Module (TPM) trên các thiết bị Windows. Chỉ nhà cung cấp hệ điều hành mới có thể đồng bộ hóa passkey đến các thiết bị khác một cách mã hóa (cuối cùng được bảo vệ bởi sinh trắc học, mật mã hoặc mã PIN của người dùng). Khóa riêng tư chỉ có thể được khôi phục và giải mã bằng mật mã / mã PIN và sẽ bị hủy trong trường hợp có quá nhiều lần đăng nhập không thành công vào tài khoản đám mây (ví dụ: Apple giới thiệu giới hạn tốc độ để ngăn chặn các cuộc tấn công brute-force ngay cả từ một vị trí có đặc quyền trên backend đám mây; Google cũng làm tương tự).
Thiết kế vốn có này có nghĩa là nếu passkey không được đồng bộ hóa như mô tả, việc truy cập passkey của bạn trên một thiết bị mới có thể là một thách thức. Đây chính là lý do tại sao phương thức vận chuyển lai để xác thực passkey đa nền tảng (vận chuyển lai) với mã QR và kiểm tra sự gần gũi bằng Bluetooth tồn tại. Nó cung cấp một cầu nối an toàn cho passkey của bạn giữa các thiết bị mà không cần phải đồng bộ hóa chúng thông qua tài khoản đám mây / trình quản lý mật khẩu, do đó duy trì nguyên tắc rằng passkey có thể chỉ thuộc về người dùng.
Sử dụng xác thực passkey đa nền tảng (vận chuyển lai) giúp khắc phục các vấn đề giữa các thiết bị, khi một tài khoản được truy cập hoàn toàn qua passkey. Vì không phải tất cả các passkey đều được đồng bộ hóa trong tài khoản đám mây hoặc trình quản lý mật khẩu, sự cần thiết của một phương pháp đáng tin cậy để truy cập passkey trên các thiết bị trở nên quan trọng, đặc biệt là khi chuyển sang một thiết bị mới hoặc cần truy cập trên một thiết bị dùng chung.
Để tạo điều kiện cho việc xác thực passkey đa nền tảng (vận chuyển lai), có các yêu cầu về phần cứng sau:
Ben Gould
Head of Engineering
I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.
Hơn 10.000 nhà phát triển tin tưởng Corbado và làm cho Internet an toàn hơn với passkey. Có câu hỏi? Chúng tôi đã viết hơn 150 bài blog về passkey.
Tham gia Cộng đồng PasskeysTừ quan điểm phần mềm, có các yêu cầu sau:
Nguồn: passkeys.dev
Quá trình sử dụng xác thực passkey đa nền tảng (vận chuyển lai) qua mã QR trông như sau:
Mã QR để xác thực passkey đa nền tảng (vận chuyển lai) được tạo ra khi người dùng cố gắng truy cập một dịch vụ trên một thiết bị không có passkey đã đăng ký, nhưng dịch vụ biết rằng người dùng nên có một passkey. Thông thường, một nút Quét mã QR hoặc một lời kêu gọi hành động tương tự được cung cấp trong giao diện xác thực.
Theo yêu cầu của người dùng, thiết bị sẽ bắt đầu tạo mã QR. Mã QR này mã hóa một định danh phiên duy nhất, có giới hạn thời gian. Định danh này được gắn với một phiên mà máy chủ xác thực tạm thời duy trì, chờ đợi quá trình xác thực hoàn tất.
Người dùng quét mã QR này bằng một thiết bị có sẵn passkey của họ. Các biện pháp bảo mật bao gồm:
Mã QR được quét chứa một URI cụ thể với lược đồ FIDO, ví dụ: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332
Việc quét mã QR kích hoạt thiết bị thứ hai của người dùng (ví dụ: điện thoại thông minh hoặc máy tính bảng) để diễn giải URI FIDO và giao tiếp với máy chủ xác thực, gửi một tín hiệu rằng người dùng đang cố gắng xác thực qua một thiết bị mới (ví dụ: laptop của bạn bè). Hành động này nhắc máy chủ tạo ra một thử thách mật mã, duy nhất cho lần xác thực này.
Thử thách được gửi lại cho thiết bị thứ hai của người dùng (ví dụ: điện thoại thông minh hoặc máy tính bảng), nơi lưu trữ passkey của họ. Thiết bị sau đó tạo ra một chữ ký số bằng cách sử dụng khóa riêng tư được liên kết với passkey, mà không bao giờ để khóa riêng tư rời khỏi thiết bị (ví dụ: điện thoại thông minh hoặc máy tính bảng). Thử thách đã ký (chữ ký) sau đó được gửi lại cho máy chủ thông qua một đường hầm được mã hóa, an toàn qua internet, xác minh tính toàn vẹn và nguồn gốc của nỗ lực xác thực.
Máy chủ xác thực chữ ký bằng cách sử dụng khóa công khai tương ứng đã được liên kết với tài khoản của người dùng. Sau khi xác thực thành công, máy chủ xác nhận việc xác thực, cho phép người dùng truy cập dịch vụ trên thiết bị mới.
Một số khía cạnh quan trọng về quyền riêng tư và bảo mật cần xem xét:
Bằng cách tuân thủ các giao thức kỹ thuật và bảo mật này, phương pháp mã QR để xác thực passkey đa nền tảng (vận chuyển lai) duy trì một tiêu chuẩn bảo mật cao đồng thời cung cấp một cách thuận tiện cho người dùng để xác thực danh tính của họ trên các thiết bị mới.
Bên cạnh quá trình quét mã QR, còn có việc kiểm tra sự gần gũi qua Bluetooth (caBLE). Việc đảm bảo rằng client và trình xác thực ở gần nhau về mặt vật lý là một trong những lợi ích chính của giao thức WebAuthn. Thông tin chi tiết hơn về hoạt động bên trong của quá trình này được mô tả sau đây:
Bluetooth Năng lượng Thấp (BLE) là một công nghệ giao tiếp không dây được thiết kế để trao đổi dữ liệu trong phạm vi ngắn. Nó đóng một vai trò quan trọng trong việc xác nhận sự gần gũi vật lý của các thiết bị trong quá trình xác thực.
caBLE là một giao thức tạo điều kiện cho việc chuyển giao thông tin xác thực an toàn giữa các thiết bị bằng BLE. Khi sử dụng caBLE để xác thực passkey đa nền tảng (vận chuyển lai), thiết bị giữ passkey sẽ xác nhận sự gần gũi của thiết bị yêu cầu thông qua tín hiệu BLE. Khi sự gần gũi được xác minh, quá trình xác thực sẽ tiếp tục, tận dụng BLE để giao tiếp cục bộ, an toàn.
Trải nghiệm người dùng được nâng cao vì phương pháp này thường yêu cầu ít tương tác trực tiếp của người dùng hơn; các thiết bị ở gần nhau về mặt vật lý sẽ tự động phát hiện nhau. Về mặt bảo mật, caBLE mang lại một lợi thế đáng kể - nó đảm bảo rằng quá trình xác thực chỉ được thực hiện khi hai thiết bị ở gần nhau, ngăn chặn những kẻ tấn công từ xa khởi tạo quá trình xác thực.
Hãy tưởng tượng bạn nhận được một mã QR chuyển hướng đến một trang web độc hại. Nếu việc xác thực được thực hiện thông qua mã QR này, có nguy cơ phiên hoặc cookie có thể bị chiếm đoạt. BLE giải quyết vấn đề này bằng cách không dựa vào việc quét hình ảnh, mà dựa vào sự hiện diện vật lý của các thiết bị. Việc kiểm tra sự gần gũi này giảm thiểu nguy cơ tấn công xen giữa (man-in-the-middle), vì việc kiểm tra sự gần gũi không diễn ra qua internet hoặc một phương tiện trực quan.
Không giống như các phương pháp khác, caBLE thực sự không trao đổi dữ liệu xác thực như passkey. Thay vào đó, nó sử dụng BLE như một kênh xác nhận để thiết lập rằng các thiết bị đang ở gần nhau về mặt vật lý. Việc kiểm tra này được thiết kế để trở thành một phần của quy trình xác thực đa yếu tố trong đó sự gần gũi của BLE là một trong các yếu tố, đảm bảo rằng ngay cả khi các yếu tố khác bị xâm phạm, nếu không có sự gần gũi vật lý, quyền truy cập sẽ không được cấp.
Bằng cách tích hợp giao thức caBLE, các nhà phát triển có thể cung cấp một phương pháp an toàn và thân thiện với người dùng để xác thực passkey đa nền tảng (vận chuyển lai) giúp tăng cường bảo mật tổng thể của quá trình xác thực. Việc kiểm tra sự gần gũi bổ sung một lớp bảo vệ đơn giản cho người dùng nhưng lại bảo vệ hiệu quả chống lại một số loại tấn công mạng tinh vi.
Phương pháp xác thực passkey đa nền tảng (vận chuyển lai) này có những lợi ích sau:
Xác thực passkey đa nền tảng qua mã QR và Bluetooth (vận chuyển lai) là một cách để cải thiện UX trong các kịch bản đa nền tảng so với việc không cung cấp bất kỳ khả năng nào. Tuy nhiên, luồng người dùng này hoàn toàn mới đối với hầu hết người dùng và chúng tôi không mong đợi nhiều người dùng không rành về công nghệ sẽ hiểu được điều gì đang xảy ra khi họ lần đầu tiên gặp phải luồng này. Sự tương đồng duy nhất của việc giới thiệu luồng mã QR có thể là với các luồng đăng nhập cho ví dụ như WhatsApp Web hoặc Discord nơi mã QR được sử dụng (mặc dù chức năng ở đây khác). Vì vậy, quy trình xác thực passkey đa nền tảng được phân tích qua mã QR / Bluetooth (vận chuyển lai) giảm thiểu nỗ lực của người dùng trong kịch bản đa nền tảng, vì không cần phải nhập thủ công bất kỳ thông tin xác thực nào, nhưng luồng tổng thể vẫn chưa được nhiều người dùng biết đến.
Bảo mật của xác thực passkey đa nền tảng (vận chuyển lai) được củng cố bởi các kỹ thuật mật mã tiên tiến. Khi một mã QR được quét hoặc một kết nối Bluetooth được thực hiện để xác thực, các thử thách và phản hồi mật mã đảm bảo rằng chỉ thiết bị dự định mới có thể hoàn thành thành công quá trình xác thực.
Việc kiểm tra sự gần gũi qua Bluetooth bổ sung một lớp bảo mật, xác nhận rằng nỗ lực xác thực đang được thực hiện bởi một người có quyền truy cập vật lý vào thiết bị phụ.
Trong quá trình xác thực đa nền tảng (vận chuyển lai), passkey không bao giờ được lưu trữ tạm thời trên các thiết bị hoặc máy chủ trung gian, điều này ngăn chặn nguy cơ passkey bị chặn hoặc rò rỉ trong quá trình chuyển giao. Việc xác thực diễn ra trong thời gian thực, và passkey vẫn được liên kết với thiết bị chính của người dùng, bảo toàn tính toàn vẹn của nó.
Các phương pháp xác thực bằng mã QR và Bluetooth vốn đã cung cấp sự bảo vệ chống lại lừa đảo (phishing). Người dùng ít có khả năng bị lừa cung cấp passkey cho một trang web độc hại vì quá trình xác thực yêu cầu các hành động vật lý cụ thể đối với các thiết bị đáng tin cậy của người dùng.
Quá trình quét mã QR hoặc kết nối qua Bluetooth thường diễn ra trong một môi trường đáng tin cậy, làm giảm khả năng người dùng vô tình làm lộ thông tin xác thực của họ.
Phương pháp xác thực passkey đa nền tảng (vận chuyển lai) này có những nhược điểm sau:
Việc giới thiệu bất kỳ công nghệ mới nào cũng có thể dẫn đến sự nhầm lẫn của người dùng, đặc biệt nếu người dùng không rành về công nghệ. Xác thực passkey đa nền tảng qua mã QR và Bluetooth (vận chuyển lai) là một sự thay đổi đáng kể so với các phương pháp xác thực truyền thống, và một số người dùng có thể thấy quy trình mới này khó nắm bắt, có khả năng dẫn đến tốc độ chấp nhận chậm hơn. Tuy nhiên, chúng tôi kỳ vọng rằng người dùng cuối cùng sẽ quen với nó, vì vậy sự thay đổi có thể khó khăn hơn lúc đầu và sẽ trở nên mượt mà và được chấp nhận nhiều hơn theo thời gian.
Sự thành công của xác thực passkey đa nền tảng (vận chuyển lai) phụ thuộc rất nhiều vào việc thiết bị của người dùng có các khả năng cần thiết, chẳng hạn như camera có thể quét mã QR và chức năng Bluetooth. Người dùng có các thiết bị cũ hơn thiếu các tính năng này sẽ không thể tận dụng xác thực passkey đa nền tảng (vận chuyển lai), tạo ra một sự phân chia kỹ thuật số dựa trên các hạn chế về phần cứng.
Hành vi của người dùng có thể không thể đoán trước, và việc phụ thuộc vào người dùng để thực hiện các hành động cụ thể như quét mã QR hoặc bật Bluetooth có thể gây ra lỗi người dùng. Ví dụ, Bluetooth đôi khi có thể được xem là một thách thức về UX do các vấn đề ghép nối, vấn đề khám phá và sự thiếu tin tưởng chung của người dùng đối với các công nghệ không dây cho các giao dịch an toàn.
Các nhà phát triển phải đối mặt với nhiệm vụ liên tục cập nhật và bảo trì hệ thống để hỗ trợ các phương pháp xác thực mới nhất. Việc tích hợp xác thực passkey đa nền tảng (vận chuyển lai) vào các hệ thống hiện có đòi hỏi các nhà phát triển phải cập nhật các tiêu chuẩn mới, áp dụng các API mới và đảm bảo khả năng tương thích ngược, điều này có thể tốn nhiều tài nguyên và thời gian.
Đối với mỗi thiết bị mới hoặc yêu cầu đăng nhập tiếp theo, một passkey mới cần được tạo nếu không sử dụng tài khoản đám mây được đồng bộ hóa như iCloud Keychain hoặc trình quản lý mật khẩu. Điều này có thể làm tăng thêm sự phức tạp cho trải nghiệm người dùng và có thể gây ra sự thất vọng nếu người dùng không quen thuộc với quy trình hoặc nếu nó không được làm cho trực quan.
Có một nhu cầu cố hữu về việc giáo dục người dùng khi triển khai các phương pháp bảo mật mới như xác thực passkey đa nền tảng (vận chuyển lai). Việc đảm bảo rằng người dùng hiểu cách sử dụng mã QR và Bluetooth một cách an toàn đòi hỏi sự giao tiếp rõ ràng và có thể là hỗ trợ khách hàng rộng rãi.
Trong khi xác thực passkey đa nền tảng qua mã QR và Bluetooth (vận chuyển lai) thể hiện một bước tiến đáng kể trong công nghệ xác thực, những nhược điểm tiềm tàng này nhấn mạnh sự cần thiết của thiết kế thân thiện với người dùng, hệ thống hỗ trợ mạnh mẽ và một quá trình chuyển đổi dần dần, được truyền đạt tốt từ các phương pháp truyền thống sang các phương pháp đổi mới. Như với bất kỳ sự thay đổi công nghệ nào, việc cân bằng giữa lợi ích của sự đổi mới và những thách thức của nó sẽ là chìa khóa để triển khai thành công và được người dùng chấp nhận rộng rãi.
Lưu ý: chúng tôi bỏ qua các khóa bảo mật phần cứng (ví dụ:
YubiKeys) trong thử nghiệm sau đây và chỉ sử dụng các
trình xác thực nền tảng được tích hợp sẵn trong các thiết bị
(ví dụ: Face ID, Touch ID, Windows Hello). Trong trường hợp của
khóa bảo mật phần cứng (ví dụ:
YubiKey), các giá trị cho transports
sẽ là
[usb hoặc nfc]
(https://www.w3.org/TR/webauthn-2/#enum-transport)
chẳng hạn.
Chúng tôi đang sử dụng các kết hợp thiết bị / trình duyệt sau và Passkeys Debugger để kiểm tra hành vi. Android không được xem xét vì Android không thể đóng vai trò là client xác thực đa nền tảng (vận chuyển lai) (xem bảng ở trên):
Để kiểm tra hành vi, chúng tôi tạo cho mỗi kết hợp một passkey mới với các thuộc tính sau:
Sau khi tạo thành công passkey, chúng tôi sau đó sửa đổi đầu vào thuộc tính
allowCredentials của
máy chủ WebAuthn và khởi tạo một yêu cầu đăng
nhập. Chúng tôi muốn mô phỏng một passkey đã bị xóa trên thiết bị mà chúng tôi đã tạo
passkey, để thiết bị / trình duyệt tìm kiếm một thiết bị khác có thể cung cấp passkey qua
mã QR / Bluetooth. Do đó, chúng tôi thay đổi
credential ID và gán giá trị CHANGED-ID
, để việc
khớp nối thất bại. Hơn nữa, chúng tôi thay đổi thuộc tính
transports của
một thông tin xác thực WebAuthn trong allowCredentials và
gán cho mỗi kết hợp thiết bị / trình duyệt các giá trị sau:
[internal, hybrid]
: Passkey có thể được sử dụng từ
trình xác thực nền tảng (ví dụ: Face ID, Touch ID,
Windows Hello) hoặc qua xác thực đa nền tảng[internal]
: Passkey có thể được sử dụng từ
trình xác thực nền tảng (ví dụ: Face ID, Touch ID,
Windows Hello)Trong trang web thử nghiệm WebAuthn, cũng có tính năng mới của WebAuthn Level 3 cho các gợi ý của user agent. Tính năng này có thể cải thiện trải nghiệm người dùng nếu bên tin cậy có những giả định nhất định về cách yêu cầu đăng nhập có thể được hoàn thành một cách thân thiện nhất với người dùng. Trong thử nghiệm này, chúng tôi đã bỏ qua tính năng này vì nó chưa được triển khai rộng rãi. Vui lòng xem thông số kỹ thuật để biết thêm chi tiết.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Vì một lý do nào đó, một phần của cửa sổ modal xuất hiện bằng tiếng Đức, là một trong những ngôn ngữ được cài đặt.
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR, qua các thiết bị đã biết và qua khóa bảo mật phần cứng.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Vì một lý do nào đó, một phần của cửa sổ modal xuất hiện bằng tiếng Đức, là một trong những ngôn ngữ được cài đặt.
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR, qua các thiết bị đã biết và qua khóa bảo mật phần cứng.
Khi tạo passkey, chúng tôi nhận được lỗi sau (nhưng một passkey vẫn được tạo):
error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Vì một lý do nào đó, một phần của cửa sổ modal xuất hiện bằng tiếng Đức, là một trong những ngôn ngữ được cài đặt.
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR, qua các thiết bị đã biết và qua khóa bảo mật phần cứng.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này). Hơn nữa, bạn có thể trực tiếp chọn một trong các thiết bị đã biết để sử dụng passkey từ đó.
Cửa sổ modal này khá khác so với phiên bản tương tự trên Windows trong Chrome 119.
[internal]
#Đây là hành vi mong đợi, vì chúng tôi chỉ cho phép sử dụng passkey nội bộ nhưng không thể tìm thấy thông tin xác thực nội bộ trên thiết bị (chúng tôi không được phép sử dụng passkey lai). Việc xác thực passkey thất bại ở bước này và trong các triển khai thực tế, bạn sẽ cần cung cấp một phương thức xác thực dự phòng.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực nền tảng đa nền tảng / trình xác thực di động. Hơn nữa, bạn có thể trực tiếp chọn một trong các thiết bị đã biết để sử dụng passkey từ đó.
Cửa sổ modal này khá khác so với phiên bản tương tự trên Windows trong Chrome 119.
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Touch ID, qua mã QR, qua các thiết bị đã biết và qua khóa bảo mật phần cứng.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Đúng như dự đoán, hầu hết các hình thức xác thực passkey đều được cho phép: qua Touch ID, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Đúng như dự đoán, hầu hết các hình thức xác thực passkey đều được cho phép: qua Face ID, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
[internal, hybrid]
#Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
[internal]
#Khá khó hiểu, mã QR cũng được hiển thị ở đây, ngay cả khi chúng tôi chỉ cho phép thông tin xác thực nội bộ. Chúng tôi không thể tìm thấy lý do hợp lệ cho hành vi này.
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
Đúng như dự đoán, hầu hết các hình thức xác thực passkey đều được cho phép: qua Face ID, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
Sau đây, đối với các thiết bị Windows 10, chúng tôi quyết định đi sâu hơn một cấp và phân tích hành vi trông như thế nào nếu Bluetooth bị tắt hoặc không có sẵn trên máy Windows 10 nói chung. Đặc biệt đối với các thiết bị máy tính để bàn cũ hơn, đây vẫn là một kịch bản rất phổ biến vì các thiết bị này thường không có mô-đun Bluetooth, do đó không thể xác thực đa nền tảng qua mã QR và Bluetooth.
8.8.1.1 transports: [internal, hybrid]
Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này - ảnh chụp màn hình đầu tiên) hoặc chọn quét mã QR (ảnh chụp màn hình thứ hai).
8.8.1.2 transports: [internal]
Khá khó hiểu, bạn được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.8.1.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.8.1.4 allowCredentials rỗng
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR, qua các thiết bị đã biết và qua khóa bảo mật phần cứng.
8.8.2.1 transports: [internal, hybrid]
Đây là một thông báo thực sự khó hiểu cho người dùng, vì không có tuyên bố rõ ràng về những gì họ nên làm và cách họ có thể xác thực. Lựa chọn duy nhất họ có là nhấp vào "Hủy", khiến kịch bản này trở thành ngõ cụt.
8.8.2.2 transports: [internal]
Hành vi này giống như trường hợp Bluetooth được bật. Rất khó hiểu khi người dùng được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.8.2.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy lựa chọn duy nhất bạn có là sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.8.2.4 allowCredentials rỗng
Xác thực passkey chỉ có thể thực hiện qua Windows Hello và khóa bảo mật phần cứng.
8.9.1.1 transports: [internal, hybrid]
Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
8.9.1.2 transports: [internal]
Khá khó hiểu, bạn được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.9.1.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.9.1.4 allowCredentials rỗng
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
8.9.2.1 transports: [internal, hybrid]
Đây là một thông báo thực sự khó hiểu cho người dùng, vì không có tuyên bố rõ ràng về những gì họ nên làm và cách họ có thể xác thực. Lựa chọn duy nhất họ có là nhấp vào "Hủy", khiến kịch bản này trở thành ngõ cụt.
8.9.2.2 transports: [internal]
Hành vi này giống như trường hợp Bluetooth được bật. Rất khó hiểu khi người dùng được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.9.2.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy lựa chọn duy nhất bạn có là sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.9.2.4 allowCredentials rỗng
Xác thực passkey chỉ có thể thực hiện qua Windows Hello và khóa bảo mật phần cứng.
8.10.1.1 transports: [internal, hybrid]
Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
8.10.1.2 transports: [internal]
Khá khó hiểu, bạn được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.10.1.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.10.1.4 allowCredentials rỗng
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
8.10.2.1 transports: [internal, hybrid]
Đây là một thông báo thực sự khó hiểu cho người dùng, vì không có tuyên bố rõ ràng về những gì họ nên làm và cách họ có thể xác thực. Lựa chọn duy nhất họ có là nhấp vào "Hủy", khiến kịch bản này trở thành ngõ cụt. Vì một lý do nào đó, một phần của cửa sổ modal Windows Security cũng được hiển thị bằng tiếng Đức (một ngôn ngữ thứ hai được cài đặt trên thiết bị này).
8.10.2.2 transports: [internal]
Hành vi này giống như trường hợp Bluetooth được bật. Rất khó hiểu khi người dùng được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.10.2.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy lựa chọn duy nhất bạn có là sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.10.2.4 allowCredentials rỗng
Xác thực passkey chỉ có thể thực hiện qua Windows Hello và khóa bảo mật phần cứng.
8.11.1.1 transports: [internal, hybrid]
Đúng như dự đoán, không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR và sử dụng passkey trên một thiết bị khác (vì hệ thống biết rằng có một passkey tồn tại cho người dùng này).
8.11.1.2 transports: [internal]
Khá khó hiểu, bạn được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.11.1.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy hệ thống đề nghị quét mã QR hoặc sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.11.1.4 allowCredentials rỗng
Đúng như dự đoán, tất cả các hình thức xác thực passkey đều được cho phép: qua Windows Hello, qua mã QR và qua khóa bảo mật phần cứng. Vì một lý do nào đó, các thiết bị đã biết không được hiển thị.
8.11.2.1 transports: [internal, hybrid]
Đây là một thông báo thực sự khó hiểu cho người dùng, vì không có tuyên bố rõ ràng về những gì họ nên làm và cách họ có thể xác thực. Lựa chọn duy nhất họ có là nhấp vào "Hủy", khiến kịch bản này trở thành ngõ cụt.
8.11.2.2 transports: [internal]
Hành vi này giống như trường hợp Bluetooth được bật. Rất khó hiểu khi người dùng được nhắc nhập mã PIN Windows Hello (hoặc quét vân tay / khuôn mặt nếu được thiết lập trên thiết bị), mặc dù chúng tôi đã thay đổi credential ID (vì vậy nó thực sự không nên tìm thấy thông tin xác thực vì nó không được chỉ định trong thuộc tính allowCredentials). Tuy nhiên, sau khi gửi mã PIN Windows Hello, một lỗi được đưa ra: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Từ góc độ người dùng, đây là một hành vi khá khó hiểu nhưng có lý vì nó có thể cung cấp thông tin về passkey của người dùng mà không có sự đồng ý của họ.
8.11.2.3 Không đặt thuộc tính transports
Không có passkey cục bộ nào khớp, vì vậy lựa chọn duy nhất bạn có là sử dụng khóa bảo mật phần cứng (ví dụ: YubiKey) / trình xác thực đa nền tảng / trình xác thực di động.
8.11.2.4 allowCredentials rỗng
Xác thực passkey chỉ có thể thực hiện qua Windows Hello và khóa bảo mật phần cứng.
transports: [internal]
), vì vậy bạn cần chuẩn bị rằng
người dùng của bạn sẽ tìm thấy phương pháp này và sẽ có câu hỏi. Sự xuất hiện của xác
thực đa nền tảng (vận chuyển lai) này sẽ xảy ra đặc biệt nếu người dùng bắt đầu
xóa passkey cục bộ.Xác thực passkey đa nền tảng qua mã QR / Bluetooth (vận chuyển lai) mang lại sự cân bằng giữa bảo mật và UX. Tuy nhiên, đây là một quy trình hoàn toàn mới đối với hầu hết người dùng và có thể gây ra nhiều tình huống khó hiểu, vì vậy cần phải suy nghĩ kỹ xem bạn có muốn quảng bá nó hay không.
Chúng tôi hy vọng rằng chúng tôi đã có thể làm sáng tỏ chủ đề xác thực passkey đa nền tảng (vận chuyển lai) qua mã QR / Bluetooth, giải thích cách thiết lập mọi thứ và hành vi trên các kết hợp thiết bị / trình duyệt khác nhau trông như thế nào. Nếu bạn có bất kỳ câu hỏi nào, vui lòng liên hệ với chúng tôi qua cộng đồng passkey của chúng tôi hoặc đăng ký Substack về passkey của chúng tôi. Hãy cùng nhau làm cho Internet trở thành một nơi an toàn hơn bằng cách phổ biến passkey.
Enjoyed this read?
🤝 Join our Passkeys Community
Share passkeys implementation tips and get support to free the world from passwords.
🚀 Subscribe to Substack
Get the latest news, strategies, and insights about passkeys sent straight to your inbox.
Related Articles
Table of Contents