Passkey Ràng Buộc Thiết Bị vs. Passkey Đồng Bộ (SCA & Passkey I)

Tổng quan: Xác thực Khách hàng Mạnh mẽ với Passkey#

• Phân tích các Yêu cầu PSD2 & SCA
• Ý nghĩa của các Yêu cầu SCA đối với Passkey
• Tác động của PSD3 / PSR đối với Passkey

1. Giới thiệu: Passkey Ràng Buộc Thiết Bị vs. Passkey Đồng Bộ#

Trong bài đăng blog trước đây của chúng tôi về passkey và PSD2, chúng tôi đã thảo luận về cách các công ty Fintech như Revolut và Finom đã sử dụng passkey và cách chúng cải thiện bảo mật kỹ thuật số cho ngành ngân hàng.

Passkey có hai dạng chính: passkey đồng bộ (synced passkeys) và passkey ràng buộc thiết bị (device-bound passkeys). Mặc dù passkey đồng bộ cho phép người dùng xác thực trên nhiều thiết bị một cách liền mạch, passkey ràng buộc thiết bị lại được liên kết chặt chẽ với một thiết bị passkey như khóa bảo mật phần cứng hoặc trình xác thực cục bộ.

Với loạt bài viết gồm bốn phần này, chúng tôi muốn phân tích sâu về cách các loại passkey khác nhau (ràng buộc thiết bị so với đồng bộ) tuân thủ các yêu cầu của SCA & PSD2.

Phần đầu tiên của loạt bài này tập trung vào việc hiểu sự khác biệt giữa passkey ràng buộc thiết bị và passkey đồng bộ.

Phần thứ hai giải thích PSD2 và Xác thực khách hàng mạnh (SCA) là gì một cách dễ hiểu, đồng thời trình bày sự phát triển lịch sử của nó.

Phần thứ ba của loạt bài cho thấy cách các loại passkey khác nhau tuân thủ SCA và ý nghĩa của điều này đối với các ngân hàng, fintech và tổ chức tài chính đang cân nhắc áp dụng passkey.

Phần thứ tư và cũng là phần cuối của loạt bài kết luận về những tác động của PSD3 / PSR đối với SCA và passkey trong tương lai.

2. Xác thực khách hàng mạnh (SCA), PSD2 và Passkey#

Sau khi xuất bản bài đăng blog trước, chúng tôi đã nhận được rất nhiều câu hỏi tiếp theo về lập trường của mình đối với passkey, đặc biệt là liên quan đến SCA trong khuôn khổ PSD2. Có một sự quan tâm rõ ràng trong việc hiểu không chỉ việc ứng dụng passkey, mà còn cách chúng phù hợp với các Tiêu chuẩn Kỹ thuật Quản lý (RTS). Ngoài ra, các bên liên quan rất tò mò về những cách diễn giải và hướng dẫn tiềm năng từ các cơ quan quản lý, bao gồm Cơ quan Ngân hàng Châu Âu (EBA), về việc sử dụng passkey.

Nhận thức được điều này, chúng tôi hướng tới việc đi sâu hơn vào cách passkey có thể được tích hợp trong chỉ thị PSD2, RTS về SCA và làm rõ lập trường của chúng tôi trong việc sử dụng công nghệ này. Chúng tôi cũng sẽ khám phá các câu hỏi và câu trả lời hiện có của EBA để làm sáng tỏ cách các cơ quan quản lý và EBA có thể nhìn nhận passkey. Việc kiểm tra này sẽ không chỉ giải quyết sự khác biệt giữa passkey đồng bộ và passkey ràng buộc thiết bị mà còn cả các ứng dụng thực tế của chúng trong việc tăng cường cả bảo mật và trải nghiệm người dùng.

Bằng cách hiểu những sắc thái này, các bên liên quan có thể đưa ra các quyết định sáng suốt không chỉ tuân thủ các yêu cầu nghiêm ngặt của PSD2 mà còn tận dụng công nghệ xác thực mới nhất để bảo mật các giao dịch kỹ thuật số. Thảo luận của chúng tôi nhằm mục đích soi sáng thêm con đường tích hợp passkey vào các quy trình xác thực, đảm bảo rằng các biện pháp bảo mật theo kịp bối cảnh kỹ thuật số đang phát triển.

Tất nhiên, mọi thực thể được quản lý thuộc phạm vi điều chỉnh của PSD2 đều cần phải đưa ra quyết định riêng của mình về cách đáp ứng các mục tiêu quy định, vì mỗi quá trình triển khai đều có những phức tạp riêng. Cách tiếp cận cá nhân này thừa nhận rằng mặc dù khuôn khổ pháp lý cung cấp một tiêu chuẩn thống nhất, nhưng việc áp dụng thực tế các tiêu chuẩn này sẽ khác nhau đáng kể giữa các tổ chức khác nhau do môi trường hoạt động, khả năng công nghệ và cơ sở người dùng độc đáo của họ.

Do đó, mặc dù những hiểu biết của chúng tôi nhằm mục đích hướng dẫn và cung cấp thông tin, chúng không mang tính chất bắt buộc. Mỗi thực thể phải xem xét các hoàn cảnh và thách thức cụ thể của mình trong việc tích hợp passkey vào các giao thức bảo mật và xác thực của họ.

3. Từ Passkey Ràng Buộc Thiết Bị đến Passkey Đồng Bộ#

Để hiểu sự khác biệt giữa passkey ràng buộc thiết bị và passkey đồng bộ, chúng ta sẽ xem xét ngắn gọn về cách hệ sinh thái đã phát triển.

