Passkeys & WebAuthn PRF cho Mã hóa End-to-End (2025)

WebAuthn & Passkeys đã cách mạng hóa việc xác thực web, cung cấp các phương thức đăng nhập không cần mật khẩu, chống lừa đảo thông qua mật mã khóa công khai. Nhưng khả năng của nó không chỉ dừng lại ở việc đăng nhập. Một tính năng thú vị là tiện ích mở rộng Hàm giả ngẫu nhiên (Pseudo-Random Function - PRF) của WebAuthn. Tiện ích mở rộng này cho phép các ứng dụng web lấy khóa bí mật trực tiếp từ passkey hoặc khóa bảo mật phần cứng của người dùng trong quá trình xác thực. Điều này mở ra khả năng mã hóa dữ liệu end-to-end hoặc giải mã một kho lưu trữ an toàn chỉ bằng passkey của bạn, mà không cần một mật khẩu riêng. Trong bài viết này, chúng ta sẽ trả lời các câu hỏi sau:

• Các trường hợp sử dụng Passkey PRF: Những trường hợp sử dụng thú vị nào để dùng tiện ích mở rộng WebAuthn PRF?
• Hỗ trợ tiện ích mở rộng PRF: Tình hình hỗ trợ thực tế của tiện ích mở rộng WebAuthn PRF trên các hệ điều hành và trình duyệt hiện nay là gì?

Bài viết này phân tích tiện ích mở rộng WebAuthn PRF, khám phá các thông số kỹ thuật, trường hợp sử dụng, chi tiết triển khai, các cân nhắc về bảo mật và bối cảnh hỗ trợ hiện tại của trình duyệt và hệ điều hành. Chúng ta tập trung vào những thay đổi trong hệ sinh thái năm 2025 và mở rộng dựa trên nền tảng đã được đặt ra bởi Matthew Miller và Levi Schuck vào năm 2023, những bài viết trước đó của họ cung cấp nền tảng kỹ thuật chi tiết, ví dụ trực tiếp và các bài kiểm tra trực tuyến (bao gồm cả mã hóa).

Tiện ích mở rộng WebAuthn PRF (PRF) được định nghĩa chính thức trong đặc tả WebAuthn Level 3. Mục đích cốt lõi của nó là cho phép một Bên tin cậy (Relying Party) (ứng dụng web của bạn) yêu cầu đánh giá một hàm giả ngẫu nhiên được liên kết với một thông tin xác thực WebAuthn cụ thể (passkey) trong một quy trình xác thực (navigator.credentials.get()).

Một PRF lấy một khóa bí mật (được giữ an toàn bên trong trình xác thực và gắn với thông tin xác thực) và một hoặc nhiều giá trị đầu vào (do Bên tin cậy cung cấp) để tạo ra một đầu ra xác định, trông có vẻ ngẫu nhiên về mặt mật mã. Đầu ra này, thường là một chuỗi 32 byte, sau đó có thể được ứng dụng phía máy khách sử dụng, đáng chú ý nhất là làm vật liệu khóa đối xứng cho mã hóa WebAuthn hoặc tạo khóa.

Nhiều trình xác thực, đặc biệt là các khóa bảo mật FIDO2, triển khai một khả năng cơ bản được định nghĩa trong Giao thức từ Máy khách đến Trình xác thực (CTAP2) gọi là tiện ích mở rộng hmac-secret. Tiện ích mở rộng CTAP2 này cung cấp quyền truy cập vào một hàm HMAC (Mã xác thực tin nhắn dựa trên hàm băm) được hỗ trợ bởi phần cứng, đóng vai trò là hàm giả ngẫu nhiên. Tiện ích mở rộng WebAuthn PRF hoạt động như một cách tiêu chuẩn hóa để các ứng dụng web truy cập khả năng hmac-secret này thông qua API WebAuthn của trình duyệt.

Để ngăn chặn các xung đột tiềm ẩn hoặc các vấn đề bảo mật khi một trang web có thể lừa trình xác thực tạo ra các HMAC dành cho các mục đích không phải web (như đăng nhập hệ điều hành cục bộ), đặc tả WebAuthn yêu cầu một bước quan trọng: các đầu vào do trang web cung cấp (salt thứ nhất và thứ hai) trước tiên được băm với một chuỗi ngữ cảnh cụ thể ("WebAuthn PRF" và một byte null) trước khi được chuyển đến hàm hmac-secret cơ bản. Điều này phân chia hiệu quả không gian đầu vào của PRF, đảm bảo rằng các đầu ra có nguồn gốc từ web khác biệt với những đầu ra có thể được sử dụng trong các ngữ cảnh khác.

