Hiểu về Chính sách bảo vệ thông tin xác thực WebAuthn
Bài viết này phân tích về chính sách bảo vệ thông tin xác thực WebAuthn trong CTAP 2.1, giúp các nhà phát triển kiểm soát việc phát hiện và sử dụng khóa bảo mật để ngăn chặn việc soi mói dữ liệu. Nó cũng đi sâu vào các mức độ bảo mật khác nhau, sự hỗ trợ của trình duyệt và cách cấu hình chính sách để đảm bảo an toàn tối đa cho người dùng.

Hiểu về Chính sách bảo vệ thông tin xác thực WebAuthn
Bài viết này giả định rằng bạn đã nắm được những kiến thức cơ bản về WebAuthn.
Khi tạo một thông tin xác thực WebAuthn, bạn có thể chỉ định xem liệu nó có nên được phát hiện hay không thông qua tùy chọn residentKey.
const credential = await navigator.credentials.create({
publicKey: {
authenticatorSelection: {
residentKey: "required",
// ...
},
// ...
},
});
Tuy nhiên, bên phụ thuộc (relying party - thường là máy chủ) không thể kiểm soát khi nào hoặc cách thức thông tin xác thực được phát hiện. Bạn có thể muốn nó chỉ có thể được phát hiện sau khi người dùng được xác minh (user verification), từ đó ẩn đi sự tồn tại của tài khoản trước những kẻ tò mò. Điều này đặc biệt quan trọng đối với các khóa bảo mật (security keys); vì không giống như các thiết bị hoặc trình quản lý mật khẩu thường yêu cầu xác thực ban đầu, chỉ việc sở hữu vật lý khóa thường là đủ để tiết lộ các thông tin xác thực đã đăng ký.
Để giải quyết vấn đề này, thông số kỹ thuật CTAP 2.1 định nghĩa một tiện ích mở rộng chính sách bảo vệ thông tin xác thực mới, có sẵn thông qua đầu vào mở rộng credentialProtectionPolicy. CTAP là thông số kỹ thuật định nghĩa cách các nền tảng (thiết bị/trình duyệt) và bộ xác thực di động (khóa bảo mật) tương tác với nhau.
const credential = await navigator.credentials.create({
publicKey: {
extensions: {
credentialProtectionPolicy: "userVerificationRequired",
enforceCredentialProtectionPolicy: true,
},
// ...
},
});
Nếu sử dụng giá trị mặc định userVerificationOptional, thông tin xác thực có thể được phát hiện và sử dụng mà không cần xác minh của người dùng. Nếu sử dụng userVerificationOptionalWithCredentialIDList, thông tin xác thực không thể được phát hiện mà không có xác minh của người dùng, nhưng nó vẫn có thể được phát hiện và sử dụng mà không cần xác minh nếu ID thông tin xác thực được cung cấp bởi bên phụ thuộc. Điều này tương đương với mức độ bảo mật của các thông tin xác thực không thể phát hiện. Cuối cùng, userVerificationRequired chỉ định rằng thông tin xác thực không thể được phát hiện hay sử dụng mà không có xác minh của người dùng.
Điều quan trọng cần nhấn mạnh là tiện ích mở rộng này kiểm soát việc phát hiện thông tin xác thực bên trong bộ xác thực. Việc xác minh xem xác nhận (assertion) có được thực hiện với xác minh của người dùng hay không vẫn là trách nhiệm của bên phụ thuộc nếu họ yêu cầu điều đó.
Đầu vào mở rộng liên quan enforceCredentialProtectionPolicy cấu hình hành động cần thực hiện nếu bộ xác thực không hỗ trợ chính sách bảo vệ thông tin xác thực. Nếu được đặt là true, thao tác sẽ thất bại nếu không thể tạo thông tin xác thực ở mức bảo mật được chỉ định.
Lưu ý rằng nếu bạn sử dụng bộ xác thực không di động (non-roaming authenticator) không hỗ trợ credentialProtectionPolicy nhưng trình duyệt có hỗ trợ, yêu cầu sẽ bị từ chối. Do đó, tùy chọn này chỉ nên được đặt là true nếu bạn muốn cho phép các bộ xác thực di động.
Về việc hỗ trợ các đầu vào mở rộng của trình duyệt, Chrome và Firefox hỗ trợ chúng, trong khi Safari không hỗ trợ và sẽ đơn giản bỏ qua chúng.
Các trình duyệt cũng có thể âm thầm áp dụng một giá trị mặc định nếu bên phụ thuộc không chỉ định một giá trị nào, và trường hợp này cụ thể xảy ra ở Chrome.
Nếu residentKey là preferred hoặc required, Chrome sẽ sử dụng userVerificationOptionalWithCredentialIDList. Như đã lưu ý, điều này giúp ngăn chặn người nào đó có quyền truy cập vật lý vào bộ xác thực nhìn thấy các tài khoản nào đã được đăng ký trên đó.
Nếu residentKey là required và userVerification là preferred, Chrome sẽ sử dụng userVerificationRequired thay thế. Phần gây nhầm lẫn ở đây là điều này không liên quan đến việc phát hiện thông tin xác thực, mà đóng vai trò là một biện pháp an toàn để thực thi xác minh người dùng. Chrome giả định rằng thông tin xác thực có khả năng sẽ được sử dụng như một bước xác thực duy nhất, vì preferred thường được sử dụng ngay cả cho xác thực passkey.
Tuy nhiên, vì xác minh người dùng vẫn là tùy chọn và việc kiểm tra nó phụ thuộc vào bên phụ thuộc, nếu máy chủ không thực thi đúng xác minh người dùng trong quá trình xác thực, ai đó có thể đăng nhập dưới tư cách người dùng chỉ với quyền truy cập vật lý vào bộ xác thực.
Hành vi cụ thể này được ghi lại trong tài liệu của Chromium.
Bài viết liên quan

Phần mềm
Cha đẻ của curl kêu gọi ưu tiên "xác minh" thay vì "tin tưởng" trong chuỗi cung ứng phần mềm
07 tháng 5, 2026

Công nghệ
Google ra mắt Gmail Live: Giờ đây bạn có thể 'nói chuyện' trực tiếp với hộp thư nhờ AI
19 tháng 5, 2026

Phần mềm
Runtime ra mắt hạ tầng sandbox cho coding agents, giúp toàn bộ đội ngũ phát triển phần mềm an toàn
21 tháng 5, 2026