3.1 Passkey Ràng Buộc Thiết Bị (Passkey Đơn Thiết Bị) là gì?#

Chúng ta bắt đầu bằng việc nhìn vào lịch sử và sự phát triển của passkey ràng buộc thiết bị trước khi tìm hiểu sâu hơn về các chi tiết kỹ thuật của chúng.

3.1.1 Lịch sử của Passkey Ràng Buộc Thiết Bị#

Về mặt lịch sử, các cơ chế xác thực trong WebAuthn (tiêu chuẩn nền tảng của passkey) được gắn chặt với các thiết bị vật lý: khóa bảo mật (ví dụ: YubiKeys). Trước khi passkey được áp dụng rộng rãi, thông tin xác thực FIDO2 gắn với một trình xác thực duy nhất đại diện cho tiêu chuẩn vàng về bảo mật. Các thông tin xác thực này được liên kết với thiết bị mà chúng cư trú. Hệ quả của sự ràng buộc này rất đáng kể: thông tin xác thực không thể được chuyển giao hoặc sử dụng ngoài phần cứng ban đầu của nó.

Cách tiếp cận này, mặc dù tăng cường bảo mật bằng cách bản địa hóa quy trình xác thực vào một thiết bị duy nhất, nhưng chắc chắn đã gặp phải những hạn chế thực tế ảnh hưởng đến việc áp dụng rộng rãi của nó, đặc biệt là đối với những người tiêu dùng phổ thông không am hiểu kỹ thuật. Người dùng buộc phải luôn có thiết bị xác thực của họ cho mỗi lần cố gắng đăng nhập, điều này không chỉ hạn chế tính di động của người dùng mà còn làm dấy lên những lo ngại trong các tình huống mà thiết bị bị mất, hư hỏng hoặc không thể truy cập ngay lập tức.

Hơn nữa, người tiêu dùng cũng miễn cưỡng đầu tư vào phần cứng bổ sung. Trong lịch sử, việc sở hữu và sử dụng các khóa bảo mật chuyên dụng rất thấp ở những người tiêu dùng phổ thông. Viễn cảnh mua phần cứng chuyên biệt cho mục đích xác thực, mặc dù có các lợi ích bảo mật được nâng cao, nhưng không gây được tiếng vang với đa số người dùng B2C, những người đồng thời thường là mục tiêu của các chiến dịch lừa đảo diện rộng hoặc các cuộc tấn công nhồi nhét thông tin xác thực (credential stuffing).

3.1.2 Chi tiết kỹ thuật của Passkey Ràng Buộc Thiết Bị#

Passkey ràng buộc thiết bị được đặc trưng bởi sự phân loại cụ thể của chúng thành các thông tin xác thực có thể khám phá (discoverable) và không thể khám phá (non-discoverable), một sự khác biệt chủ yếu xác định khả năng khám phá của chúng. Nhưng yếu tố chính để phân biệt khóa ràng buộc thiết bị được gói gọn trong các thuộc tính thông tin xác thực WebAuthn, đặc biệt là thông qua các cờ isBackupEligible và isBackupSynchronized. Đối với passkey ràng buộc thiết bị, cả hai trường này đều được đặt thành 0, cho biết rằng các thông tin xác thực không đủ điều kiện để sao lưu hoặc đồng bộ hóa giữa các thiết bị. Các đặc điểm này nhấn mạnh mối liên kết nội tại của chúng với thiết bị vật lý mà chúng được tạo ra, đảm bảo rằng thông tin xác thực vẫn được gắn liền và chỉ có thể sử dụng được trên mảnh phần cứng cụ thể đó.

Một ví dụ đáng chú ý về thông tin xác thực ràng buộc thiết bị trong thực tế được quan sát trong hệ sinh thái Windows. Thông tin xác thực Windows Hello trên Windows 10 và Windows 11 vẫn bị ràng buộc vào thiết bị—bản thân Windows Hello chưa đồng bộ hóa passkey trên các thiết bị. Tuy nhiên, Microsoft đã thực hiện một bước tiến quan trọng đầu tiên bằng cách giới thiệu tính năng lưu và đồng bộ passkey trong Microsoft Edge (bắt đầu từ Edge 142). Tính năng đồng bộ ở cấp trình duyệt này thông qua Microsoft Password Manager cho phép passkey đồng bộ trên các thiết bị Windows khi sử dụng Edge, tương tự như cách Google Password Manager kích hoạt đồng bộ passkey trong trình duyệt Chrome trên Windows. Điều này đại diện cho một bước tiến quan trọng trong khả năng passkey của Windows, mặc dù nó dành riêng cho trình duyệt Edge thay vì nền tảng xác thực Windows Hello. Các passkey Windows Hello vẫn ràng buộc vào thiết bị, nhưng sự tích hợp Edge này cung cấp một con đường thực tế hướng tới các passkey đồng bộ trên Windows trong khi trình xác thực nền tảng bản thân nó có thể phát triển để hỗ trợ đồng bộ hóa trong tương lai.

Mặt khác, Google đã nêu rõ lập trường của mình về các passkey không thể khám phá, cho biết rằng các passkey không thể khám phá hiện tại sẽ vẫn không được đồng bộ hóa trong các bản triển khai trong tương lai. Quyết định này phù hợp với nguyên tắc rộng hơn rằng các thông tin xác thực không thể khám phá đóng vai trò quan trọng trong các bối cảnh bảo mật nhất định bằng cách vẫn bị ràng buộc chặt chẽ vào thiết bị và không thể khám phá, do đó không thể được sử dụng như passkey.