Khả năng tạo ra các khóa gắn liền với trình xác thực mở ra một số trường hợp sử dụng hấp dẫn cho các nhà phát triển:

1. Mã hóa phía máy khách / End-to-End (E2EE): Đây là động lực chính cho tiện ích mở rộng WebAuthn PRF. Các ứng dụng dựa trên trình duyệt có thể tạo ra một khóa mã hóa duy nhất cho mỗi thông tin xác thực trong khi đăng nhập. Khóa này sau đó có thể được sử dụng với WebCrypto API để mã hóa dữ liệu người dùng được lưu trữ cục bộ hoặc trên máy chủ. Dữ liệu vẫn được mã hóa khi lưu trữ và chỉ có thể được giải mã bởi người dùng sau khi xác thực thành công với passkey cụ thể, tăng cường quyền riêng tư và bảo mật dữ liệu. Các nhà cung cấp dịch vụ có thể lưu trữ dữ liệu người dùng mà không bao giờ có quyền truy cập vào bản rõ. Điều này đặc biệt hữu ích cho các ứng dụng trong thế giới không mật khẩu, vì nếu không có tiện ích mở rộng PRF, họ sẽ cần yêu cầu thêm một bí mật dưới dạng mật khẩu, điều này mâu thuẫn với kiến trúc không mật khẩu.

2. Giải mã kho lưu trữ không cần mật khẩu: Các dịch vụ như trình quản lý mật khẩu (ví dụ: Bitwarden, 1Password) hoặc các ứng dụng ghi chú an toàn (ví dụ: Notesnook, Reflect) có thể sử dụng PRF để thay thế mật khẩu chủ truyền thống. Người dùng xác thực bằng passkey của họ, tiện ích mở rộng PRF tạo ra khóa giải mã kho lưu trữ và kho được mở khóa - không cần mật khẩu chủ. Bitwarden đã công bố hỗ trợ cho tính năng này. Hơn nữa, Dashlane gần đây đã áp dụng tiện ích mở rộng WebAuthn PRF để tăng cường khả năng chống lừa đảo và nâng cao bảo mật khi truy cập các kho lưu trữ được mã hóa. Người dùng xác thực bằng passkey của họ, cho phép PRF tạo khóa giải mã kho một cách an toàn, loại bỏ hoàn toàn nhu cầu về mật khẩu chủ.

3. Xoay vòng khóa an toàn: Tiện ích mở rộng WebAuthn PRF cho phép cung cấp hai "salt" đầu vào (thứ nhất và thứ hai) trong quá trình xác thực. Điều này tạo điều kiện cho các cơ chế xoay vòng khóa mật mã. Một máy chủ có thể yêu cầu khóa "hiện tại" bằng cách sử dụng salt thứ nhất và khóa "tiếp theo" bằng cách sử dụng salt thứ hai. Theo thời gian, máy chủ có thể cập nhật salt nào tương ứng với khóa hiện tại, cho phép xoay vòng liền mạch mà không làm gián đoạn trải nghiệm người dùng. Điều này đặc biệt quan trọng trong trường hợp các yêu cầu quy định hoặc chính sách nội bộ yêu cầu tất cả các khóa phải được xoay vòng trong một lịch trình cụ thể và tăng cường bảo mật.

4. Ví nhận dạng & Hệ thống không lưu ký: PRF có thể tạo ra các khóa để bảo mật dữ liệu nhận dạng trong các ví kỹ thuật số hoặc cho phép các hệ thống không lưu ký nơi các khóa riêng tư không bao giờ bị lộ phía máy chủ.

