Khóa Thường Trú WebAuthn: Thông Tin Xác Thực Có Thể Khám Phá Dưới Dạng Passkey

Passkeys và giao thức nền tảng WebAuthn đang cách mạng hóa bối cảnh xác thực. Tuy nhiên, việc thiết lập một máy chủ WebAuthn đúng cách có thể là một nỗ lực khó khăn. Cấu hình sai không chỉ có thể gây ra các lỗ hổng mà còn làm hỏng các passkey hiện có nếu bạn cần thay đổi chúng sau này. Bài viết sau đây sẽ giúp bạn hiểu rõ hơn về các thông số kỹ thuật thường phức tạp của WebAuthn và đưa ra lời khuyên về cài đặt nào là tốt nhất cho trường hợp sử dụng của bạn.

WebAuthn hoạt động với ba thực thể chính:

• Relying Party (RP): Đây là dịch vụ web của bạn muốn xác thực người dùng. Nó gửi các thử thách đến máy khách, xác minh phản hồi và quản lý khóa công khai của một passkey.
• Trình xác thực (Authenticators): Đây là các thiết bị có thể chứng minh quyền sở hữu thông tin xác thực. Ví dụ bao gồm điện thoại thông minh, máy tính xách tay, hoặc khóa bảo mật (ví dụ: YubiKeys). Trình xác thực có thể dành riêng cho nền tảng (như Windows Hello hoặc Touch ID / Face ID của Apple) hoặc đa nền tảng (như khóa bảo mật, ví dụ: YubiKeys).
• Máy khách (Clients): Thông thường, đây là các trình duyệt web hoặc ứng dụng gốc hoạt động như một trung gian giữa RP và trình xác thực. Chúng tạo điều kiện cho việc giao tiếp, đảm bảo rằng dữ liệu được luân chuyển một cách chính xác và an toàn.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Sau đây, chúng tôi sẽ mô tả luồng dữ liệu cấp cao trong quá trình xác thực (đăng nhập hoặc đăng ký).

1. Khởi tạo từ máy khách: Quá trình bắt đầu từ phía máy khách, thường là khi người dùng cố gắng đăng nhập hoặc đăng ký. Ví dụ, họ có thể nhấp vào nút "Đăng nhập bằng WebAuthn" và máy khách sẽ gửi một yêu cầu thử thách đến RP.
2. Yêu cầu từ RP: RP sau đó gửi một thử thách trở lại máy khách. Thử thách này là một giá trị được tạo ngẫu nhiên để đảm bảo tính xác thực của phản hồi tiếp theo.
3. Từ máy khách đến Trình xác thực: Trong quá trình đăng ký, máy khách yêu cầu trình xác thực tạo một passkey mới bằng cách tạo cặp khóa công khai-riêng tư tương ứng. Trong quá trình đăng nhập, máy khách yêu cầu trình xác thực ký vào thử thách. Điều này được thực hiện bằng khóa riêng tư trên trình xác thực, tương ứng với một khóa công khai đã đăng ký trước đó được lưu trữ trên RP.
4. Phản hồi từ Trình xác thực: Trong quá trình đăng ký, trình xác thực gửi lại khóa công khai cho máy khách. Trong quá trình đăng nhập, trình xác thực ký vào thử thách và gửi assertion đã ký này trở lại máy khách.
5. Từ máy khách đến RP: Máy khách chuyển tiếp khóa công khai mới này / assertion đã ký đến RP.
6. Xác minh bởi RP: RP lưu trữ khóa công khai / xác minh assertion đã ký bằng khóa công khai đã lưu. Nếu hợp lệ, quá trình xác thực thành công.

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 lập trình viên tin tưởng Corbado & giúp 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 Passkeys

Luồng quy trình cấp cao được mô tả ở trên mô tả các quy trình đăng ký và đăng nhập của WebAuthn. Passkey được xây dựng dựa trên WebAuthn. Ban đầu, thuật ngữ passkey được sử dụng như một thuật ngữ dễ nhớ và phi kỹ thuật hơn so với WebAuthn để mô tả cùng một thứ. Hơn nữa, passkey cung cấp nhiều tính năng hơn so với WebAuthn tiêu chuẩn, ví dụ như khả năng đồng bộ hóa passkey qua tài khoản đám mây hoặc trình quản lý mật khẩu.

Để hiểu rõ hơn các phần sau, chúng ta hãy định nghĩa một số thuật ngữ quan trọng trong giao thức WebAuthn để có một sự hiểu biết chung.