Ngược lại, cách tiếp cận của Apple với macOS và iOS khác biệt đáng kể. Không giống như chiến lược cố định, ràng buộc thiết bị được quan sát với Windows và khóa không thể khám phá của Google, hệ sinh thái của Apple mạnh mẽ hơn nhiều khi nghiêng về việc chỉ cho phép passkey đồng bộ, đặc biệt là trên iOS, do đó không thể tạo passkey ràng buộc thiết bị thông qua WebAuthn.

Sự phân chia chiến lược này trên các nền tảng chính minh họa các phương pháp tiếp cận đa dạng để quản lý thông tin xác thực WebAuthn, đặc biệt là khi xem xét sự cân bằng giữa tính bảo mật, sự tiện lợi và khả năng tiếp cận của người dùng. Mặc dù passkey ràng buộc thiết bị cung cấp mức độ bảo mật cao bằng cách đảm bảo rằng thông tin xác thực không thể bị di chuyển hoặc sử dụng sai mục đích bên ngoài thiết bị dự kiến của chúng, ngành công nghiệp vẫn tiếp tục phát triển, tìm kiếm các giải pháp duy trì các tiêu chuẩn bảo mật mà không làm giảm trải nghiệm và khả năng di động của người dùng.

3.2 Passkey Đồng Bộ (Passkey Đa Thiết Bị) là gì?#

Tại đây, chúng ta cũng xem xét sự phát triển lịch sử của passkey đồng bộ trước khi phân tích các chi tiết kỹ thuật. Đôi khi, passkey đồng bộ còn được gọi là passkey có thể đồng bộ (syncable passkeys).

3.2.1 Lịch sử của Passkey Đồng Bộ#

Theo sau việc công bố thông số kỹ thuật WebAuthn Level 2 và CTAP 2.1 vào khoảng giữa đến cuối năm 2021, nhóm làm việc WebAuthn đã khởi xướng một sáng kiến lớn trong ngành nhằm khắc phục những trở ngại chính cản trở khả năng thay thế mật khẩu và tăng mức độ áp dụng của tiêu chuẩn WebAuthn. Sáng kiến này tập trung vào hai khía cạnh quan trọng: loại bỏ yêu cầu về các thiết bị bảo mật phần cứng bổ sung và giảm thiểu rủi ro liên quan đến việc mất trình xác thực trong khi vẫn giữ nguyên khả năng tương thích ngược với các tiêu chuẩn hiện có.

3.2.1.1 Sử dụng Trình xác thực nền tảng như các Mô-đun phần cứng bảo mật#

Thử thách đầu tiên – xóa bỏ nhu cầu về phần cứng mới – đã được giải quyết thông qua việc sử dụng các trình xác thực nền tảng (platform authenticators) được tích hợp sẵn trong các thiết bị tiêu dùng hiện đại (ví dụ: Touch ID, Face ID, Windows Hello).

Các thiết bị hiện đại ngày càng được trang bị các mô-đun bảo mật chuyên biệt, chẳng hạn như Trusted Execution Environment (TEE) trên Android, Secure Enclave trên iOS và macOS, và Trusted Platform Module (TPM) trên các thiết bị Windows. Các kho lưu trữ khóa bảo mật tích hợp này đóng vai trò là nền tảng vững chắc cho passkey, hoạt động hiệu quả như "khóa bảo mật" tích hợp sẵn. Cách tiếp cận này cho phép áp dụng rộng rãi mật mã khóa công khai (public key cryptography), một mức độ bảo mật mà trước đây chỉ có thể đạt được thông qua các khóa bảo mật phần cứng bên ngoài (ví dụ: YubiKeys), và phần lớn chỉ giới hạn cho những cá nhân sành sỏi về công nghệ hoặc các tổ chức trong các ngành được quản lý chặt chẽ.

Bằng cách khai thác các khả năng của TEE, Secure Enclave hoặc TPM, các giao thức WebAuthn được trao quyền để cung cấp các cơ chế xác thực người dùng bằng mật mã, mạnh mẽ. Giờ đây, các phương thức xác thực tinh vi trở nên thân thiện với người dùng và có thể truy cập được cho công chúng, mà không cần thêm phần cứng chuyên dụng.

Sự tiến hóa này là một sự cải thiện rất mạnh mẽ trong cách tiếp cận bảo mật kỹ thuật số, nhấn mạnh vai trò quan trọng mà các giải pháp bảo mật lấy người dùng làm trung tâm đóng góp trong việc thúc đẩy việc áp dụng rộng rãi. Các tổ chức kết hợp passkey đồng bộ với quy trình tạo passkey và đăng nhập bằng passkey được tối ưu hóa sẽ thấy tỷ lệ áp dụng cao nhất. Bằng cách sử dụng các tính năng bảo mật của các thiết bị hiện đại, nỗ lực của ngành đã giải quyết thành công rào cản ban đầu về việc loại bỏ sự cần thiết của phần cứng bên ngoài.

Sự phát triển này là một bước quan trọng trong kỷ nguyên mới của hệ sinh thái xác thực kỹ thuật số, nơi việc áp dụng rộng rãi mật mã khóa công khai trở nên khả dụng trực tiếp cho nhiều trường hợp sử dụng và đồng thời đơn giản hóa việc xác thực cho người dùng.

3.2.1.2 Đồng bộ hóa Passkey lên đám mây#