Trong khi đặc tả đã được định nghĩa, sự hỗ trợ thực tế của trình duyệt và nền tảng là yếu tố quan trọng đối với các nhà phát triển. Hỗ trợ đã và đang phát triển và cho đến gần đây, chủ yếu chỉ giới hạn ở các trình duyệt dựa trên Chromium. Việc theo dõi hỗ trợ có thể là một thách thức vì không có mục riêng trên CanIUse.com cho chính tiện ích mở rộng PRF (tìm kiếm "webauthn" cho thấy hỗ trợ API chung, nhưng không phải các tiện ích mở rộng cụ thể). Thông tin thường phải được thu thập từ ghi chú phát hành của trình duyệt, trình theo dõi lỗi và các trang trạng thái. Để sử dụng thành công tiện ích mở rộng WebAuthn PRF, cần có sự phối hợp đồng bộ giữa ba lớp riêng biệt của ngăn xếp công nghệ. Hỗ trợ tiện ích mở rộng PRF phải có mặt ở mỗi cấp độ để tính năng này hoạt động:

1. Trình xác thực (The Authenticator): Đây là thành phần phần cứng (như khóa bảo mật) hoặc thành phần nền tảng (như Windows Hello, iCloud Keychain và mô-đun phần cứng tương ứng, ví dụ: TPM hoặc Secure Enclave) lưu trữ an toàn khóa bí mật của thông tin xác thực và thực hiện phép tính hàm giả ngẫu nhiên thực tế (thường sử dụng khả năng CTAP2 hmac-secret). Nếu trình xác thực thiếu khả năng mật mã cơ bản này, PRF không thể hoạt động.

2. Hệ điều hành (The Operating System - OS): HĐH hoạt động như cầu nối giữa trình duyệt và trình xác thực. Nó cung cấp các trình điều khiển cần thiết và các API cấp hệ thống để trình duyệt khám phá, giao tiếp và yêu cầu các hoạt động từ trình xác thực (đặc biệt là các trình xác thực nền tảng và những trình được kết nối qua USB/NFC/Bluetooth). HĐH phải có khả năng nhận dạng và hiển thị khả năng PRF (hmac-secret) của trình xác thực cho trình duyệt. Nếu HĐH không cung cấp đường dẫn này, trình duyệt không thể truy cập tính năng.

3. Trình duyệt (The Browser): Là giao diện cho ứng dụng web, trình duyệt phải triển khai API JavaScript WebAuthn, đặc biệt là nhận dạng tiện ích mở rộng prf, dịch yêu cầu web thành các lệnh thích hợp cho HĐH/trình xác thực, xử lý bước bảo mật quan trọng là băm các đầu vào với chuỗi ngữ cảnh, và phân tích cú pháp chính xác và trả về kết quả cho ứng dụng.

Sự thất bại hoặc thiếu hỗ trợ ở bất kỳ cấp nào trong ba cấp này—khả năng của Trình xác thực, sự hiển thị của HĐH, hoặc việc triển khai của Trình duyệt—sẽ ngăn cản tiện ích mở rộng PRF hoạt động.

Biểu đồ tuần tự này cho thấy một phiên bản đơn giản hóa về cách các tác nhân này làm việc cùng nhau để tạo điều kiện hỗ trợ PRF.

Một quy trình làm việc PRF hoạt động đòi hỏi mọi lớp trong chuỗi WebAuthn ↔ CTAP phải hợp tác. Để rõ ràng, chúng ta tách cuộc thảo luận thành (1) hành vi của trình duyệt + hệ điều hành và (2) hành vi của trình xác thực.

Hành trình hướng tới hỗ trợ PRF rộng rãi nêu bật một thách thức chung với các tiện ích mở rộng tiêu chuẩn web: việc triển khai thường bị so le, với các vấn đề cụ thể của nền tảng cần được giải quyết. Chúng tôi sẽ cố gắng cập nhật bảng này, nhưng hãy nhớ rằng vì tiện ích mở rộng PRF là một trong những bổ sung mới nhất đòi hỏi toàn bộ chuỗi tương thích phải thích ứng, nên các điều chỉnh liên tục là điều được mong đợi.

Dưới đây, chúng tôi phân tích hỗ trợ theo hệ điều hành.

Hỗ trợ cho tiện ích mở rộng WebAuthn PRF trên Windows còn hạn chế, vì trình xác thực nền tảng gốc (Windows Hello) hiện thiếu khả năng hmac-secret cần thiết. Do đó, chức năng PRF phụ thuộc vào các khóa bảo mật bên ngoài.

