Les "Passkeys" (WebAuthN de son petit nom technique) sont une n-ième tentative pour se débarrasser des mots de passe. Je ne retiens pas mon souffle, car tant d'autres tentatives ont échoué avant cela.
Ceci étant dit, il est amusant de constater que les Passkeys reviennent au bon vieux concept de PGP: Une clé publique et une clé privée. Le tout avec une API Javascript spécifique dans les navigateurs (Firefox la supporte déjà).
Pourquoi ça pourrait marcher ?
- Déjà parce que les GAFAM - pour une fois - sont tous ensemble pour travailler sur le sujet.
- Ensuite parce que fondamentalement les systèmes clé publique/clé privée ont fait leurs preuves en matière de sécurité.
- Et enfin parce qu'ils ont inventé un système qui a priori simplifie la gestion de ces clés (complexité de gestion qui a été à la base de l'échec de PGP).
Pourtant, il y a quand même le souci de savoir comment sont stockées et gérées ces clés privées (dans le système d'exploitation lui-même, a priori), et surtout comment les sauvegarder. Là c'est encore assez bancal.
(Par exemple sous Android, la clé privée peut être stockée sur le smartphone, et déblocable avec la lecture d'empreinte.)
Pour expliquer de manière simplifiée le processus d'authentification :
- Lorsque vous arrivez la première fois sur le site et que vous demandez à vous créer un compte, votre navigateur créé une paire de clés privées et publiques et un identifiant de clé, et envoie clé publique et identifiant au site.
- Vous arrivez les fois suivantes sur le site pour vous authentifier. Alors :
- Le site récupère l'identifiant de votre clé via l'API Javascript WebAuthN.
- Le site vous envoie un challenge (données aléatoires et quelques informations).
- Le navigateur active Passkey qui vous demande de vous authentifier (sur le périphérique: par exemple empreinte digitale sur smartphone).
- Passkey signe le challenge avec votre clé privée et la renvoie au site.
- Le site vérifie la signature du challenge avec votre clé publique.
Pourquoi c'est intéressant ?
1) Sécurité : Parce que même en cas de piratage complet du site web, le pirate n'aura que les clés publiques dont il ne pourra rien faire. Il n'a aucun mot de passe, et ne peut pas calculer la clé privée. Côté client, la clé privée est censée être bien protégée par le système d'exploitation (la plupart des OS ont un système de stockage sécurisé bien isolé, chiffré et stocké dans votre profile utilisateur. Il est déjà utilisé pour stocker vos mots de passe. Par exemple sous Linux le logiciel seamonkey permet de voir votre trousseau de clés.)
2) Simplicité : Pas de gestion complexe des clés. C'est le système d'exploitation qui s'en occupe à la demande du navigateur. Cela laisse aussi la liberté au système d'exploitation de choisir la manière de les stocker de manière sécurisée, et aussi le choix de la manière de vous authentifier (empreinte digitale, mot de passe...). Sachant que vous êtes déjà authentifié·e pour pouvoir utiliser votre système d'exploitation, le nécessaire est déjà en place.
Ce que j'en pense ?
Cette fois ça pourrait marcher, mais ma crainte est que les clés privées restent prisonnières des systèmes d'exploitation avec aucun moyen de les sauvegarder autrement que dans le cloud des GAFAM.
C'est déjà le cas de Google qui est très pressé de sauvegarder tous vos mots de passe, mais qui - à ma connaissance - n'offre pas d'option pour tout exporter. Ce qui rendrait votre identité en ligne *encore* prisonnière d'un GAFAM. C'est le risque principal actuellement à mon sens.
Je pense que les gestionnaires de mot de passe - tel Keepass - les gèreront assez rapidement, ce qui permettra au moins d'avoir un stockage non dépendant d'un GAFAM.
(
Permalink)