Để giải quyết rủi ro liên quan đến việc mất điện thoại di động và kéo theo đó là mất passkey lưu trữ trên đó, sáng kiến của ngành tập trung vào việc cho phép đồng bộ hóa các thông tin xác thực có thể khám phá lên đám mây. Cách tiếp cận này chuyển đổi một cách hiệu quả các thông tin xác thực từ chỗ bị ràng buộc chặt chẽ vào thiết bị sang đa thiết bị và chính xác hơn là bị ràng buộc vào tài khoản của người dùng với nhà cung cấp đám mây của họ, chẳng hạn như iCloud đối với các thiết bị của Apple hoặc Google đối với các thiết bị Android.

Giải pháp thiết thực này có nghĩa là ngay cả khi điện thoại của người dùng bị mất hoặc bị thay thế, các thông tin xác thực đã thiết lập trước đó sẽ không bị mất vĩnh viễn. Thay vào đó, những thông tin xác thực này có thể được lấy lại từ tài khoản đám mây của người dùng và đồng bộ hóa sang một thiết bị mới. Sự thay đổi này làm giảm đáng kể sự bất tiện và rủi ro bảo mật trước đây liên quan đến việc mất thiết bị xác thực vật lý.

Bằng cách tận dụng đồng bộ hóa đám mây, các passkey hiện có thể chuyển tiếp mượt mà giữa các thiết bị của người dùng, duy trì tính toàn vẹn và bảo mật của chúng bất kể thiết bị cụ thể đang sử dụng. Ví dụ: khi người dùng đăng nhập vào trang web từ một thiết bị mới, các thông tin xác thực có sẵn trong tài khoản đám mây của họ có thể được tự động đề xuất để xác thực. Nếu cần, những thông tin xác thực này có thể được truyền sang thiết bị mới, duy trì trải nghiệm xác thực an toàn và nhất quán trên các nền tảng và thiết bị khác nhau.

Sự chuyển đổi sang các thông tin xác thực gắn với tài khoản, được đồng bộ hóa trên đám mây này đại diện cho một cách tiếp cận thực dụng đối với bảo mật kỹ thuật số. Nó thừa nhận thực tế của việc sử dụng thiết bị hiện đại và sự cố thường xuyên xảy ra trong việc trao đổi thiết bị, cho dù là do mất mát, hư hỏng hoặc nâng cấp. Bằng cách ràng buộc thông tin xác thực với tài khoản đám mây của người dùng – dù là với iCloud của Apple hay các dịch vụ đám mây của Google – giải pháp này không chỉ giảm thiểu rủi ro liên quan đến việc mất thiết bị mà còn nâng cao khả năng quản lý và khôi phục danh tính kỹ thuật số của người dùng trên nhiều thiết bị.

Sự phát triển này mở rộng hiệu quả khả năng ứng dụng của các cơ chế xác thực bằng mật mã mạnh mẽ của WebAuthn, làm cho chúng dễ thích ứng hơn với các tình huống người dùng trong thế giới thực. Nó cũng đảm bảo rằng xác thực mạnh mẽ có thể truy cập và quản lý được, không chỉ dành cho những người có nền tảng kỹ thuật hoặc những người trong các ngành được quản lý chặt chẽ mà còn cho cả người dùng trung bình đang điều hướng trong thế giới kỹ thuật số với nhiều thiết bị.

3.2.2 Chi tiết kỹ thuật của Passkey Đồng Bộ#

Passkey đồng bộ còn được gọi là thông tin xác thực có thể khám phá (discoverable credentials) hoặc khóa thường trú (resident keys). Chúng được phân biệt với các khóa ràng buộc thiết bị bởi hai thuộc tính quan trọng: isBackupEligible và isBackedUp có các giá trị khác nhau. Đối với passkey đồng bộ, cờ isBackupEligible được đặt thành 1, cho thấy rằng các thông tin xác thực này đủ điều kiện để sao lưu. Sau khi đồng bộ hóa thành công với đám mây, cờ isBackedUp cũng được đặt thành 1, xác nhận rằng thông tin xác thực đã được đồng bộ hóa đúng cách. Cần lưu ý rằng trạng thái đồng bộ hóa có thể thay đổi theo thời gian, phản ánh bản chất năng động của việc sử dụng và quản lý thiết bị.

Khi các nền tảng yêu cầu khóa thường trú, bằng cách đặt tham số "requireResidentKey" thành required (bắt buộc) hoặc preferred (ưu tiên), các nền tảng hỗ trợ dịch vụ đám mây sẽ tự động tạo các passkey đồng bộ. Quá trình này đảm bảo rằng người dùng có thể dựa vào việc thông tin xác thực của họ có thể truy cập được trên các thiết bị khác nhau của họ. Trên Windows, các passkey đồng bộ hiện có sẵn thông qua Microsoft Edge/Microsoft Password Manager (đồng bộ cấp trình duyệt), trong khi các thông tin xác thực trình xác thực nền tảng Windows Hello vẫn bị ràng buộc vào thiết bị. Các trình quản lý mật khẩu của bên thứ ba (ví dụ: Dashlane, KeePassXC, 1Password) có khả năng quản lý passkey cũng cung cấp đồng bộ hóa trên nhiều nền tảng. Trong các tình huống sử dụng passkey đồng bộ, các cờ isBackupEligible và isBackedUp được đặt thành 1, cho biết khả năng đủ điều kiện sao lưu và đồng bộ hóa thành công.