Với macOS 15, hỗ trợ PRF đã có mặt cho các trình xác thực nền tảng. Cả Safari và Chrome đều hỗ trợ PRF qua iCloud Keychain. Hỗ trợ của Firefox cho trình xác thực nền tảng vẫn đang chờ xử lý. Khóa bảo mật chỉ hoạt động với Chrome.

Tình trạng trên iOS và iPadOS tương tự như macOS, với PRF hoạt động qua iCloud Keychain. Tuy nhiên, có những lưu ý quan trọng: một lỗi trong các phiên bản đầu của iOS 18 có thể dẫn đến mất dữ liệu, và hỗ trợ cho các khóa bảo mật bên ngoài vẫn chưa được triển khai.

Android hiện cung cấp sự hỗ trợ mạnh mẽ và rộng rãi nhất cho tiện ích mở rộng WebAuthn PRF. Các passkey được lưu trữ trong Google Password Manager bao gồm hỗ trợ PRF theo mặc định, và nó hoạt động trên hầu hết các trình duyệt lớn, ngoại trừ Firefox.

Trong bảng trên, chúng tôi đã bao gồm các kết hợp quan trọng nhất cho hỗ trợ nhà cung cấp passkey bên thứ nhất. Tuy nhiên, khi sử dụng các trình quản lý mật khẩu làm nhà cung cấp passkey bên thứ ba, các khả năng cụ thể của chúng phải được xem xét riêng. Ví dụ, 1Password hỗ trợ PRF trong phiên bản Android nhưng không hỗ trợ trong phiên bản iOS. Ngoài ra, Chrome Profile với vai trò là trình xác thực không hỗ trợ prf. Để biết thêm chi tiết về các trình xác thực, xem bên dưới.

Trong khi WebAuthn chỉ định cái gì mà một Bên tin cậy có thể yêu cầu, Giao thức từ Máy khách đến Trình xác thực (CTAP) định nghĩa cách trình xác thực phải hoạt động. Trong thực tế, các trình xác thực được chia thành bốn loại:

1. Không hỗ trợ PRF: Các trình xác thực nền tảng cũ hơn (ví dụ: Windows Hello), các khóa bảo mật cũ không có tiện ích mở rộng hmac-secret và các nhà cung cấp bên thứ ba chưa áp dụng tiện ích mở rộng prf.

2. PRF chỉ khi cờ PRF được đặt lúc tạo thông tin xác thực: Một số khóa bảo mật CTAP 2.0/2.1 có hmac-secret, nhưng sẽ từ chối các đánh giá PRF trừ khi Bên tin cậy đã yêu cầu nó khi thông tin xác thực được tạo lần đầu để khởi tạo các bí mật.

3. PRF có sẵn khi xác thực ngay cả khi không được yêu cầu lúc tạo: Các token phần cứng thế hệ mới và iCloud và Google Password Manager hiển thị chức năng hmac-secret một cách vô điều kiện; các thông tin xác thực được tạo mà không có cờ vẫn hoạt động với PRF trong navigator.credentials.get().

4. Tuân thủ đầy đủ CTAP 2.2 (PRF + giá trị PRF đầu tiên khi tạo): Các trình xác thực nền tảng đồng bộ hóa passkey—chẳng hạn như iCloud Keychain và Google Password Manager—có thể, theo yêu cầu, trả về đầu ra PRF đầu tiên ngay trong navigator.credentials.create(), giúp tinh giản các luồng thiết lập khóa.

Biết được một trình xác thực thuộc nhóm nào là điều cần thiết khi bạn thiết kế logic sao lưu, di chuyển hoặc thiết lập khóa. Chúng tôi cũng đã bao gồm các bài kiểm tra cho các kịch bản này trong demo của mình.

Bạn có thể trải nghiệm trực tiếp tiện ích mở rộng WebAuthn PRF bằng ứng dụng demo WebAuthn PRF tương tác của chúng tôi. Trong demo này, bạn sẽ có thể:

• Đăng ký một passkey với PRF và xác nhận xem trình xác thực của bạn có hỗ trợ tiện ích mở rộng mạnh mẽ này không.
• Xác thực bằng passkey của bạn và xem giá trị mật mã do PRF tạo ra đang hoạt động.

