Passkeys & WebAuthn PRF pour le chiffrement de bout en bout (2025)

WebAuthn et les Passkeys ont révolutionné l'authentification web, en offrant des connexions sans mot de passe et résistantes au phishing grâce à la cryptographie à clé publique. Mais leurs capacités vont au-delà des connexions. Une fonctionnalité passionnante est l'extension WebAuthn Pseudo-Random Function (PRF). Cette extension permet aux applications web de dériver des clés secrètes directement à partir du Passkey d'un utilisateur ou d'une clé de sécurité matérielle lors de l'authentification. Cela ouvre la voie au chiffrement de bout en bout des données ou au déchiffrement d'un coffre-fort sécurisé en utilisant uniquement votre Passkey, sans avoir besoin d'un mot de passe distinct. Dans cet article, nous souhaitons répondre aux questions suivantes :

• Cas d'utilisation du PRF pour les Passkeys : Quels sont les cas d'utilisation intéressants pour l'extension WebAuthn PRF ?
• Support de l'extension PRF : Quel est le support réel actuel de l'extension WebAuthn PRF sur les systèmes d'exploitation et les navigateurs aujourd'hui ?

Cet article analyse l'extension WebAuthn PRF, en explorant ses spécifications techniques, ses cas d'utilisation, ses détails d'implémentation, ses considérations de sécurité et l'état actuel du support par les navigateurs et les systèmes d'exploitation. Nous nous concentrons sur les changements dans l'écosystème de 2025 et nous nous appuyons sur les travaux de Matthew Miller et Levi Schuck de 2023, dont les articles précédents fournissent un contexte technique détaillé, des exemples concrets et des tests en ligne (y compris le chiffrement).

L'extension WebAuthn PRF (PRF) est formellement définie dans la spécification WebAuthn Level 3. Son objectif principal est de permettre à une Relying Party (votre application web) de demander l'évaluation d'une fonction pseudo-aléatoire associée à un identifiant WebAuthn spécifique (Passkey) lors d'une cérémonie d'authentification (navigator.credentials.get()).

Une PRF prend une clé secrète (conservée en toute sécurité dans l'authenticator et liée à l'identifiant) et une ou plusieurs valeurs d'entrée (fournies par la Relying Party) pour produire une sortie déterministe, d'apparence cryptographiquement aléatoire. Cette sortie, généralement une chaîne de 32 octets, peut ensuite être utilisée par l'application côté client, notamment comme matériel de clé symétrique pour le chiffrement WebAuthn ou la dérivation de clés.

De nombreux authenticators, en particulier les clés de sécurité FIDO2, implémentent une capacité sous-jacente définie dans le protocole CTAP2 (Client-to-Authenticator-Protocol) appelée l'extension hmac-secret. Cette extension CTAP2 donne accès à une fonction HMAC (Hash-based Message Authentication Code) matérielle, qui sert de fonction pseudo-aléatoire. L'extension WebAuthn PRF agit comme un moyen standardisé pour les applications web d'accéder à cette capacité hmac-secret via l'API WebAuthn du navigateur.

Pour éviter les conflits potentiels ou les problèmes de sécurité où un site web pourrait tromper l'authenticator pour générer des HMAC destinés à des fins non web (comme la connexion à l'OS local), la spécification WebAuthn impose une étape importante : les entrées fournies par le site web (premier et second sels) sont d'abord hachées avec une chaîne de contexte spécifique ("WebAuthn PRF" et un octet nul) avant d'être transmises à la fonction hmac-secret sous-jacente. Cela partitionne efficacement l'espace d'entrée de la PRF, garantissant que les sorties dérivées pour le web sont distinctes de celles potentiellement utilisées dans d'autres contextes.

La capacité de dériver des clés liées à l'authentificateur ouvre plusieurs cas d'utilisation convaincants pour les développeurs :