• Credential ID: Credential ID là một mã định danh duy nhất được gán cho một thông tin xác thực khóa công khai cụ thể do trình xác thực tạo ra. Nó cho phép các Relying Party (RP) xác định và chọn PublicKeyCredential chính xác cho các quy trình xác thực.
• PublicKeyCredential: Đây là cấu trúc dữ liệu chính được trả về từ API WebAuthn của trình duyệt hoặc ứng dụng gốc. Nó bao gồm cả dữ liệu Attestation trong quá trình đăng ký và dữ liệu Assertion trong quá trình đăng nhập. Về cơ bản, nó chứa dữ liệu mà RP cần để xác minh quy trình.
• Attestation: Attestation trong bối cảnh WebAuthn đóng vai trò là bằng chứng về nguồn gốc và tính toàn vẹn của trình xác thực. Trong quá trình đăng ký, đó là cách để trình xác thực nói rằng, "Tôi đã đăng ký thông tin xác thực của người dùng một cách an toàn, và đây là một tuyên bố bạn có thể sử dụng để xác minh điều đó". Relying Party sau đó có thể xác minh rằng chữ ký đến từ một trình xác thực cụ thể được cho phép (ví dụ: Yubikey). Không phải tất cả trình xác thực passkey đều trả lời bằng một attestation như vậy, một số chỉ không gửi lại dữ liệu hữu ích (xem tại đây danh sách các trình xác thực passkey). Các AAGUID (Authenticator Attestation GUIDs) khác xác định nhiều trình xác thực hơn (chủ yếu là các khóa bảo mật, ví dụ: YubiKeys) có thể được tìm thấy trong FIDO Alliance Metadata Service.
• Assertion: Sau quá trình đăng ký, khi người dùng cố gắng đăng nhập, trình xác thực tạo ra một assertion. Assertion về cơ bản là PublicKeyCredential + thử thách đã được ký. Assertion này chứng minh rằng người dùng sở hữu khóa riêng tư được liên kết với khóa công khai đã đăng ký mà không tiết lộ khóa riêng tư thực tế. Đó là cách của trình xác thực để nói, "Đây là người dùng đích thực, và tôi có thể bảo đảm cho họ."

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Khóa thường trú (Resident keys - RKs) và khóa không thường trú (non-resident keys - NRKs) là hai loại khóa mật mã được sử dụng trong giao thức WebAuthn, và chúng khác nhau chủ yếu ở vị trí lưu trữ và cơ chế truy xuất.

Định nghĩa:

Khóa thường trú được lưu trữ trực tiếp trên chính trình xác thực. Đây có thể là một khóa bảo mật (ví dụ: YubiKey), một vùng an toàn của nền tảng (ví dụ: Secure Enclave của iPhone), hoặc một mô-đun nền tảng đáng tin cậy (TPM) trên máy tính xách tay. Conditional UI (tự động điền passkey) chỉ hoạt động với khóa thường trú và nhóm làm việc WebAuthn hiện yêu cầu khóa thường trú phải được coi là một passkey.

Trong ảnh chụp màn hình sau, bạn sẽ thấy danh sách tất cả các khóa thường trú (credential ID, rpID, username, display name) được lưu trữ trên một YubiKey. Khóa không thường trú không có trong danh sách, vì chúng không được lưu trữ trên trình xác thực:

Luồng đăng nhập:

Nguồn: William Brown

Trong quá trình đăng nhập, Relying Party gửi một yêu cầu mà không chỉ định thông tin xác thực đến máy khách (trình duyệt), sau đó máy khách bắt đầu truy vấn trình xác thực (ở đây trong biểu đồ là: khóa bảo mật). Trình xác thực khám phá tất cả các khóa thường trú cho Relying Party tương ứng và máy khách (trình duyệt) chọn khóa thường trú mong muốn. Khóa thường trú này được sử dụng để ký thử thách. Chữ ký được gửi từ trình xác thực qua máy khách đến Relying Party.

Ưu điểm:

1. Trải nghiệm người dùng được tinh giản: Một trong những ưu điểm đáng kể nhất của khóa thường trú là trình xác thực lưu trữ định danh người dùng (ví dụ: email, số điện thoại, tên người dùng) và do đó có thể điền trước định danh người dùng (ví dụ: email, số điện thoại, tên người dùng) để đăng nhập. Người dùng không cần phải nhớ hoặc nhập định danh người dùng, giúp tinh giản quá trình đăng nhập, đặc biệt là trên các thiết bị có khả năng sinh trắc học. Điều này cũng có thể xảy ra tự động với Conditional UI.
2. Xác thực theo thiết bị cụ thể: Khóa thường trú có thể cung cấp một lớp bảo mật bổ sung bằng cách liên kết xác thực với một thiết bị cụ thể. Điều này có thể đặc biệt hữu ích cho các dịch vụ muốn đảm bảo người dùng đang đăng nhập từ các thiết bị đáng tin cậy.
3. Conditional UI (Tự động điền Passkey): Conditional UI chỉ hoạt động với các khóa thường trú, mang lại trải nghiệm đăng nhập liền mạch nhất (xem bên dưới để biết chi tiết).

Nhược điểm:

1. Giới hạn lưu trữ: Một số trình xác thực có dung lượng lưu trữ hữu hạn. Đặc biệt đối với các khóa bảo mật (ví dụ: YubiKeys), thường có giới hạn về số lượng khóa thường trú mà chúng có thể lưu trữ (hầu hết có giới hạn từ 8 đến ~100 khóa thường trú). Khi đạt đến giới hạn này, các khóa cũ hơn có thể cần phải bị xóa để nhường chỗ cho các khóa mới, hoặc người dùng có thể cần sử dụng một trình xác thực khác.
2. Mất trình xác thực: Nếu trình xác thực, ví dụ như một khóa bảo mật (ví dụ: YubiKey) hoặc điện thoại thông minh, bị mất hoặc hỏng, tất cả các khóa thường trú trên thiết bị đó sẽ bị mất. Điều này có thể khiến người dùng bị khóa khỏi nhiều dịch vụ cho đến khi họ đăng ký lại hoặc khôi phục tài khoản của mình. Đồng bộ hóa khóa qua tài khoản đám mây (ví dụ: iCloud Keychain, Google Password Manager) hoặc một trình quản lý mật khẩu hiện đại (ví dụ: 1Password hoặc Dashlane) sẽ ngăn chặn việc mất mát này.
3. Mối lo ngại về bảo mật: Nếu một trình xác thực có khóa thường trú bị đánh cắp, kẻ tấn công có thể cố gắng trích xuất các khóa. Mặc dù các trình xác thực hiện đại có các cơ chế bảo mật mạnh mẽ để ngăn chặn việc trích xuất, ví dụ như người dùng bảo vệ thiết bị bằng mã PIN, mật mã hoặc cử chỉ mạnh, rủi ro, dù là tối thiểu, vẫn tồn tại.

Trường hợp sử dụng: Lý tưởng cho các thiết bị mà người dùng thường xuyên xác thực, như điện thoại thông minh cá nhân hoặc máy tính xách tay.

Want to find out how many people use passkeys?

View Adoption Data

Định nghĩa:

Ngược lại, khóa không thường trú không được lưu trữ trên trình xác thực. Thay vào đó, trình xác thực tạo ra một cặp khóa mới (dựa trên khóa chủ được bảo vệ bên trong của nó) và gửi khóa công khai của cặp khóa mới này đến máy chủ (Relying Party) cùng với credential ID (chứa một seed) trong quá trình đăng ký. Máy chủ sau đó liên kết khóa công khai này với tài khoản của người dùng. Đối với các lần xác thực tiếp theo, trình xác thực sẽ tái tạo khóa riêng tư bằng cách nhận credential ID, trích xuất seed và kết hợp nó với khóa chủ. Bởi vì khóa chỉ có sẵn tạm thời trong bộ nhớ được bảo vệ của trình xác thực, đôi khi nó được gọi là khóa tạm thời (ephemeral key) trong ngôn ngữ mật mã.

Luồng đăng nhập:

Nguồn: William Brown

Trong quá trình đăng nhập, Relying Party trước tiên phải xác định người dùng nào đang yêu cầu xác thực (ví dụ: bằng cách yêu cầu định danh người dùng, ví dụ: email, số điện thoại hoặc tên người dùng) và sau đó gửi các credential ID mà nó biết cho người dùng yêu cầu đến máy khách (trình duyệt). Máy khách chuyển tiếp chúng đến trình xác thực (ở đây: khóa bảo mật). Trình xác thực sử dụng credential ID cùng với khóa chủ của trình xác thực để tạo ra khóa riêng tư tạm thời, ký thử thách bằng khóa đã tạo và trả về cho máy khách (ở đây: trình duyệt), sau đó máy khách chuyển tiếp nó đến Relying Party. Khóa không thường trú ban đầu được sử dụng làm yếu tố thứ hai trước khi passkey ra đời. Do đó, việc xác định người dùng trước là một phần của quy trình đăng nhập thông thường.

Ưu điểm:

1. Khả năng mở rộng: Vì khóa không thường trú không nằm trên trình xác thực, người dùng có thể có một số lượng gần như không giới hạn các khóa không thường trú được liên kết với các dịch vụ khác nhau. Điều này đặc biệt có lợi cho những người dùng có tài khoản trên nhiều nền tảng.
2. Khả năng di động (Roaming): Khóa không thường trú lý tưởng cho các trình xác thực di động như khóa bảo mật (ví dụ: YubiKey). Người dùng có thể sử dụng cùng một khóa bảo mật (ví dụ: YubiKey) để xác thực trên nhiều thiết bị và nền tảng, mang lại trải nghiệm nhất quán.
3. Giảm sự phụ thuộc vào bộ nhớ của trình xác thực: Với các cài đặt máy chủ WebAuthn phù hợp, không cần phải lo lắng về giới hạn lưu trữ của trình xác thực. Điều này có thể đặc biệt thuận lợi cho các trình xác thực có bộ nhớ thấp, như khóa bảo mật (ví dụ: YubiKeys).

Nhược điểm:

1. UX kém hơn do yêu cầu định danh người dùng: Nhược điểm lớn nhất của khóa không thường trú là định danh người dùng (ví dụ: email, số điện thoại, tên người dùng) cần được người dùng cung cấp, điều này khiến việc điền trước tên người dùng qua Conditional UI là không thể. Định danh người dùng này cần được liên kết với credential ID, vốn cần thiết để tính toán khóa được bao bọc bởi khóa tạm thời (ephermal key-wrapped key).
2. Tiềm năng quản lý sai: Các RP cần quản lý và bảo mật các liên kết giữa tài khoản người dùng và khóa công khai. Quản lý kém hoặc các lỗ hổng có thể dẫn đến các vấn đề bảo mật.

Trường hợp sử dụng: Lý tưởng cho các trình xác thực di động như khóa bảo mật (ví dụ: YubiKeys) được sử dụng trên nhiều dịch vụ hoặc nền tảng.

Hãy tưởng tượng bạn có một khóa bảo mật (ví dụ: YubiKey) và bạn đăng ký nó với hai dịch vụ trực tuyến: Dịch vụ A và Dịch vụ B. Đối với Dịch vụ A, bạn sử dụng khóa thường trú. Đối với Dịch vụ B, bạn sử dụng khóa không thường trú. Khi bạn xác thực với Dịch vụ A, bạn chỉ cần chạm vào khóa bảo mật của mình (ví dụ: YubiKey) và bạn đã đăng nhập - không cần chỉ định tên người dùng. Đối với Dịch vụ B, trước tiên bạn sẽ cung cấp tên người dùng của mình trong trình duyệt / ứng dụng gốc. Dịch vụ sau đó sẽ gửi credential ID được liên kết đến khóa bảo mật của bạn (ví dụ: YubiKey), sau đó khóa này sẽ tái tạo khóa riêng tư tạm thời để xác thực.

Về cơ bản, trong khi cả khóa thường trú và không thường trú đều tăng cường bảo mật bằng cách tận dụng xác thực mật mã, trải nghiệm người dùng và cơ chế lưu trữ của chúng khác nhau, phục vụ cho các trường hợp sử dụng đa dạng.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Conditional UI là một tính năng cột mốc của passkey / WebAuthn. Nó giúp người dùng giảm bớt gánh nặng hơn nữa, vì người dùng không chỉ không cần nhớ mật khẩu, mà còn không cần nhớ định danh người dùng (ví dụ: email, số điện thoại, tên người dùng) mà họ đã đăng ký với một Relying Party. Đặc biệt, trong những trường hợp các dịch vụ của Relying Party chỉ được sử dụng không thường xuyên, đây là một bước tiến lớn.

Điều này hoạt động vì ngay khi trang đăng nhập được mở, máy chủ Relying Party sẽ gửi một thử thách trong nền đến máy khách (hãy nhớ rằng không cần gửi credential ID trong lệnh gọi này). Máy khách nhận thử thách này và kiểm tra xem passkey nào khớp với Relying Party ID trên trình xác thực này và đưa ra lựa chọn thông qua menu tự động điền, nơi người dùng có thể chọn passkey thích hợp.

Hơn nữa, nó cũng giúp người dùng tiết kiệm một cú nhấp chuột vào nút đăng nhập, bởi vì ngay sau khi passkey được chọn từ menu tự động điền, quá trình đăng nhập sẽ bắt đầu.

CTAP là một giao thức nền tảng trong tiêu chuẩn FIDO2, kết nối khoảng cách giao tiếp giữa máy khách (như trình duyệt) và trình xác thực (như khóa bảo mật, ví dụ: YubiKeys, hoặc điện thoại thông minh). Để hiểu rõ hơn về CTAP, chúng ta hãy xem xét sơ lược các phiên bản giao thức khác nhau trước khi phân tích tác động của chúng đối với khóa thường trú và không thường trú.

Phiên bản trước đó, thường được gọi là Universal 2nd Factor (U2F), được thiết kế chủ yếu cho xác thực yếu tố thứ hai. Trong U2F, máy chủ cung cấp một thử thách, và trình xác thực cung cấp một phản hồi, chứng minh quyền sở hữu khóa riêng tư. Tuy nhiên, U2F không hỗ trợ khóa thường trú, nghĩa là nó luôn yêu cầu một tra cứu phía máy chủ để xác định khóa nào sẽ sử dụng cho một người dùng, vì đây là một phần của quy trình khi yêu cầu một yếu tố thứ hai.

Là phiên bản kế thừa của U2F, CTAP2 đã giới thiệu hỗ trợ cho khóa thường trú, cho phép xác thực không cần mật khẩu và không cần tên người dùng. Với khóa thường trú, trình xác thực lưu trữ tên người dùng và credential ID của người dùng (cùng với Relying Party ID), loại bỏ nhu cầu Relying Party phải cung cấp nó trong quá trình xác thực. Đây là một bước nhảy vọt đáng kể hướng tới một UX liền mạch hơn.