Việc tự mình nhìn thấy giá trị PRF làm nổi bật những ý nghĩa thực tế của việc sử dụng passkey cho các hoạt động an toàn, dựa trên khóa. Nó cho phép bạn xác minh trực tiếp khả năng tương thích của trình xác thực đối với tiện ích mở rộng PRF và quan sát cách các khóa có nguồn gốc từ PRF có thể cung cấp năng lượng cho mã hóa end-to-end WebAuthn và giải mã kho lưu trữ an toàn mà không cần mật khẩu.

Hãy dành một chút thời gian để thử demo, việc hiểu rõ khả năng PRF của môi trường cụ thể của bạn sẽ giúp bạn lập kế hoạch tốt hơn cho các trải nghiệm an toàn, không cần mật khẩu được thiết kế riêng cho người dùng của mình.

Sẵn sàng để kiểm tra sức mạnh của PRF? Nhấp vào hình ảnh trên hoặc theo liên kết này để bắt đầu khám phá thực hành của bạn.

Tiện ích mở rộng WebAuthn PRF không phải là tiện ích mở rộng WebAuthn duy nhất liên quan đến việc lưu trữ hoặc tạo dữ liệu. Passkey PRF so sánh như thế nào?

• PRF so với credBlob / largeBlob:

  • credBlob: Cho phép lưu trữ một blob tĩnh nhỏ (32 byte) cùng với thông tin xác thực, có thể tại thời điểm tạo. Nó không được thiết kế chủ yếu cho các bí mật, và hỗ trợ còn hạn chế, đặc biệt đối với các thông tin xác thực không thể phát hiện.

  • largeBlob: Cho phép lưu trữ nhiều dữ liệu hơn (~1KB) với các thông tin xác thực có thể phát hiện, thường dành cho dữ liệu phụ trợ như chứng chỉ. Hỗ trợ cũng hạn chế (được hỗ trợ bởi iCloud Keychain kể từ iOS 17, nhưng không được GPM hỗ trợ). Các nhà phát triển Chrome đã rõ ràng ủng hộ việc tập trung vào PRF hơn là largeBlob cho hầu hết các trường hợp sử dụng, mặc dù việc phát triển có thể xảy ra trong tương lai.

  • PRF: Ngược lại, PRF được thiết kế đặc biệt để tạo ra các khóa bí mật theo yêu cầu trong quá trình xác thực bằng cách sử dụng một bí mật gắn với phần cứng, thay vì lưu trữ một blob tĩnh. Nó thường được coi là cơ chế tiêu chuẩn phù hợp và an toàn nhất để tạo ra các khóa mã hóa gắn với một passkey. Sự phát triển từ việc thảo luận về blob cho các bí mật đến việc tiêu chuẩn hóa và tập trung triển khai vào PRF cho thấy sự hội tụ vào PRF như là giải pháp chuyên dụng cho trường hợp sử dụng này.

• PRF so với Khóa có nguồn gốc từ Mật khẩu (ví dụ: PBKDF2): Theo truyền thống, các khóa mã hóa phía máy khách được tạo ra từ mật khẩu của người dùng. PRF mang lại những lợi thế đáng kể:

  • Nguồn mạnh hơn: Các khóa được tạo ra từ vật liệu mật mã mạnh bên trong trình xác thực, không phải từ các mật khẩu có thể yếu hoặc được tái sử dụng.

  • Chống lừa đảo: Việc tạo khóa được gắn với luồng xác thực WebAuthn chống lừa đảo.

  • Không mật khẩu: Cho phép các trường hợp sử dụng như giải mã kho lưu trữ mà không cần mật khẩu.

• PRF so với Dữ liệu WebAuthn khác: Cố gắng tạo khóa từ các phần khác của phản hồi WebAuthn (như chữ ký, authenticatorData, hoặc khóa công khai) là không an toàn và không chính xác về cơ bản. Các thành phần này hoặc là công khai, không bí mật, hoặc được thiết kế để xác minh, không phải để tạo khóa.

Để tạo ra vật liệu khóa mật mã một cách an toàn được liên kết trực tiếp với một thông tin xác thực WebAuthn hoặc passkey, tiện ích mở rộng WebAuthn PRF là phương pháp tiêu chuẩn được xây dựng có mục đích và được khuyến nghị.

Khi tích hợp tiện ích mở rộng PRF vào ứng dụng của bạn, hãy xem xét các hướng dẫn thực tế sau:

Các khuyến nghị sau đây giúp các nhà phát triển điều hướng hiệu quả trạng thái hiện tại của hỗ trợ tiện ích mở rộng PRF và lập kế hoạch cho các phát triển trong tương lai:

• Coi PRF là một cơ hội: Hỗ trợ cho tiện ích mở rộng WebAuthn PRF hiện đang thay đổi đáng kể giữa các trình duyệt, hệ điều hành và trình xác thực. Do đó, hãy coi việc tích hợp PRF như một sự nâng cấp thay vì một sự phụ thuộc cốt lõi.

• Tránh phụ thuộc quan trọng vào PRF: Tránh làm cho PRF trở nên thiết yếu cho các chức năng quan trọng. Hỗ trợ hiện tại, đặc biệt trên các nền tảng như Safari trên macOS và iOS, vẫn còn không nhất quán và chưa hoàn chỉnh.

• Chuẩn bị cho các kịch bản mất Passkey: Hãy nhớ rằng dữ liệu được mã hóa bằng các khóa có nguồn gốc từ PRF chỉ gắn liền với passkey cụ thể đó. Mất passkey sẽ làm cho dữ liệu được mã hóa không thể truy cập vĩnh viễn. Luôn triển khai các cơ chế sao lưu và phục hồi mạnh mẽ.

• Dự đoán hỗ trợ rộng rãi hơn vào năm 2026: Hỗ trợ tiện ích mở rộng PRF đang phát triển nhanh chóng. Đến năm 2026, hãy dự đoán sự sẵn có nhất quán trên các trình duyệt, hệ điều hành và trình xác thực lớn, đặc biệt là với các nhà cung cấp passkey bên thứ nhất.

• Theo dõi hệ sinh thái Windows: Hỗ trợ trình xác thực nền tảng qua Windows Hello hiện không có. Việc tích hợp PRF đầy đủ trong môi trường Windows phụ thuộc nhiều vào chiến lược áp dụng của Microsoft, vì vậy hãy theo dõi chặt chẽ hệ sinh thái này.

Việc tuân theo các hướng dẫn này đảm bảo các nhà phát triển có thể tích hợp PRF một cách trơn tru trong khi vẫn duy trì khả năng tương thích và bảo mật trong giai đoạn áp dụng của nó.

Hiểu cách PRF phù hợp với chiến lược passkey tổng thể của bạn sẽ giúp bạn tối đa hóa lợi ích của nó mà không có những phức tạp không cần thiết:

• Tích hợp linh hoạt: Không cần thiết phải quyết định có nên tận dụng PRF tại thời điểm tạo passkey hay không. Các passkey hiện có sau này có thể được tích hợp liền mạch với các trường hợp sử dụng PRF mà không cần thêm chi phí quản lý thông tin xác thực.

• Trang bị thêm PRF: Vì PRF hoạt động trong giai đoạn xác thực (navigator.credentials.get()), các passkey đã được tạo trước đó có thể hỗ trợ các quy trình làm việc dựa trên PRF ở giai đoạn sau. Điều này cho phép ứng dụng của bạn tăng cường bảo mật một cách từ từ mà không làm gián đoạn các phương thức xác thực đã được thiết lập. Cách tiếp cận này hoạt động với iCloud Keychain và Google Password Manager (GPM) và các khóa bảo mật mới hơn. Đối với các khóa bảo mật cũ hơn, một hmac-secret có thể chỉ được tạo ra nếu được yêu cầu khi tạo thông tin xác thực.

• Cân nhắc về sự phức tạp của Passkey: Những sự phức tạp vốn có trong quản lý passkey—chẳng hạn như đồng bộ hóa thông tin xác thực, xác thực chéo thiết bị và các quy trình phục hồi—cũng áp dụng tương tự khi sử dụng PRF. Đảm bảo việc triển khai PRF của bạn phù hợp một cách chặt chẽ với chiến lược xác thực passkey tổng thể của bạn, duy trì trải nghiệm người dùng được tinh giản và các biện pháp kiểm soát bảo mật mạnh mẽ.

Xem xét PRF như một phần của chiến lược passkey toàn diện cho phép chuyển đổi mượt mà hơn sang các phương pháp xác thực an toàn và thân thiện với người dùng hơn.