Hơn nữa, mặc dù hiện tại vẫn có thể xác định trình xác thực cụ thể nơi passkey đã được lưu trữ, nhưng việc thiếu chứng thực (attestation) đối với phần lớn các thông tin xác thực này có nghĩa là nguồn gốc của chúng không thể được xác minh bằng mật mã. Khía cạnh này làm nổi bật một hạn chế tiềm ẩn trong việc đảm bảo nguồn gốc bảo mật của passkey đồng bộ chỉ thông qua các cơ chế tiêu chuẩn của WebAuthn.

Sự phát triển này ở các passkey đồng bộ về cơ bản mở rộng phạm vi của các thông tin xác thực có thể khám phá bằng cách tích hợp chúng vào một khuôn khổ đồng bộ hóa dựa trên đám mây. Bằng cách làm cho các khóa này đủ điều kiện sao lưu và đảm bảo sự đồng bộ hóa của chúng trên các thiết bị của người dùng, WebAuthn giải quyết hai trong số các thách thức chính trong xác thực kỹ thuật số: rủi ro mất quyền truy cập do thiết bị bị mất và sự bất tiện khi quản lý nhiều thông tin xác thực ràng buộc với thiết bị.

3.3 Sự ràng buộc đơn thiết bị của thông tin xác thực WebAuthn đã bị hy sinh vì lợi ích lớn hơn#

Quá trình chuyển đổi từ passkey ràng buộc thiết bị sang passkey đồng bộ đã bắt đầu một cuộc đối thoại quan trọng trong nhóm làm việc của WebAuthn, tập trung vào nhu cầu về các biện pháp bảo mật nâng cao, các câu hỏi pháp lý liên quan, và một sự thỏa hiệp vừa thân thiện với người tiêu dùng vừa an toàn.

Việc áp dụng các passkey đồng bộ đã được hoan nghênh vì lời hứa nâng cao sự tiện lợi và bảo mật cho người dùng thông qua các tính năng như đồng bộ hóa đám mây và chức năng đa thiết bị liền mạch. Tuy nhiên, nó đã gây ra một số khó chịu cho một số bên phụ thuộc (Relying Parties - RP), đặc biệt là liên quan đến các ý nghĩa đối với bảo mật và tính tuân thủ trong các môi trường có yêu cầu cao. Bản chất của cuộc tranh luận là yêu cầu về một cơ chế đảm bảo ngay cả passkey đồng bộ cũng duy trì kết nối với các thiết bị cụ thể, một khái niệm quan trọng đối với các bên phụ thuộc khi giải quyết các giao dịch nhạy cảm hoặc hoạt động theo các tiêu chuẩn pháp lý nghiêm ngặt.

Đối với những RP không thể hoặc không muốn áp dụng passkey, việc thiếu một phương pháp đáng tin cậy để ràng buộc các thông tin xác thực này vào các thiết bị cụ thể trong các ứng dụng quan trọng đã đặt ra một thách thức đáng kể. Cơ chế như vậy được coi là rất quan trọng đối với một số RP. Từ góc độ của họ, việc thiếu vắng khả năng ràng buộc thiết bị này, một sự kỳ vọng có thể không được tuyên bố rõ ràng nhưng chắc chắn là được mong đợi, thể hiện một sự ngạc nhiên nghiêm trọng và là một sự vi phạm lòng tin.

Cuộc thảo luận đi đến kết luận rằng nên có sự hài hòa giữa các lợi ích, nhưng trước hết mục tiêu lớn hơn là phổ biến passkey nên được ưu tiên. Trong cuộc thảo luận, tiện ích mở rộng devicePubKey được xem như một cách để giải quyết những lo ngại đó, nhưng sau đó đã được thay thế bằng supplementalPubKeys với một cách tiếp cận rộng lớn hơn nhiều trong bản nháp hiện tại của WebAuthn Level 3. Thật không may, cách tiếp cận này cũng đã bị ngừng lại vào tháng 8 năm 2024.

3.4 Điều tốt nhất của hai thế giới: Tiện ích mở rộng Passkey và supplementalPubKeys [đã ngừng dùng từ tháng 8 năm 2024]#

Hãy cùng phân tích cách mà sự thỏa hiệp với tiện ích mở rộng supplementalPubKeys được hình thành và điều này có ý nghĩa gì về mặt kỹ thuật.

3.4.1 Từ tiện ích mở rộng devicePubKey sang supplementalPubKeys#

Cuộc thảo luận xoay quanh sự chuyển đổi từ tiện ích mở rộng devicePubKey sang tiện ích mở rộng supplementalPubKeys làm nổi bật tính chất năng động của thông số kỹ thuật WebAuthn. Ban đầu, devicePubKey phục vụ cho việc tăng cường bảo mật thông qua các khóa công khai ràng buộc thiết bị, nhưng sau đó nó đã được thay thế bằng đề xuất về supplementalPubKeys trong Bản nháp làm việc của WebAuthn Level 3. Tiện ích mở rộng mới hơn này cung cấp một giải pháp toàn diện hơn bằng cách cho phép sử dụng nhiều khóa để tăng cường quy trình xác thực.

Trọng tâm của cuộc tranh luận tập trung vào việc cân bằng các biện pháp bảo mật nâng cao với việc áp dụng rộng rãi và tiện ích thực tế của passkey trên các thiết bị và nền tảng khác nhau. Tiện ích mở rộng supplementalPubKeys đại diện cho sự kết hợp của các ưu tiên này, cho phép xác thực nghiêm ngặt hơn. Ví dụ, nó có thể đáp ứng các quy định yêu cầu một số tiêu chuẩn xác thực nhất định bằng cách cho phép thêm các “khóa phụ” (sub-keys) kèm theo các tuyên bố chứng thực (attestation statements). Những khóa này có thể báo hiệu sự tuân thủ các yêu cầu xác thực, có khả năng giảm nhu cầu về các thử thách đăng nhập bổ sung trong một số điều kiện nhất định (ngay cả với passkey).

