Mã QR & Bluetooth của Passkey WebAuthn: Vận chuyển lai (Hybrid Transport)

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.

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:

• Hỗ trợ WebAuthn: Các thiết bị phải hỗ trợ WebAuthn. Điều này đã có trên 99% thiết bị, theo phân tích dữ liệu passkey mới nhất của chúng tôi.
• Camera để quét mã QR: Các thiết bị sẽ cần một camera có khả năng quét mã QR. Hầu hết các điện thoại thông minh hiện đại đều được trang bị camera có chức năng này. Hơn nữa, camera cần có khả năng quét QR tích hợp (điều mà hầu hết các thiết bị đều có sẵn). Nếu camera của bạn không hỗ trợ, thì một trình quét QR trực tuyến cũng là một lựa chọn tốt. Nếu không, việc cài đặt một ứng dụng mã QR cũng được.
• Khả năng Bluetooth: Bluetooth Năng lượng Thấp được hỗ trợ bởi đám mây (caBLE) được sử dụng để thiết lập một kết nối an toàn dựa trên sự gần gũi giữa các thiết bị. Các phiên bản cần tìm là Bluetooth 4.0 trở lên, cho phép mở rộng caBLE cho WebAuthn.
• Kết nối Internet: Cần có kết nối internet ổn định trên cả hai thiết bị, vì việc trao đổi liên quan đến việc mở một đường hầm để thực hiện các bước xác minh yêu cầu truyền dữ liệu thời gian thực.

Từ quan điểm phần mềm, có các yêu cầu sau:

• Cấu hình máy chủ WebAuthn: Rõ ràng, bạn cần có một máy chủ WebAuthn để quản lý các khóa công khai. Điều này cũng bao gồm việc cho phép tài khoản của người dùng được liên kết với nhiều trình xác thực và thiết lập máy chủ để bắt đầu nghi thức xác thực.
• Web Bluetooth API: Để kiểm tra sự gần gũi bằng Bluetooth, bạn sẽ cần truy cập Web Bluetooth API để kích hoạt khả năng Bluetooth của thiết bị từ trình duyệt.
• Yêu cầu hệ điều hành: Vui lòng xem bảng sau về việc hỗ trợ Xác thực đa thiết bị cho các hệ điều hành khác nhau tính đến tháng 3 năm 2025. Trình xác thực (Authenticator) có nghĩa là thiết bị có thể đóng vai trò là thiết bị giữ passkey (trong kịch bản của chúng ta là điện thoại thông minh). Client có nghĩa là thiết bị tạo mã QR và nơi người dùng cố gắng đăng nhập (trong kịch bản của chúng ta là máy tính để bàn):

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:

• Sử dụng một lần: Định danh phiên trong mã QR chỉ có giá trị cho một lần sử dụng duy nhất, ngăn chặn các cuộc tấn công phát lại (replay attacks).
• Mã hóa: Tất cả dữ liệu trong mã QR đều được mã hóa, đảm bảo rằng mọi thông tin liên lạc bị chặn đều không thể bị giải mã bởi các bên không được ủy quyền.

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:

• Không trao đổi dữ liệu Bluetooth, hoàn toàn qua Internet: Điều quan trọng cần lưu ý là trong quá trình xác thực passkey đa nền tảng dựa trên mã QR này (vận chuyển lai), Bluetooth không tham gia vào việc trao đổi dữ liệu. Quá trình này hoàn toàn dựa vào kết nối Internet để truyền dữ liệu được mã hóa giữa các thiết bị và máy chủ. Tuy nhiên, Bluetooth được sử dụng để kiểm tra sự gần gũi của hai thiết bị.
• Khóa riêng tư không rời khỏi thiết bị: Trong suốt quá trình này, khóa riêng tư của người dùng vẫn được giữ an toàn trên thiết bị của họ.
• Không để lộ dữ liệu nhạy cảm: Không có thông tin passkey nhạy cảm hoặc khóa riêng tư nào được chuyển hoặc để lộ trong quá trình xác thực.
• Mật mã bất đối xứng: Cơ chế thử thách-phản hồi đảm bảo rằng những gì được gửi đi chỉ là các phiên bản đã ký, không thể tái sử dụng của các thử thách mà không thể bị khai thác để truy cập trái phép.

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:

• userName: alex muller (không ảnh hưởng trong thử nghiệm này)
• authenticatorAttachment: platform (vì chúng tôi muốn loại trừ khóa bảo mật phần cứng như YubiKeys)
• residentKey: preferred (không ảnh hưởng trong thử nghiệm này)
• userVerification: preferred (không ảnh hưởng trong thử nghiệm này)
• attestation: none (không ảnh hưởng trong thử nghiệm này)
• hints: empty (xem giải thích bên dưới)
• usePRF: no (không ảnh hưởng trong thử nghiệm này)

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:

1. transports: [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
2. transports: [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)
3. Không đặt thuộc tính transports: hành vi mặc định không có giới hạn

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.

Đú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).

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.

Đú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).

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.

Đú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).

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.

Đú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.

Đâ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.

Đú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).

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ị.

Đú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).

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ị.

Đú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).

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.

• Sử dụng thư viện và framework giúp trừu tượng hóa một số phức tạp của API WebAuthn thuần túy.
• Xem xét các kịch bản xác thực đa nền tảng ngay từ đầu để đảm bảo một lượng lớn người dùng có thể hưởng lợi từ việc triển khai passkey của bạn. Tùy thuộc vào lựa chọn thiết kế của bạn, bạn cũng có thể cung cấp các phương thức đăng nhập thay thế trong các kịch bản này.
• Phát triển các cơ chế dự phòng cho các kịch bản mà xác thực đa nền tảng passkey (vận chuyển lai) có thể không thực hiện được do hạn chế của thiết bị.
• Quyết định thiết kế lớn nhất là quyết định xem bạn có muốn quảng bá xác thực passkey đa nền tảng qua mã QR / Bluetooth (vận chuyển lai) và biến nó thành một phương thức nổi bật để xác thực passkey hay sử dụng các gợi ý để không quảng bá nó một cách tích cực. Trong trường hợp sau, hệ thống luôn cố gắng sử dụng ngay lập tức các passkey được lưu trữ nội bộ và chỉ khi không tìm thấy passkey nội bộ nào, một mã QR cho xác thực đa nền tảng (vận chuyển lai) mới được hiển thị. Điều này cần được xác định trong các tùy chọn máy chủ WebAuthn của bạn trong các thuộc tính excludeCredentials và allowCredentials. Trong thuộc tính excludeCredentials của máy chủ WebAuthn của bạn, bạn có thể thấy thông tin vận chuyển về các thông tin xác thực đã được tạo. Trong thuộc tính allowCredentials, bạn có thể chỉ định hành vi trong quá trình đăng nhập (xem các thử nghiệm ở trên).
• Hơn nữa, bạn không thể ngăn chặn hoàn toàn xác thực passkey đa nền tảng (vận chuyển lai) (xem các thử nghiệm ở trên với 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ộ.

• Tạo các hướng dẫn và bài học toàn diện hướng dẫn người dùng qua quy trình xác thực passkey đa nền tảng (vận chuyển lai).
• Sử dụng các chú giải công cụ trong ứng dụng và các phần trợ giúp theo ngữ cảnh để hướng dẫn người dùng trong lần trải nghiệm xác thực passkey đa nền tảng (vận chuyển lai) đầu tiên của họ.
• Cung cấp các phần Câu hỏi thường gặp (FAQs) và khắc phục sự cố trên trang web của bạn hoặc trong ứng dụng.

• Triển khai các phiên có giới hạn thời gian cho các lần đăng nhập passkey qua mã QR hoặc Bluetooth để đảm bảo rằng quyền truy cập chỉ là tạm thời và an toàn.
• Đảm bảo rằng xác thực passkey đa nền tảng (vận chuyển lai) không làm suy yếu bất kỳ giao thức bảo mật hiện có nào, duy trì tính toàn vẹn của dữ liệu người dùng.
• Xem xét các tác động về quyền riêng tư và đảm bảo rằng bất kỳ quyền truy cập tạm thời nào được cấp qua xác thực passkey đa nền tảng (vận chuyển lai) đều được ghi lại và giám sát theo các phương pháp bảo mật tốt nhất.

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.