Đối với các nhà cung cấp dịch vụ doanh nghiệp xử lý dữ liệu người dùng nhạy cảm, khả năng tận dụng WebAuthn PRF cùng với passkey mở ra các khả năng tăng cường bảo mật và trải nghiệm người dùng, đặc biệt trong các kịch bản yêu cầu mã hóa phía máy khách Thông tin nhận dạng cá nhân (PII) hoặc bảo mật các ứng dụng yêu cầu Mã hóa End-2-End. Mặc dù Corbado Connect chủ yếu được thiết kế để tích hợp passkey doanh nghiệp liền mạch, nó cũng có thể tạo điều kiện cho việc triển khai các tiện ích mở rộng passkey như SPC hoặc PRF.

Đây là cách Corbado có thể hỗ trợ các tổ chức muốn tích hợp PRF:

• Tạo điều kiện cho PRF để lưu trữ được mã hóa: Trong môi trường doanh nghiệp, đôi khi có yêu cầu lưu trữ thông tin nhạy cảm một cách an toàn, thậm chí đôi khi trực tiếp ở phía máy khách để giảm thiểu việc lộ PII phía máy chủ. Corbado Connect có thể được cấu hình để yêu cầu các giá trị PRF trong luồng xác thực passkey (navigator.credentials.get()), cho phép các ứng dụng tạo ra các khóa mật mã cần thiết.
• Các mẫu lưu trữ linh hoạt: Dữ liệu được mã hóa bằng các khóa có nguồn gốc từ PRF có thể được lưu trữ theo nhiều cách khác nhau tùy thuộc vào yêu cầu bảo mật và kiến trúc:
  • Phía máy khách: Được lưu trữ trực tiếp trong trình duyệt bằng các cơ chế như localStorage hoặc Cookie an toàn. Dữ liệu bản rõ chỉ tồn tại tạm thời trên máy khách trong quá trình giải mã.
  • Backend của Corbado (E2EE): Mặc dù Corbado thường tránh lưu trữ PII của khách hàng, cơ chế PRF về mặt kỹ thuật cho phép lưu trữ dữ liệu được mã hóa phía máy khách trên máy chủ của Corbado. Corbado sẽ không sở hữu các khóa để giải mã dữ liệu này; việc giải mã vẫn sẽ diễn ra phía máy khách sau khi xác thực người dùng thành công.
  • Backend của khách hàng: Dữ liệu được mã hóa cũng có thể được gửi đến và lưu trữ trên các hệ thống backend của chính doanh nghiệp, vẫn được hưởng lợi từ việc mã hóa phía máy khách.
• Luồng tạo khóa an toàn: Các thành phần của Corbado Connect quản lý sự tương tác với API WebAuthn. Khi PRF được yêu cầu:
  1. Một đầu ra PRF dành riêng cho người dùng được tạo ra bởi trình xác thực, gắn với passkey cá nhân.
  2. Đầu ra này được trả về an toàn cho ứng dụng phía máy khách.
  3. Ứng dụng sau đó nên sử dụng một Hàm tạo khóa (KDF) qua WebCrypto API (ví dụ: HKDF) để tạo ra một khóa mã hóa đối xứng mạnh mẽ từ đầu ra PRF.
  4. Khóa đối xứng này được sử dụng với WebCrypto (ví dụ: AES-GCM) để mã hóa hoặc giải mã thông tin mục tiêu (như PII).
• Giải mã liền mạch trong các lần đăng nhập tiếp theo: Khi người dùng xác thực lại bằng cùng một passkey, Corbado Connect sẽ khởi tạo cùng một yêu cầu PRF. Điều này tạo ra cùng một đầu ra PRF, cho phép ứng dụng tạo lại cùng một khóa đối xứng và giải mã thông tin đã được lưu trữ trước đó ở phía máy khách.
• Thông tin về việc áp dụng PRF: Việc triển khai PRF đòi hỏi phải biết liệu môi trường của người dùng (HĐH, trình duyệt, trình xác thực) có hỗ trợ nó hay không. Corbado Connect thu thập các tín hiệu về thiết bị và khả năng của người dùng trong quá trình xác thực. Thông tin này có thể được sử dụng để:
  • Xác định sự sẵn sàng của PRF trên toàn bộ cơ sở người dùng trước khi kích hoạt hoàn toàn các tính năng phụ thuộc vào PRF.
  • Triển khai PRF một cách cơ hội, cung cấp nó như một sự nâng cấp cho những người dùng được hỗ trợ trong khi duy trì các cơ chế dự phòng (như nhắc xác minh lại hoặc sử dụng các phương pháp thay thế) cho những người không có hỗ trợ.