Tuy nhiên, CTAP2 cũng đi kèm với những thách thức. Một vấn đề đáng chú ý là việc quản lý các khóa thường trú. Ví dụ, việc xóa một khóa thường trú cụ thể trong một thiết bị CTAP2.0 thường yêu cầu đặt lại hoàn toàn thiết bị (nghĩa là khóa chủ của bạn cũng bị đặt lại, có nghĩa là tất cả các khóa không thường trú của bạn cũng sẽ không còn hoạt động), điều này không thân thiện với người dùng và có thể gây ra vấn đề trong các tình huống có nhiều khóa thường trú được lưu trữ trên một thiết bị duy nhất. Điều này làm cho khóa thường trú trên thiết bị CTAP2.0 trở thành một cam kết nghiêm túc. Bạn thực sự không muốn vô tình lấp đầy không gian hạn chế mà bạn thường có, đặc biệt là trên các khóa bảo mật (ví dụ: YubiKeys).

CTAP2.1 là phiên bản tiếp theo của CTAP2, mang đến các tính năng và cải tiến bổ sung cho giao thức. Một số điểm chính về CTAP 2.1 bao gồm:

• Quản lý khóa thường trú tốt hơn: CTAP 2.1 cho phép quản lý, cập nhật và xóa từng khóa thường trú cụ thể khỏi thiết bị của bạn.
• Attestation cho doanh nghiệp: Tính năng này cho phép các doanh nghiệp kiểm soát nhiều hơn đối với các khóa được nhân viên của họ sử dụng. Nó cung cấp một cách để các doanh nghiệp xác minh rằng các khóa đang được sử dụng là do công ty cấp.
• Nhận dạng nhiều người dùng: Một số trình xác thực có thể nhận dạng nhiều người dùng. CTAP 2.1 cung cấp một cách để các trình xác thực này cho biết người dùng nào đã được nhận dạng.
• Tương thích ngược: CTAP 2.1 được thiết kế để tương thích ngược với CTAP2, đảm bảo rằng các thiết bị và nền tảng hỗ trợ phiên bản cũ hơn vẫn có thể hoạt động với phiên bản mới.

Sau khi đã xem xét về khóa thường trú, khóa không thường trú và các phiên bản CTAP khác nhau, bây giờ chúng ta sẽ phân tích sâu hơn về phía Relying Party và do đó là phía máy chủ WebAuthn.

Tính linh hoạt (nhưng cũng là sự phức tạp) của WebAuthn phần lớn được cho là do các cài đặt máy chủ của nó, đặc biệt là trong đối tượng authenticatorSelection. Đối tượng này hướng dẫn máy khách trong việc chọn trình xác thực phù hợp cho công việc.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Tùy chọn máy chủ này chỉ định cách trình xác thực được gắn vào thiết bị của máy khách. Nó cung cấp thông tin chi tiết về cách trình xác thực giao tiếp với máy khách:

Các giá trị khả thi

• platform: Điều này cho biết rằng trình xác thực được gắn vào nền tảng của máy khách và do đó không thể tháo rời.
• cross-platform: Điều này cho biết rằng trình xác thực không bị ràng buộc vào nền tảng của máy khách và có thể được sử dụng trên nhiều thiết bị.

Trường hợp sử dụng & Ví dụ

• platform: Ví dụ bao gồm một máy quét vân tay được tích hợp sẵn trong máy tính xách tay hoặc một hệ thống nhận dạng khuôn mặt trên điện thoại, ví dụ: Face ID, Touch ID hoặc Windows Hello.
• cross-platform: Ví dụ bao gồm các khóa bảo mật USB (ví dụ: YubiKeys), thiết bị Bluetooth hoặc thẻ NFC.

Trong đặc tả WebAuthn Cấp độ 1, tùy chọn máy chủ này được gọi là requireResidentKey và có thể giữ các giá trị Boolean true (trình xác thực phải tạo khóa thường trú) hoặc false (trình xác thực phải tạo khóa không thường trú). WebAuthn Cấp độ 2 đã thay thế tùy chọn máy chủ này bằng tùy chọn mới residentKey:

Các giá trị khả thi

• required: Trình xác thực phải tạo một khóa thường trú (nếu không thể, hoạt động sẽ thất bại).
• preferred: Trình xác thực nên cố gắng tạo một khóa thường trú (nếu không thể, nó nên tạo một khóa không thường trú)
• discouraged: Trình xác thực phải tạo một khóa không thường trú (nếu không thể, hoạt động sẽ thất bại).

Trường hợp sử dụng & Ví dụ

• required: Lý tưởng cho các kịch bản muốn đăng nhập không cần tên người dùng hoặc nơi người dùng chỉ nên xác thực từ các thiết bị đã đăng ký trước đó (bằng cách thêm một lớp bảo mật bổ sung bằng cách liên kết thông tin xác thực của người dùng với một thiết bị cụ thể).
• preferred: Phù hợp cho các kịch bản mà dịch vụ web muốn cung cấp trải nghiệm đăng nhập tốt nhất có thể (thông qua khóa thường trú), nhưng vẫn muốn hỗ trợ khóa không thường trú nếu không thể tạo khóa thường trú.
• discouraged: Một dịch vụ muốn cung cấp xác thực bằng passkey và cũng muốn đảm bảo rằng người dùng có thể sử dụng bất kỳ trình xác thực nào, ngay cả những trình xác thực không có khả năng lưu trữ, mà không cần liên kết thông tin xác thực với một thiết bị cụ thể.