1. Chiffrement côté client / de bout en bout (E2EE) : C'est la principale motivation de l'extension WebAuthn PRF. Les applications basées sur un navigateur peuvent dériver une clé de chiffrement unique par identifiant lors de la connexion. Cette clé peut ensuite être utilisée avec l'API WebCrypto pour chiffrer les données de l'utilisateur stockées localement ou sur le serveur. Les données restent chiffrées au repos et ne peuvent être déchiffrées que par l'utilisateur après une authentification réussie avec le Passkey spécifique, améliorant ainsi la confidentialité et la sécurité des données. Les fournisseurs de services peuvent stocker les données des utilisateurs sans jamais avoir accès au texte en clair. C'est particulièrement utile pour les applications dans le monde du sans mot de passe, car sans l'extension PRF, elles devraient demander en plus un secret sous la forme d'un mot de passe, ce qui contredit l'architecture sans mot de passe.

2. Déchiffrement de coffre-fort sans mot de passe : Des services comme les gestionnaires de mots de passe (par ex., Bitwarden, 1Password) ou les applications de notes sécurisées (par ex., Notesnook, Reflect) peuvent utiliser le PRF pour remplacer le mot de passe maître traditionnel. L'utilisateur s'authentifie avec son Passkey, l'extension PRF dérive la clé de déchiffrement du coffre-fort et le coffre-fort est déverrouillé - aucun mot de passe maître n'est requis. Bitwarden a annoncé le support de cette fonctionnalité. De plus, Dashlane a récemment adopté l'extension WebAuthn PRF pour renforcer la résistance au phishing et améliorer la sécurité d'accès aux coffres-forts chiffrés. Les utilisateurs s'authentifient avec leurs Passkeys, permettant au PRF de dériver les clés de déchiffrement du coffre-fort en toute sécurité, éliminant complètement le besoin d'un mot de passe maître.

3. Rotation sécurisée des clés : L'extension WebAuthn PRF permet de fournir deux "sels" d'entrée (premier et second) lors de l'authentification. Cela facilite les schémas de rotation de clés cryptographiques. Un serveur pourrait demander la clé "actuelle" en utilisant le premier sel et la clé "suivante" en utilisant le second. Au fil du temps, le serveur peut mettre à jour quel sel correspond à la clé actuelle, permettant une rotation transparente sans perturber l'expérience utilisateur. C'est particulièrement important si des exigences réglementaires ou des politiques internes exigent que toutes les clés soient renouvelées selon un calendrier spécifique, ce qui augmente la sécurité.

4. Portefeuilles d'identité & Systèmes non dépositaires : Le PRF peut dériver des clés pour sécuriser les données d'identité dans des portefeuilles numériques ou permettre des systèmes non dépositaires où les clés privées ne sont jamais exposées côté serveur.