• Tinh giản tính sẵn có của PII: Bằng cách sử dụng PRF để mã hóa PII đã được xác minh (ví dụ: các thuộc tính nhận dạng thu được qua một luồng xác minh) và lưu trữ nó phía máy khách, các ứng dụng có thể làm cho dữ liệu này có sẵn ngay lập tức sau một lần đăng nhập bằng passkey cho các tương tác hoặc giao dịch tiếp theo, giảm đáng kể sự phiền phức so với việc xác minh lại hoặc các luồng dựa trên ứng dụng.
• Kích hoạt các hệ thống E2EE tùy chỉnh: Mặc dù Corbado Connect cung cấp các thành phần UI cho các luồng tiêu chuẩn, các nguyên tắc cơ bản có thể cho phép các nhà phát triển tích hợp chức năng PRF sâu hơn vào các ứng dụng nhạy cảm. Điều này cho phép xây dựng các hệ thống mã hóa end-to-end nơi ứng dụng frontend trực tiếp tận dụng các khóa có nguồn gốc từ PRF cho các hoạt động mật mã phức tạp trên dữ liệu hiện có hoặc mới. Hiện tại, điều này vẫn chỉ có thể thực hiện một cách cơ hội và các cơ chế dự phòng cần phải triển khai một cách khác để lưu trữ những thông tin đó.

Corbado nhằm mục đích đơn giản hóa sự phức tạp của việc tích hợp passkey và PRF, cho phép các doanh nghiệp tận dụng các tiêu chuẩn một cách an toàn và hiệu quả, thích ứng với các trường hợp sử dụng cụ thể như mã hóa PII phía máy khách trong khi điều hướng bối cảnh đang phát triển.

Tiện ích mở rộng WebAuthn PRF đánh dấu một bước tiến quan trọng trong việc biến các ứng dụng mã hóa end-to-end, thực sự không cần mật khẩu trở thành hiện thực. Bằng cách tận dụng passkey để tạo ra các khóa mật mã một cách an toàn, nó cung cấp một trải nghiệm người dùng liền mạch và an toàn mà không ảnh hưởng đến quyền riêng tư.

Trả lời trực tiếp các câu hỏi được đặt ra ở đầu bài viết này:

• Các trường hợp sử dụng PRF thú vị: PRF cho phép các trường hợp sử dụng hấp dẫn như lưu trữ dữ liệu được mã hóa end-to-end, giải mã kho lưu trữ không cần mật khẩu cho các trình quản lý mật khẩu, các cơ chế xoay vòng khóa mật mã an toàn, và các ví nhận dạng an toàn hoặc các hệ thống không lưu ký bảo vệ quyền riêng tư của người dùng bằng cách đảm bảo các khóa riêng tư không bao giờ rời khỏi thiết bị của khách hàng.

• Tình trạng hỗ trợ PRF hiện tại (tháng 6 năm 2025): Hỗ trợ vẫn còn phân mảnh và đang phát triển. Trong khi Android có hỗ trợ mạnh mẽ trên các trình duyệt và trình xác thực, các nền tảng như macOS và đặc biệt là iOS còn yếu, đặc biệt khi làm nguồn CDA với một lỗi nghiêm trọng. Hỗ trợ trên Windows chủ yếu giới hạn ở các khóa bảo mật bên ngoài, với sự hỗ trợ nền tảng gốc qua Windows Hello đáng chú ý là không có.

Các nhà phát triển xem xét tiện ích mở rộng PRF nên dự đoán sự cải thiện nhanh chóng, nhưng vẫn tiến hành một cách thận trọng, xây dựng các ứng dụng linh hoạt có thể xử lý một cách duyên dáng các hạn chế hiện tại. Khi sự chấp nhận rộng rãi hơn xuất hiện trên các nền tảng lớn và hệ sinh thái trình xác thực, tương lai cho mã hóa không mật khẩu được kích hoạt bởi PRF có vẻ tươi sáng, hứa hẹn tăng cường quyền riêng tư và khả năng sử dụng trong xác thực web.