Xác minh người dùng đề cập đến quá trình đảm bảo người tương tác với trình xác thực là chủ sở hữu hợp pháp, thường bằng cách yêu cầu một cử chỉ xác thực cụ thể như nhập mã PIN, cung cấp dấu vân tay hoặc sử dụng nhận dạng khuôn mặt.

Đôi khi sự hiện diện của người dùng (User Presence - UP) cũng được đề cập hoặc sử dụng tương tự như xác minh người dùng nhưng thực sự có một số khác biệt. Sự hiện diện của người dùng chỉ xác nhận rằng có ai đó - bất kỳ ai - đang có mặt thực tế và tương tác với thiết bị. Nó không xác minh danh tính của người đó. Một cú chạm đơn giản vào khóa bảo mật, không có bất kỳ kiểm tra danh tính nào khác, có thể đủ cho sự hiện diện của người dùng. Đối với passkey / WebAuthn, người dùng luôn cần phải có mặt.

Các giá trị khả thi

• required: Hoạt động phải có xác minh người dùng.
• preferred: Hoạt động nên có xác minh người dùng nếu có thể, nhưng có thể tiếp tục mà không cần nó.
• discouraged: Hoạt động không nên có xác minh người dùng.

Trường hợp sử dụng & Ví dụ

• required: Lý tưởng cho các ứng dụng bảo mật cao như ngân hàng hoặc y tế, nơi việc xác minh danh tính của người dùng (ví dụ: thông qua dấu vân tay hoặc mã PIN) là rất quan trọng.
• preferred: Hữu ích cho các ứng dụng chung nơi bảo mật bổ sung là một điểm cộng nhưng không hoàn toàn cần thiết.
• discouraged: Phù hợp cho các hoạt động có rủi ro thấp hoặc các kịch bản mà xác minh người dùng có thể gây bất tiện.

Mẫu cài đặt

• authenticatorAttachment: platform
• residentKey: required
• User verification: required

Ví dụ: Một ứng dụng doanh nghiệp muốn nhân viên đăng nhập mà không cần mật khẩu trên máy tính xách tay do công ty cấp bằng cách sử dụng đầu đọc dấu vân tay tích hợp. Thông tin xác thực được lưu trữ trên thiết bị và người dùng phải xác minh bằng dấu vân tay mỗi lần.

Mẫu cài đặt

• authenticatorAttachment: cross-platform
• residentKey: required
• userVerification: required

Ví dụ: Một người dùng đăng ký một khóa bảo mật (ví dụ: YubiKey) cho tài khoản ngân hàng trực tuyến của họ. Họ có thể sử dụng khóa này để xác thực trên bất kỳ thiết bị nào bằng cách cung cấp khóa bảo mật (ví dụ: YubiKey), mà không cần phải nhập tên người dùng.

Nhiều khóa bảo mật dựa trên phần cứng (ví dụ: YubiKeys) có những hạn chế về lưu trữ vốn có. Hạn chế này là do bộ nhớ vật lý có sẵn trên thiết bị và các cân nhắc thiết kế của nhà sản xuất.

Ví dụ: Một YubiKey có thể có dung lượng để lưu trữ chỉ 20 khóa thường trú. Khi đạt đến giới hạn này, không thể thêm khóa thường trú nào khác mà không xóa các khóa hiện có.

Giải pháp:

• Sử dụng có chọn lọc khóa thường trú: Thay vì sử dụng khóa thường trú cho mọi người dùng, hãy xem xét chúng cho các vai trò hoặc kịch bản cụ thể. Ví dụ, ưu tiên khóa thường trú cho các vai trò quản trị viên hoặc người dùng có đặc quyền cao yêu cầu bảo mật nâng cao.
• Giáo dục người dùng: Thông báo cho người dùng về những hạn chế của khóa bảo mật của họ (ví dụ: YubiKeys). Khuyến khích họ chuyển sang các thiết bị có thể sử dụng khóa thường trú không giới hạn, ví dụ: máy tính xách tay hoặc điện thoại thông minh.

Các trình xác thực khác nhau có thể xử lý các yêu cầu khóa thường trú theo những cách khác nhau. Một số có thể mặc định tạo khóa thường trú ngay cả khi không được yêu cầu rõ ràng, trong khi những trình khác có thể yêu cầu chỉ dẫn rõ ràng.

Hành vi không nhất quán đối với các tùy chọn máy chủ WebAuthn khác nhau trên các nền tảng khác nhau là một vấn đề lớn. Ví dụ, iOS sẽ luôn tạo một khóa thường trú bất kể các tùy chọn máy chủ WebAuthn được truyền vào, trong khi Android yêu cầu sự đồng ý (ví dụ: với residentKey: preferred hoặc residentKey: required).