Bien que la spécification soit définie, le support réel par les navigateurs et les plateformes est le facteur critique pour les développeurs. Le support a évolué et, jusqu'à récemment, était principalement limité aux navigateurs basés sur Chromium. Suivre le support peut être difficile car il n'y a pas d'entrée dédiée sur CanIUse.com pour l'extension PRF elle-même (une recherche de "webauthn" montre le support général de l'API, mais pas des extensions spécifiques). Les informations doivent souvent être recueillies à partir des notes de version des navigateurs, des suivis de bugs et des pages de statut. L'utilisation réussie de l'extension WebAuthn PRF nécessite un effort coordonné sur trois couches distinctes de la pile technologique. Le support de l'extension PRF doit être présent à chaque niveau pour que la fonctionnalité soit opérationnelle :

1. L'Authenticator : C'est le composant matériel (comme une clé de sécurité) ou de plateforme (comme Windows Hello, le Trousseau iCloud et le module matériel correspondant, par ex. TPM ou Secure Enclave) qui stocke en toute sécurité la clé secrète de l'identifiant et effectue le calcul réel de la fonction pseudo-aléatoire (généralement en utilisant la capacité CTAP2 hmac-secret). Si l'authentificateur ne dispose pas de cette capacité cryptographique fondamentale, le PRF ne peut pas fonctionner.

2. Le système d'exploitation (OS) : L'OS sert de pont entre le navigateur et l'authentificateur. Il fournit les pilotes et les API système nécessaires pour que le navigateur puisse découvrir, communiquer avec et demander des opérations aux authenticators (en particulier les authenticators de plateforme et ceux connectés via USB/NFC/Bluetooth). L'OS doit être capable de reconnaître et d'exposer la capacité PRF (hmac-secret) de l'authenticator au navigateur. Si l'OS ne fournit pas cette passerelle, le navigateur ne peut pas accéder à la fonctionnalité.

3. Le navigateur : En tant qu'interface pour l'application web, le navigateur doit implémenter l'API JavaScript WebAuthn, reconnaître spécifiquement l'extension prf, traduire la requête web en commandes appropriées pour l'OS/l'authentificateur, gérer l'étape de sécurité cruciale du hachage des entrées avec la chaîne de contexte, et analyser et retourner correctement les résultats à l'application.

Une défaillance ou un manque de support à l'un de ces trois niveaux – capacité de l'Authenticator, exposition par l'OS ou implémentation par le navigateur – empêchera l'extension PRF de fonctionner.

Ce diagramme de séquence montre une version simplifiée de la manière dont ces acteurs collaborent pour faciliter le support du PRF.

Un flux de travail PRF fonctionnel exige que chaque couche de la chaîne WebAuthn ↔ CTAP coopère.
Pour plus de clarté, nous séparons la discussion en (1) le comportement du navigateur + système d'exploitation et (2) le comportement de l'authentificateur.

Le chemin vers un large support du PRF met en évidence un défi commun avec les extensions de standards web : l'implémentation est souvent échelonnée, avec des problèmes spécifiques à chaque plateforme à résoudre. Nous nous efforcerons de maintenir ce tableau à jour, mais gardez à l'esprit que, comme l'extension PRF est l'un des ajouts les plus récents nécessitant l'adaptation de toute la chaîne de compatibilité, des ajustements continus sont à prévoir.

Ci-dessous, nous détaillons le support par système d'exploitation.

Le support de l'extension WebAuthn PRF sur Windows est limité, car l'authentificateur de plateforme natif (Windows Hello) ne dispose actuellement pas de la capacité hmac-secret nécessaire. La fonctionnalité PRF dépend donc de clés de sécurité externes.

Avec macOS 15, le support du PRF est arrivé pour les authentificateurs de plateforme. Safari et Chrome supportent tous deux le PRF via le Trousseau iCloud. Le support de Firefox pour l'authentificateur de plateforme est toujours en attente. Les clés de sécurité ne fonctionnent qu'avec Chrome.

Le statut sur iOS et iPadOS est similaire à celui de macOS, avec le PRF fonctionnant via le Trousseau iCloud. Cependant, il y a des mises en garde importantes : un bug dans les premières versions d'iOS 18 peut entraîner une perte de données, et le support des clés de sécurité externes n'est pas encore implémenté.

Android offre actuellement le support le plus robuste et le plus répandu pour l'extension WebAuthn PRF. Les Passkeys stockés dans le Gestionnaire de mots de passe de Google incluent le support PRF par défaut, et cela fonctionne sur la plupart des principaux navigateurs, à l'exception de Firefox.

Dans le tableau ci-dessus, nous avons inclus les combinaisons les plus importantes pour le support des fournisseurs de Passkeys de première partie. Cependant, lors de l'utilisation de gestionnaires de mots de passe comme fournisseurs de Passkeys tiers, leurs capacités spécifiques doivent être considérées séparément. Par exemple, 1Password supporte le PRF dans sa version Android mais pas dans sa version iOS. De plus, le profil Chrome en tant qu'authentificateur ne supporte pas le PRF. Pour plus de détails sur les authentificateurs, voir ci-dessous.

Alors que WebAuthn spécifie ce que une Relying Party peut demander, le Protocole Client-à-Authentificateur (CTAP) définit comment l'authentificateur doit se comporter. En pratique, les authentificateurs se répartissent en quatre catégories :

1. Aucun support PRF : Anciens authentificateurs de plateforme (par ex., Windows Hello), clés de sécurité héritées sans l'extension hmac‑secret et fournisseurs tiers n'ayant pas encore adopté l'extension PRF.

2. PRF uniquement si le drapeau PRF a été défini lors de la création de l'identifiant : Certaines clés de sécurité CTAP 2.0/2.1 exposent hmac‑secret, mais refuseront les évaluations PRF à moins que la Relying Party ne l'ait demandé lors de la création initiale de l'identifiant pour initialiser les secrets.

3. PRF disponible à l'authentification même si non demandé à la création : Les jetons matériels de nouvelle génération ainsi que le Trousseau iCloud et le Gestionnaire de mots de passe de Google exposent la fonctionnalité hmac‑secret sans condition ; les identifiants créés sans le drapeau fonctionnent toujours avec le PRF lors de navigator.credentials.get().

4. Conformité totale à CTAP 2.2 (PRF + première valeur PRF à la création) : Les authentificateurs de plateforme qui synchronisent les Passkeys — comme le Trousseau iCloud et le Gestionnaire de mots de passe de Google — peuvent, sur demande, retourner la première sortie PRF dès la création de l'identifiant (navigator.credentials.create()), simplifiant ainsi les flux d'établissement de clés.

Savoir à quelle catégorie appartient un authentificateur est essentiel lors de la conception de la logique de sauvegarde, de migration ou d'établissement de clés. Nous avons également inclus des tests pour ces scénarios dans notre démo.

Vous pouvez tester l'extension WebAuthn PRF directement en utilisant notre application de démonstration WebAuthn PRF interactive. Dans cette démo, vous pourrez :

• Enregistrer un Passkey avec PRF et confirmer si votre authentificateur supporte cette puissante extension.
• Vous authentifier en utilisant votre Passkey et voir la valeur cryptographique générée par le PRF en action.

Voir la valeur PRF par vous-même met en évidence les implications pratiques de l'utilisation des Passkeys pour des opérations sécurisées basées sur des clés. Cela vous permet de vérifier directement la compatibilité de l'authentificateur pour l'extension PRF et d'observer comment les clés dérivées du PRF peuvent alimenter le chiffrement de bout en bout WebAuthn et le déchiffrement sécurisé de coffres-forts sans mot de passe.

Prenez un moment pour essayer la démo ; comprendre la capacité PRF de votre environnement spécifique vous aide à mieux planifier des expériences sécurisées et sans mot de passe adaptées à vos utilisateurs.

Prêt à tester la puissance du PRF ? Cliquez sur l'image ci-dessus ou suivez ce lien pour commencer votre exploration pratique.

L'extension WebAuthn PRF n'est pas la seule extension WebAuthn liée au stockage ou à la dérivation de données. Comment le PRF des Passkeys se compare-t-il ?

• PRF vs. credBlob / largeBlob :

  • credBlob : Permet de stocker un petit blob statique (32 octets) avec l'identifiant, potentiellement au moment de la création. Il n'a pas été conçu principalement pour les secrets, et son support est limité, en particulier pour les identifiants non détectables.

  • largeBlob : Permet de stocker plus de données (~1 Ko) avec des identifiants détectables, souvent destiné à des données auxiliaires comme des certificats. Le support est également limité (supporté par le Trousseau iCloud depuis iOS 17, mais pas par GPM). Les développeurs de Chrome ont explicitement préféré se concentrer sur le PRF plutôt que sur largeBlob pour la plupart des cas d'utilisation, bien que des développements puissent avoir lieu à l'avenir.

  • PRF : En revanche, le PRF est spécifiquement conçu pour dériver des clés secrètes à la demande lors de l'authentification en utilisant un secret lié au matériel, plutôt que de stocker un blob statique. Il est généralement considéré comme le mécanisme standard le plus approprié et sécurisé pour dériver des clés de chiffrement liées à un Passkey. L'évolution des discussions sur les blobs pour les secrets vers la standardisation et la mise en œuvre axées sur le PRF suggère une convergence vers le PRF comme solution dédiée pour ce cas d'utilisation.

• PRF vs. Clés dérivées de mots de passe (par ex., PBKDF2) : Traditionnellement, les clés de chiffrement côté client étaient dérivées des mots de passe des utilisateurs. Le PRF offre des avantages significatifs :

  • Source plus forte : Les clés sont dérivées d'un matériel cryptographique fort au sein de l'authentificateur, et non de mots de passe potentiellement faibles ou réutilisés.

  • Résistance au phishing : La dérivation est liée au flux d'authentification WebAuthn, résistant au phishing.

  • Sans mot de passe : Permet des cas d'utilisation comme le déchiffrement de coffre-fort sans nécessiter de mot de passe du tout.

• PRF vs. Autres données WebAuthn : Tenter de dériver des clés à partir d'autres parties de la réponse WebAuthn (comme la signature, authenticatorData ou la clé publique) est fondamentalement non sécurisé et incorrect. Ces composants sont soit publics, non secrets, soit conçus pour la vérification, et non pour la dérivation de clés.

Pour dériver de manière sécurisée du matériel de clé cryptographique lié directement à un identifiant WebAuthn ou à un Passkey, l'extension WebAuthn PRF est l'approche standard, conçue spécifiquement et recommandée.

Lors de l'intégration de l'extension PRF dans votre application, tenez compte de ces directives pratiques :

Les recommandations suivantes aident les développeurs à naviguer efficacement dans l'état actuel du support de l'extension PRF et à planifier les développements futurs :

• Traitez le PRF de manière opportuniste :
  Le support de l'extension WebAuthn PRF varie actuellement de manière significative entre les navigateurs, les systèmes d'exploitation et les authentificateurs. Par conséquent, traitez l'intégration du PRF comme une amélioration plutôt que comme une dépendance fondamentale.

• Évitez une dépendance critique au PRF :
  Évitez de rendre le PRF essentiel pour les fonctionnalités critiques. Le support actuel, en particulier sur des plateformes comme Safari sur macOS et iOS, reste incohérent et incomplet.

• Préparez-vous aux scénarios de perte de Passkey :
  N'oubliez pas que les données chiffrées avec des clés dérivées du PRF sont exclusivement liées au Passkey spécifique. La perte du Passkey rendra les données chiffrées définitivement inaccessibles. Mettez toujours en œuvre des mécanismes de sauvegarde et de récupération robustes.

• Anticipez un support plus large d'ici 2026 :
  Le support de l'extension PRF mûrit rapidement. D'ici 2026, attendez-vous à une disponibilité cohérente sur les principaux navigateurs, systèmes d'exploitation et authentificateurs, en particulier avec les fournisseurs de Passkeys de première partie.

• Surveillez l'écosystème Windows :
  Le support de l'authentificateur de plateforme via Windows Hello est actuellement absent. L'intégration complète du PRF dans les environnements Windows dépend fortement de la stratégie d'adoption de Microsoft, alors gardez cet écosystème sous haute surveillance.

Le respect de ces directives garantit que les développeurs peuvent intégrer le PRF en douceur tout en maintenant la compatibilité et la sécurité pendant sa phase d'adoption.

Comprendre comment le PRF s'aligne sur votre stratégie globale de Passkeys vous aide à maximiser ses avantages sans complications inutiles :

• Intégration flexible :
  Il n'est pas nécessaire de décider d'utiliser le PRF au moment de la création du Passkey. Les Passkeys existants peuvent être intégrés ultérieurement de manière transparente avec des cas d'utilisation PRF sans surcharge de gestion des identifiants.

• Mise à niveau vers le PRF :
  Comme le PRF fonctionne pendant la phase d'authentification (navigator.credentials.get()), les Passkeys créés précédemment peuvent supporter des flux basés sur le PRF à un stade ultérieur. Cela permet à votre application d'améliorer la sécurité de manière incrémentielle sans perturber les méthodes d'authentification établies. Cette approche fonctionne avec le Trousseau iCloud et le Gestionnaire de mots de passe de Google (GPM) ainsi qu'avec les nouvelles clés de sécurité. Pour les anciennes clés de sécurité, un hmac-secret pourrait n'être généré que si demandé lors de la création de l'identifiant.

• Considérations sur la complexité des Passkeys :
  Les complexités inhérentes à la gestion des Passkeys — telles que la synchronisation des identifiants, l'authentification inter-appareils et les processus de récupération — s'appliquent également lors de l'utilisation du PRF. Assurez-vous que votre implémentation du PRF s'aligne de manière cohérente avec votre stratégie globale d'authentification par Passkey, en maintenant des expériences utilisateur fluides et des contrôles de sécurité robustes.

Considérer le PRF dans le cadre d'une stratégie de Passkeys globale permet une transition plus douce vers des pratiques d'authentification plus sécurisées et plus conviviales.

Pour les entreprises et fournisseurs de services gérant des données utilisateur sensibles, la capacité d'utiliser WebAuthn PRF avec les Passkeys ouvre des possibilités pour améliorer la sécurité et l'expérience utilisateur, en particulier dans les scénarios nécessitant le chiffrement côté client d'informations personnelles identifiables (PII) ou la sécurisation d'applications qui exigent un chiffrement de bout en bout. Bien que Corbado Connect soit principalement conçu pour une intégration transparente des Passkeys en entreprise, il peut également faciliter l'implémentation d'extensions de Passkeys telles que SPC ou PRF.

Voici comment Corbado peut aider les organisations qui cherchent à intégrer le PRF :

• Faciliter le PRF pour le stockage chiffré : Dans les environnements d'entreprise, il est parfois nécessaire de stocker des informations sensibles de manière sécurisée, parfois même directement côté client pour minimiser l'exposition des PII côté serveur. Corbado Connect peut être configuré pour demander des valeurs PRF pendant le flux d'authentification par Passkey (navigator.credentials.get()), permettant aux applications de dériver les clés cryptographiques nécessaires.
• Modèles de stockage flexibles : Les données chiffrées à l'aide de clés dérivées du PRF peuvent être stockées de différentes manières en fonction des exigences de sécurité et de l'architecture :
  • Côté client : Stockées directement dans le navigateur à l'aide de mécanismes comme localStorage ou des cookies sécurisés. Les données en clair n'existent que de manière transitoire sur le client lors du déchiffrement.
  • Backend de Corbado (E2EE) : Bien que Corbado évite généralement de stocker les PII des clients, le mécanisme PRF permet techniquement de stocker des données chiffrées côté client sur les serveurs de Corbado. Corbado ne posséderait pas les clés pour déchiffrer ces données ; le déchiffrement se ferait toujours côté client après une authentification utilisateur réussie.
  • Backend du client : Les données chiffrées pourraient également être envoyées et stockées sur les propres systèmes backend de l'entreprise, tout en bénéficiant du chiffrement côté client.
• Flux de dérivation de clé sécurisé : Les composants de Corbado Connect gèrent l'interaction avec l'API WebAuthn. Lorsque le PRF est demandé :
  1. Une sortie PRF spécifique à l'utilisateur est générée par l'authentificateur, liée au Passkey individuel.
  2. Cette sortie est retournée en toute sécurité à l'application côté client.
  3. L'application doit ensuite utiliser une fonction de dérivation de clé (KDF) via l'API WebCrypto (par ex., HKDF) pour dériver une clé de chiffrement symétrique robuste à partir de la sortie PRF.
  4. Cette clé symétrique est utilisée avec WebCrypto (par ex., AES-GCM) pour chiffrer ou déchiffrer les informations cibles (comme les PII).
• Déchiffrement transparent lors des connexions ultérieures : Lorsque l'utilisateur s'authentifie à nouveau avec le même Passkey, Corbado Connect initie la même requête PRF. Cela produit la même sortie PRF, permettant à l'application de re-dériver la même clé symétrique et de déchiffrer les informations précédemment stockées côté client.
• Intelligence sur l'adoption du PRF : L'implémentation du PRF nécessite de savoir si l'environnement de l'utilisateur (OS, navigateur, authentificateur) le supporte. Corbado Connect collecte des signaux sur l'appareil et les capacités de l'utilisateur lors de l'authentification. Cette intelligence peut être utilisée pour :
  • Déterminer l'état de préparation au PRF au sein de la base d'utilisateurs avant d'activer complètement les fonctionnalités dépendant du PRF.
  • Implémenter le PRF de manière opportuniste, en le fournissant comme une amélioration pour les utilisateurs supportés tout en maintenant des mécanismes de repli (comme demander une nouvelle vérification ou utiliser des méthodes alternatives) pour ceux qui n'ont pas de support.
• Rationalisation de la disponibilité des PII : En utilisant le PRF pour chiffrer des PII vérifiées (par ex., des attributs d'identité obtenus via un flux de vérification) et en les stockant côté client, les applications peuvent rendre ces données immédiatement disponibles après une connexion par Passkey pour des interactions ou des transactions ultérieures, réduisant considérablement la friction par rapport à une nouvelle vérification ou à des flux basés sur une application.
• Permettre des systèmes E2EE personnalisés : Bien que Corbado Connect offre des composants d'interface utilisateur pour les flux standards, les principes sous-jacents peuvent permettre aux développeurs d'intégrer plus profondément la fonctionnalité PRF dans des applications sensibles. Cela permet de construire des systèmes chiffrés de bout en bout où l'application frontend exploite directement les clés dérivées du PRF pour des opérations cryptographiques complexes sur des données existantes ou nouvelles. Pour le moment, cela ne sera possible que de manière opportuniste et des mécanismes de repli devront implémenter une autre manière de stocker ces informations.

Corbado vise à simplifier les complexités de l'intégration des Passkeys et du PRF, permettant aux entreprises de tirer parti des standards de manière sécurisée et efficace, en s'adaptant à des cas d'utilisation spécifiques comme le chiffrement des PII côté client tout en naviguant dans un paysage en constante évolution.

L'extension WebAuthn PRF marque une étape importante pour faire des applications véritablement sans mot de passe et chiffrées de bout en bout une réalité pratique. En s'appuyant sur les Passkeys pour dériver des clés cryptographiques de manière sécurisée, elle offre une expérience utilisateur transparente et sécurisée sans compromettre la confidentialité.

Pour répondre directement aux questions posées au début de cet article :

• Cas d'utilisation intéressants du PRF : Le PRF permet des cas d'utilisation convaincants tels que le stockage de données chiffrées de bout en bout, le déchiffrement de coffres-forts sans mot de passe pour les gestionnaires de mots de passe, des schémas de rotation de clés cryptographiques sécurisés, et des portefeuilles d'identité sécurisés ou des systèmes non dépositaires qui protègent la confidentialité des utilisateurs en garantissant que les clés privées ne quittent jamais les appareils clients.

• État actuel du support du PRF (juin 2025) : Le support reste fragmenté et en évolution. Alors qu'Android bénéficie d'un support robuste sur les navigateurs et les authentificateurs, des plateformes comme macOS et surtout iOS sont instables, en particulier en tant que source CDA avec un bug sévère. Le support de Windows est principalement limité aux clés de sécurité externes, avec une absence notable de support de la plateforme native via Windows Hello.

Les développeurs qui envisagent l'extension PRF doivent anticiper une amélioration rapide, mais procéder avec prudence, en construisant des applications résilientes qui gèrent gracieusement les limitations actuelles. À mesure que l'adoption se généralise sur les principales plateformes et dans les écosystèmes d'authentificateurs, l'avenir du chiffrement sans mot de passe activé par le PRF semble prometteur, promettant une confidentialité et une convivialité améliorées dans l'authentification web.