Một ví dụ trực tiếp từ bản nháp WebAuthn:

“Giả sử có một yêu cầu đăng nhập xuất hiện tại một trang web đi kèm với tín hiệu định vị địa lý mà tài khoản người dùng này chưa từng được thấy trước đây, và nằm ngoài giờ sử dụng thông thường được quan sát thấy của tài khoản. Rủi ro có thể được coi là đủ cao để không cho phép yêu cầu, ngay cả khi có một sự xác nhận bằng thông tin xác thực đa thiết bị. Nhưng nếu một chữ ký từ khóa bổ sung (supplemental key) ràng buộc thiết bị và đã được thiết lập tốt cho người dùng này cũng có thể được trình bày, thì điều đó có thể làm nghiêng cán cân.”

Trong cuộc thảo luận, người ta đã làm nổi bật rằng những điều này chỉ dành cho các RP có yêu cầu cực kỳ cao về bảo mật (ví dụ: trong bối cảnh chính phủ).

Bằng cách kết hợp các phản hồi và giải quyết các trường hợp sử dụng cụ thể – cũng bao gồm cả các giao dịch tài chính được quản lý và nhu cầu về các tín hiệu ràng buộc thiết bị trong một môi trường thông tin xác thực đa thiết bị – cộng đồng WebAuthn nhằm mục đích giải quyết cả các mối quan tâm về bảo mật và khả năng tương tác. Do đó, tiện ích mở rộng supplementalPubKeys là một cách tiếp cận tìm cách cung cấp các tính năng bảo mật mạnh mẽ đồng thời hỗ trợ trải nghiệm người dùng liền mạch và khả năng tương thích rộng rãi cần thiết cho việc áp dụng passkey rộng khắp. Đây là một tiện ích mở rộng hoàn toàn không bắt buộc và không can thiệp vào việc triển khai passkey vốn đã được thấy trong 2 năm qua.

Sự tiến hóa này theo hướng một khuôn khổ toàn diện và linh hoạt hơn nhấn mạnh cam kết của cộng đồng WebAuthn trong việc cải thiện các phương thức xác thực web ngay cả đối với các trường hợp sử dụng nghiêm ngặt hơn.

3.4.2 Chi tiết kỹ thuật của supplementalPubKeys#

Tiện ích mở rộng supplementalPubKeys được giới thiệu trong WebAuthn cho phép sử dụng thêm các cặp khóa bổ sung cùng với thông tin xác thực chính.

Lấy từ vấn đề GitHub gốc

Hình ảnh cho thấy khái niệm supplementalPubKey được lấy từ vấn đề GitHub gốc (pk = passkey, pspk=khóa bổ sung của nhà cung cấp, dspk = khóa bổ sung của thiết bị).

Dưới đây là một bản phân tích về cách hoạt động và mục đích sử dụng của nó:

Mục đích và chức năng của supplementalPubKey

• Chỉ còn lại một thông tin xác thực passkey trung tâm: Cần nhớ rằng chỉ có một passkey trung tâm vẫn là phương pháp xác thực người dùng chính, và các khóa bổ sung cung cấp thêm các lớp bảo mật và sự đảm bảo. Cấu trúc này duy trì sự đơn giản và hiệu quả của việc sử dụng một passkey cốt lõi, duy nhất để xác thực trên nhiều thiết bị, đảm bảo trải nghiệm người dùng liền mạch. Các khóa bổ sung, trong khi đó, phục vụ để tăng cường bối cảnh xác thực, cung cấp cho Bên phụ thuộc (Relying Party - RP) các tín hiệu bổ sung về môi trường bảo mật hoặc sự tuân thủ các tiêu chuẩn xác thực cụ thể. Các khóa bổ sung này không phải là phương pháp xác thực độc lập mà thay vào đó là tăng cường passkey chính, củng cố mức độ tin cậy của nó bằng bằng chứng về tính toàn vẹn của thiết bị.
• Khóa Ràng buộc Thiết bị (Device-Bound Keys): Chúng được gắn liền cụ thể với một thiết bị. Chúng có thể cung cấp các đảm bảo rằng yêu cầu xác thực đến từ một thiết bị đáng tin cậy đã được xác thực trước đó. Chúng sẽ không được đồng bộ hóa trong bất kỳ trường hợp nào.
• Khóa Ràng buộc Nhà cung cấp (Provider-Bound Keys): Các khóa này có phạm vi là "nhà cung cấp", nghĩa là chúng có thể mang lại các đảm bảo bổ sung dựa trên chính sách của nhà cung cấp xác thực hoặc sự chứng thực cụ thể của nhà cung cấp. Ví dụ: một nhà cung cấp có thể chỉ phát hành một khóa như vậy sau khi người dùng đã hoàn tất một mức độ xác thực cao hơn (như 2FA).
• Nhiều Khóa Công khai: Khác với thế hệ tiền nhiệm, tiện ích mở rộng devicePubKey, vốn chỉ cho phép một khóa công khai ràng buộc thiết bị, supplementalPubKeys cho phép bao gồm một hoặc hai loại khóa bổ sung. Các khóa này có thể phục vụ các mục đích và phạm vi khác nhau – cụ thể là các phạm vi ràng buộc với thiết bị và ràng buộc với nhà cung cấp.