Bên cạnh hành vi, điều tồi tệ hơn là dựa trên dữ liệu được lưu trữ phía máy chủ, bạn không thể nói chắc chắn 100% liệu một thông tin xác thực được lưu trữ là khóa thường trú hay khóa không thường trú. Thay vào đó, bạn có thể thực hiện một số kiểm tra và thu hẹp nó (xem bên dưới), nhưng vẫn cần hy vọng rằng hành vi của thông tin xác thực là theo niềm tin của bạn.

Lý do đằng sau là có một đề xuất của WebAuthn để lưu trữ thông tin về loại thông tin xác thực (khóa thường trú hoặc khóa không thường trú) trong phần mở rộng thuộc tính thông tin xác thực (credential properties extension) (clientExtensionResults.credProps.rk là true hoặc false). Tuy nhiên, việc cung cấp thông tin này cho RP không được đảm bảo vì tất cả các phần mở rộng của WebAuthn là tùy chọn, ví dụ: iOS không gửi nó (vì vậy bạn không biết đó là khóa thường trú hay khóa không thường trú).

Trong quá trình nghiên cứu, chúng tôi đã cố gắng kiểm tra hành vi trên các nền tảng và trình xác thực khác nhau (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) với hai trang demo WebAuthn cung cấp thêm chi tiết về các thông tin xác thực được tạo: https://webauthn.io và https://webauthntest.identitystandards.io/. Trang sau cung cấp khả năng làm việc với thuộc tính requireResidentKey cũ (WebAuthn Cấp độ 1) và thậm chí kết hợp nó với thuộc tính residentKey (WebAuthn Cấp độ 2). Tuy nhiên, kết quả không đáng tin cậy (ví dụ: nó ghi là khóa không thường trú cho iOS nhưng rõ ràng là conditional UI đã hoạt động).

Lược đồ kiểm tra đáng tin cậy nhất chúng tôi tìm thấy là như sau:

1. Kiểm tra cài đặt máy chủ WebAuthn của bạn cho thuộc tính residentKey
   1. Nếu residentKey: required và một thông tin xác thực được tạo thành công -> đó là một khóa thường trú
   2. Nếu residentKey: preferred hoặc residentKey: discouraged, thì chuyển sang kiểm tra tiếp theo
2. Phần mở rộng credProps.rk có được hỗ trợ và lưu trữ trong thông tin xác thực trên máy chủ không?
   1. Nếu credProps.rk = true, thông tin xác thực là một khóa thường trú
   2. Nếu credProps.rk = false, thông tin xác thực là một khóa không thường trú
   3. Nếu credProps trống, thì loại thông tin xác thực không xác định

Như bạn có thể thấy, điều này giúp thu hẹp vấn đề, nhưng tùy chọn không xác định vẫn tồn tại và bạn không thể xác định loại khóa với độ chắc chắn 100%.

Điều này cũng phù hợp với những phát hiện của William Brown từ SUSE trong bài viết tuyệt vời của ông phác thảo cách các khóa bảo mật (ví dụ: YubiKeys) có thể trở nên vô dụng nếu các Relying Party yêu cầu khóa thường trú (chúng tôi đã mở rộng bảng của ông):

Trong bảng, bạn sẽ thấy đối với các tùy chọn khóa thường trú khác nhau của máy chủ WebAuthn, liệu một khóa thường trú đã được tạo (true), một khóa không thường trú đã được tạo (false) hay một điều gì đó khác đã xảy ra.

Giải pháp:

• Kiểm tra kỹ lưỡng: Trước khi triển khai, hãy kiểm tra việc triển khai WebAuthn của bạn trên một loạt các trình xác thực phổ biến để hiểu hành vi của chúng.
• Cài đặt máy chủ rõ ràng: Khi thiết lập máy chủ WebAuthn của bạn, hãy rõ ràng trong các yêu cầu của bạn. Nếu bạn chỉ muốn có passkey, hãy đặt tùy chọn residentKey thành required (lưu ý: điều này có thể dẫn đến các thách thức khác với các trình xác thực có dung lượng khóa thường trú hạn chế, xem ở trên).

Nếu người dùng đạt đến giới hạn lưu trữ trên khóa bảo mật của họ (ví dụ: YubiKey), họ có thể gặp lỗi hoặc không thể đăng ký thông tin xác thực mới. Điều này có thể dẫn đến sự nhầm lẫn và thất vọng.

Giải pháp:

• Xử lý lỗi một cách tinh tế: Triển khai các thông báo lỗi rõ ràng thông báo cho người dùng khi khóa bảo mật của họ (ví dụ: YubiKey) đã đầy và cung cấp hướng dẫn về cách giải quyết vấn đề.
• Luồng công việc có hướng dẫn: Cung cấp các hướng dẫn từng bước hoặc hướng dẫn về cách người dùng có thể quản lý các khóa thường trú của họ, đảm bảo họ có thể tự giải quyết các vấn đề.

9. Các phương pháp tốt nhất cho nhà phát triển và quản lý sản phẩm

