Authentification FIDO2

Lorsqu'un client enregistre une passkey, l'authentificateur génère une paire de clés propre au service. La recommandation W3C Web Authentication, recommandation W3C depuis avril 2021, indique que la clé privée est liée à un authentificateur et ne devrait jamais être exposée à un tiers, tandis que la clé publique est transmise au service qui la conserve. À la connexion, le service envoie un défi, l'authentificateur le signe et le service vérifie la signature avec la clé publique conservée.

Pour une banque, la base ne mérite plus d'être compromise pour voler des identifiants. Un tableau de clés publiques volé ne permet pas d'authentifier un client bancaire. Comparez avec un fichier de mots de passe, dont l'intérêt pour l'attaquant vient du stockage de ce que présente le client, et vous comprendrez pourquoi la FIDO Alliance parle de supprimer le secret partagé plutôt que de mieux le protéger.

Deux spécifications remplissent des fonctions distinctes lors de la connexion: WebAuthn est l'API côté navigateur, appelée par l'application bancaire, le navigateur gérant la cérémonie. CTAP, Client to Authenticator Protocol de FIDO Alliance, permet au navigateur de communiquer avec un authentificateur externe, par exemple une clé de sécurité USB ou NFC. La spécification W3C cite CTAP parmi ses dépendances et impose l'encodage CBOR canonique CTAP2, point de liaison entre les deux.

Un authentificateur de plateforme, l'élément sécurisé du téléphone ou ordinateur, est accessible par le même appel WebAuthn sans protocole externe. Pour l'ingénierie, une intégration couvre donc les deux cas, contrairement à l'époque où chaque fournisseur de jetons livrait son middleware. Pour la sécurité, les questions sur l'authentificateur passent de l'intégration à l'appareil.

L'identifiant est limité à un identifiant de partie de confiance, et la spécification W3C est explicite: une clé publique ne peut authentifier qu'auprès de l'entité identifiée par ce RP ID où elle a été enregistrée. Le navigateur indique l'origine demandeuse à l'authentificateur, qui n'a simplement aucun identifiant à proposer si elle ne correspond pas.

Un client sur une fausse page convaincante lit ou saisit le code, l'attaquant le transmet à la vraie banque durant sa validité, et le client suivant les instructions a déjoué le contrôle. La passkey ne peut être relayée, car le domaine adverse n'est pas celui enregistré, et persuader le client n'y change rien. Le BSI décrit précisément cette catégorie comme résistante au phishing pour cette raison.

Une passkey liée à l'appareil reste sur l'authentificateur qui l'a créée. La perte de l'appareil supprime aussi l'identifiant, exigeant une procédure de récupération sûre. Une passkey synchronisée est sauvegardée via le compte de plateforme du client et apparaît sur ses autres appareils; l'adoption est facilitée car changer de téléphone ne force pas à se réinscrire auprès de chaque banque.

La banque doit déterminer comment cette synchronisation affecte le facteur de possession utilisé. Si l'identifiant peut apparaître sur un nouvel appareil après connexion à un compte de plateforme, la preuve de possession bancaire porte en partie sur ce compte. L'EBA définit les exigences des facteurs concernées, et l'authentification forte du client couvre la règle et ses catégories. La plupart des établissements acceptent donc les passkeys synchronisées pour l'accès à faible risque et exigent autre chose pour les opérations transférant de l'argent.

Un client perdra son authentificateur, et votre réaction définira votre vrai niveau de sécurité. Si la récupération passe par un appel au support demandant une date de naissance, l'attaquant incapable de voler la passkey par phishing téléphonera, et tout l'investissement dépendra de cette conversation. NIST SP 800-63B intègre l'association et le remplacement d'un authentificateur perdu à la conception de l'authentification plutôt qu'à une réflexion opérationnelle ultérieure.

Les conceptions solides partagent une approche: enregistrer plusieurs authentificateurs tant que le client a accès, pour rendre la perte ordinaire plutôt que critique, et garantir une récupération au moins aussi solide que l'identifiant remplacé. Les orientations d'authentification du BSI vont dans ce sens. Si la récupération est plus faible, indiquez-le clairement dans l'évaluation des risques, afin que l'évaluation documente ce contrôle plus faible.

Dans un modèle délégué, un commerçant ou portefeuille authentifie et l'émetteur accepte le résultat, au lieu de renvoyer le client à sa banque. Le client évite une transition perturbante durant l'achat, tandis que l'émetteur se fie à un contrôle réalisé ailleurs, sous contrat définissant sa nature.

La passkey déjà détenue chez le commerçant intéresse alors l'émetteur, et la responsabilité devient un sujet, car celui qui contrôle et celui qui supporte la perte diffèrent. Les paiements par carte en Allemagne couvrent le volet commercial et PSD3 et le PSR l'orientation législative.

La connexion client est la moitié dont tout le monde parle, mais l'accès salarié est celui où un détournement fait le plus de dégâts, car les identifiants administrateur ouvrent plus que ceux d'un client. Le même identifiant FIDO2 fonctionne ici et supprime l'attaque initiale la plus fréquente, un salarié convaincu de s'authentifier sur une page étrangère à la banque.

DORA inclut droits d'accès et gestion des identités dans les obligations de protection TIC des entités financières européennes, faisant de cette protection une obligation réglementaire pour ces entités financières. Le zero trust bancaire traite de l'architecture supposant un vol d'identifiant, et l'identité machine bancaire des identifiants jamais utilisés par un salarié pour se connecter.

Une passkey peut offrir deux facteurs si déverrouiller l'authentificateur exige biométrie ou PIN, l'appareil enregistré constituant un élément et l'empreinte ou le PIN libérant la clé un second. L'acceptation de deux éléments indépendants par le superviseur dépend de la conservation et synchronisation de la clé, expliquant l'importance concrète de la distinction entre synchronisée et liée à l'appareil. La règle et ses catégories figurent dans l'authentification forte du client.

Une passkey liée à l'appareil disparaît et le client doit utiliser la récupération. Une passkey synchronisée réapparaît sur l'appareil suivant connecté à son compte de plateforme, favorisant l'adoption mais obligeant la banque à évaluer l'intérêt de ce compte pour un attaquant. Dans les deux cas, un second authentificateur enregistré rend la perte mineure.

Une passkey empêche l'attaquant de capturer un élément réutilisable à la connexion, sans empêcher un appelant de convaincre le client de payer lui-même. Ces contrôles diffèrent, et la prévention de la fraude en Allemagne couvre les paiements.

Un authentificateur intégré au téléphone ou ordinateur est accessible par le même appel WebAuthn, donc la plupart des clients n'ont jamais de clé distincte. Les clés externes USB ou NFC utilisent CTAP et restent utiles pour séparer l'identifiant de l'appareil, choix courant pour l'accès administrateur.