Trường hợp sử dụng và Ví dụ về supplementalPubKey

1. Tăng cường bảo mật: Trong các tình huống mà một trang web (bên phụ thuộc) phải tuân thủ một số tiêu chuẩn bảo mật nâng cao để xác thực, các khóa bổ sung có thể được sử dụng để đáp ứng các yêu cầu này. Nếu khóa bổ sung này đã được nhìn thấy và xác minh bởi trang web trước đó, nó có thể cho phép người dùng bỏ qua các thử thách đăng nhập bổ sung vì tính liên tục của thiết bị có thể được xác nhận bởi các tín hiệu trước đó.
2. Quản lý rủi ro: Đối với các yêu cầu đăng nhập có vẻ rủi ro (ví dụ: đến từ một vị trí địa lý mới hoặc vào những giờ bất thường), sự hiện diện của một khóa bổ sung ràng buộc thiết bị có lịch sử sử dụng với tài khoản của người dùng có thể làm giảm rủi ro cảm nhận được và cho phép yêu cầu tiếp tục, trong khi nó có thể bị chặn.

Các khía cạnh kỹ thuật của supplementalPubKey

• Không có ID Thông tin xác thực riêng: Khóa bổ sung không phải là thông tin xác thực của người dùng và chúng không có ID thông tin xác thực riêng.
• Tuyên bố chứng thực (Attestation Statements): Khóa bổ sung có thể có chứng thực một cách không bắt buộc. Những điều này rất quan trọng để hiểu được phạm vi và mức độ bảo mật của các khóa bổ sung. Chứng thực có thể chỉ ra mức độ bảo vệ của một khóa ràng buộc phần cứng, hoặc các chính sách đối với các loại khóa bổ sung khác.
• Việc triển khai cho các Bên phụ thuộc (Relying Parties): Các bên phụ thuộc có thể yêu cầu những khóa bổ sung này như một phần của quy trình xác thực. Tuy nhiên, sự phức tạp của việc giải quyết nhiều khóa và tuyên bố chứng thực có nghĩa là tiện ích mở rộng này phù hợp nhất với các thực thể có nhu cầu bảo mật cụ thể, chẳng hạn như ngân hàng hoặc các dịch vụ hoạt động theo các yêu cầu pháp lý nghiêm ngặt.

Điều quan trọng cần lưu ý là, tính đến tháng 4 năm 2024, tiện ích mở rộng supplementalPubKeys vẫn chưa được trình duyệt lớn nào áp dụng và thông số kỹ thuật WebAuthn Level 3 vẫn đang trong quá trình phát triển và có thể thay đổi. Việc liệu tính năng này có được đưa vào phiên bản cuối cùng của thông số kỹ thuật hay không, cũng như khả năng triển khai và áp dụng trong tương lai của nó, vẫn chưa chắc chắn, vì hiện tại nó chỉ nằm trong Bản nháp của Biên tập viên (Editor’s Draft).

3.4.3 Việc ngừng hỗ trợ supplementalPubKeys vào tháng 8 năm 2024#

Kể từ tháng 8 năm 2024, tiện ích mở rộng supplementalPubKeys đã chính thức bị ngừng. Nhóm làm việc của WebAuthn quyết định xóa tính năng này do không được hỗ trợ đầy đủ. Việc loại bỏ tiện ích mở rộng này cũng đánh dấu một định hướng mới. Hiện tại, Liên minh FIDO (FIDO Alliance) đang làm việc để phát triển một phương pháp tiếp cận khác nhằm hỗ trợ các Bên Phụ Thuộc (Relying Parties) có yêu cầu bảo mật cao. Giải pháp sắp tới này dự kiến sẽ lấp đầy những khoảng trống do việc ngừng hỗ trợ supplementalPubKeys để lại và cung cấp các phương pháp mới để củng cố các quy trình xác thực trong các tình huống mà các tiêu chuẩn bảo mật nghiêm ngặt là rất quan trọng.

Để biết thêm chi tiết về việc ngừng hỗ trợ, vui lòng xem Pull Request chính thức trên WebAuthn GitHub.

4. Cách Corbado xử lý sự khác biệt giữa Passkey Ràng Buộc Thiết Bị và Passkey Đồng Bộ trong thực tế#

Hiểu rõ sự khác biệt giữa passkey ràng buộc thiết bị và passkey đồng bộ là rất quan trọng, nhưng các ngân hàng cũng cần có công cụ để vận hành những khác biệt này ở quy mô lớn. Nền tảng của Corbado cung cấp hệ thống thông tin về mức độ tin cậy của thiết bị, tự động phân loại các loại passkey và áp dụng phương thức xử lý SCA thích hợp cho từng loại.

Khả năng hiển thị Mức độ Tin cậy Thiết bị trên các Loại Passkey#

Bảng điều khiển Thiết bị Tin cậy (Device Trust) của Corbado cho thấy passkey ràng buộc thiết bị và passkey đồng bộ có hiệu suất hoạt động khác nhau trong thực tế ra sao. Passkey ràng buộc thiết bị đạt tỷ lệ thành công cao hơn (99,1%) mà không có yêu cầu nâng cao xác thực (step-up), trong khi passkey đồng bộ có các tín hiệu tin cậy thiết bị đạt 98,4% với tỷ lệ nâng cao xác thực ở mức nhỏ gọn đối với thiết bị mới.