Như bạn đã thấy ở trên, các cài đặt máy chủ WebAuthn bạn chọn có thể ảnh hưởng đáng kể đến trải nghiệm người dùng và bảo mật của quy trình xác thực của bạn. Việc hiểu rõ các sắc thái của những cài đặt này để đưa ra quyết định sáng suốt là điều cần thiết.

Khóa thường trú so với không thường trú: Nếu phần lớn người dùng của bạn chủ yếu truy cập dịch vụ của bạn từ các thiết bị cá nhân như điện thoại thông minh hoặc máy tính xách tay, khóa thường trú là một lựa chọn phù hợp. Khóa thường trú được lưu trữ trên chính thiết bị và cung cấp trải nghiệm xác thực liền mạch cho những người dùng thường xuyên sử dụng cùng một thiết bị. Tuy nhiên, đối với những người dùng sử dụng khóa bảo mật (ví dụ: YubiKeys), khóa không thường trú có thể phù hợp hơn.

Cài đặt xác minh người dùng (UV): Tùy thuộc vào mức độ bảo mật bạn muốn đạt được, bạn có thể quyết định quy trình xác minh người dùng nên nghiêm ngặt đến mức nào. Nếu bạn đang nhắm đến bảo mật cao, việc yêu cầu mã PIN, dấu vân tay hoặc nhận dạng khuôn mặt (userVerification: preferred hoặc userVerification: required) là điều nên làm.

Attestation và độ tin cậy: Attestation cho phép bạn xác minh nguồn gốc và tính toàn vẹn của trình xác thực. Hãy quyết định xem bạn muốn tin tưởng tất cả các trình xác thực hay chỉ những trình xác thực từ các nhà sản xuất cụ thể. Điều này có thể rất quan trọng nếu bạn đang xử lý dữ liệu nhạy cảm và muốn đảm bảo rằng chỉ những trình xác thực chất lượng cao, đáng tin cậy mới được sử dụng.

Cơ chế dự phòng: Luôn có một cơ chế dự phòng. Nếu người dùng mất trình xác thực hoặc nếu nó bị trục trặc, họ nên có một cách thay thế để truy cập vào tài khoản của mình. Điều này có thể thông qua mã dự phòng, xác minh SMS, liên kết ma thuật qua email hoặc các phương pháp xác thực đa yếu tố khác.

Giáo dục liên tục: Bối cảnh của passkey và WebAuthn đang liên tục phát triển. Hãy cập nhật những phát triển, lỗ hổng và các bản vá mới nhất. Khuyến khích nhóm phát triển của bạn tham gia các hội thảo, webinar và hội nghị liên quan đến passkey và WebAuthn.

Hướng dẫn và giáo dục người dùng: Khi giới thiệu xác thực bằng passkey, hãy đảm bảo rằng người dùng của bạn hiểu được lợi ích của nó và cách nó hoạt động. Cung cấp hướng dẫn rõ ràng trong quá trình đăng ký và cung cấp các tài nguyên (như câu hỏi thường gặp hoặc video hướng dẫn) để hỗ trợ người dùng thiết lập và sử dụng passkey.

Bằng cách tuân thủ các phương pháp tốt nhất này, các nhà phát triển và quản lý sản phẩm có thể đảm bảo rằng họ triển khai xác thực bằng passkey một cách hiệu quả, cân bằng cả bảo mật và trải nghiệm người dùng.

Nếu bạn muốn triển khai passkey để áp dụng rộng rãi trên trang web hoặc ứng dụng của mình và không cần hỗ trợ các khóa bảo mật (ví dụ: YubiKeys), vì hầu hết người dùng của bạn sẽ chỉ sử dụng điện thoại thông minh hoặc máy tính xách tay của họ, chúng tôi đề xuất các cài đặt sau.

• authenticator: platform
• residentKey: required
• userVerification: required

Lợi ích:

• Vì tất cả các khóa được tạo đều là khóa thường trú, thiết lập này cho phép sử dụng Conditional UI, giúp việc đăng nhập của bạn trở nên liền mạch hơn cho người dùng vì họ không phải nhớ tên người dùng.
• Tất cả các thiết bị hiện đại từ Apple, Google và Microsoft đều được hỗ trợ và sử dụng passkey.

Các cài đặt máy chủ của WebAuthn, mặc dù phức tạp, nhưng cung cấp một khuôn khổ mạnh mẽ và linh hoạt cho việc xác thực. Việc nắm vững các cài đặt này là rất quan trọng, vì nó không chỉ là việc triển khai một tiêu chuẩn mới; đó là việc cải thiện cơ bản về bảo mật và hiệu quả của xác thực người dùng.

Về cơ bản, việc hiểu các cài đặt máy chủ của WebAuthn là một khoản đầu tư vào việc xây dựng các ứng dụng an toàn hơn, hiệu quả hơn và hướng tới tương lai. Khi bối cảnh kỹ thuật số phát triển, việc thành thạo các công nghệ như vậy sẽ là điều không thể thiếu. Để cập nhật, hãy tham gia cộng đồng passkey của chúng tôi hoặc đăng ký nhận bản tin của chúng tôi bên dưới.