Bảng điều khiển cũng theo dõi việc phân loại thiết bị — xác định thiết bị nào là độc quyền của một người dùng duy nhất (92% trong các triển khai điển hình cho ngành ngân hàng), thiết bị nào được chia sẻ giữa hai người dùng (7%), và thiết bị nào là thiết bị được dùng chung/kiosk (0,8%). Việc phân loại này đóng vai trò trực tiếp vào các quyết định tuân thủ SCA.

Kiểm soát dựa trên chính sách cho các tình huống Passkey khác nhau#

Thay vì đối xử với mọi passkey giống hệt nhau, các chính sách tin cậy của Corbado cho phép các ngân hàng áp dụng các quy tắc khác nhau dựa trên loại passkey, trạng thái thiết bị và mức độ tin cậy. Passkey ràng buộc thiết bị trên thiết bị đã biết được hưởng quá trình xác thực không ma sát (frictionless authentication), trong khi passkey đồng bộ trên thiết bị mới sẽ kích hoạt một quy trình xác minh nâng cao (step-up verification) — chính xác là cách tiếp cận nhiều sắc thái mà khung SCA của PSD2 yêu cầu.

Điều này có nghĩa là các ngân hàng có thể tự tin triển khai passkey đồng bộ để đem lại trải nghiệm người dùng tốt hơn, trong khi vẫn duy trì sự kiểm soát thiết bị nghiêm ngặt mà passkey ràng buộc thiết bị mang lại cho các tình huống bảo mật cao — tất cả đều được quản lý thông qua cấu hình chính sách thay vì các luồng xác thực riêng biệt.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Câu hỏi Thường gặp#

Làm thế nào passkey ràng buộc thiết bị tăng cường bảo mật?#

Passkey ràng buộc thiết bị là thông tin xác thực WebAuthn gắn chặt với thiết bị mà nó được tạo ra. Khác với passkey đồng bộ, chúng chỉ tồn tại trên một thiết bị duy nhất, làm cho chúng vốn dĩ bảo mật hơn trong một số trường hợp sử dụng nhất định:

• Không bị đánh cắp thông tin xác thực: Khóa riêng tư (private key) không bao giờ rời khỏi thiết bị, nên những kẻ tấn công không thể chặn lấy thông tin xác thực.
• Ngăn chặn truy cập trái phép: Việc xác thực chỉ diễn ra từ thiết bị cụ thể mà passkey được tạo ra.
• Không phụ thuộc vào đám mây: Xóa bỏ các rủi ro liên quan đến rò rỉ dữ liệu đám mây hoặc việc bị chiếm quyền điều khiển tài khoản.
• Tuân thủ bảo mật cao: Đáp ứng các yêu cầu xác thực ràng buộc thiết bị nghiêm ngặt đối với các ngành được quản lý như dịch vụ tài chính (AAL3).

Hạn chế chính của chúng là tính di động kém. Nếu bị mất thiết bị, passkey sẽ không thể được phục hồi trừ khi người dùng đăng ký một passkey mới trên một thiết bị khác.

Tại sao passkey đồng bộ được giới thiệu và lợi ích của chúng là gì?#

Passkey đồng bộ (passkey đa thiết bị) được giới thiệu nhằm giải quyết những thách thức về khả năng sử dụng của passkey ràng buộc thiết bị, đặc biệt là thiếu tính di động và khả năng bị khóa tài khoản nếu làm mất thiết bị. Lợi ích chính bao gồm:

• Xác thực đa thiết bị: Truy cập tài khoản từ nhiều thiết bị mà không cần phải đăng ký một passkey mới một cách thủ công cho từng thiết bị.
• Không rủi ro mất quyền truy cập: Thông tin xác thực được sao lưu trên đám mây (ví dụ: iCloud Keychain, Google Password Manager), đảm bảo có thể khôi phục nếu thiết bị bị mất.
• Cải thiện Trải nghiệm Người dùng (UX): Xóa bỏ mọi trở ngại bằng cách không yêu cầu truyền hoặc tạo lại thông tin xác thực theo cách thủ công.
• Không cần phần cứng bổ sung: Khác với khóa bảo mật phần cứng, passkey đồng bộ sử dụng các mô-đun bảo mật có sẵn trong thiết bị.
• Bảo mật mạnh mẽ cùng tiện lợi đám mây: Mã hóa đầu cuối đảm bảo khóa riêng tư không bao giờ rời khỏi thiết bị dưới định dạng không được mã hóa.

5. Kết luận#

Trong phần đầu tiên của loạt bài 4 phần, chúng tôi đã phân tích sự khác biệt về lịch sử và kỹ thuật của passkey ràng buộc thiết bị và passkey đồng bộ. Việc hiểu rõ những khác biệt này sẽ giúp chúng ta áp dụng các yêu cầu của PSD2 và SCA một cách thích hợp. Đồng thời, chúng tôi cũng đã xem xét những gì có thể diễn ra trong tương lai bằng cách xem xét những thay đổi mới nhất trong Tiêu chuẩn WebAuthn Level 3 vẫn đang phát triển.

Dưới đây là liên kết tới các phần khác trong loạt bài của chúng tôi:

• Phần 2 “Phân tích các Yêu cầu của PSD2 & SCA (SCA & Passkey II)”
• Phần 3 "Ý nghĩa của các Yêu cầu SCA đối với Passkey (SCA & Passkey III)"
• Phần 4 "Tác động của PSD3 / PSR đối với Passkey (SCA & Passkey IV)"