SRP n’envoie pas le mot de passe dans le protocole ; cela ne signifie ni absence de mot de passe, ni immunité au phishing, ni innocuité du vérificateur.
Les passkeys et SRP sont deux approches différentes de l’authentification. Une passkey utilise une paire de clés et peut supprimer le besoin d’un mot de passe. SRP reste fondé sur un mot de passe, mais, lorsque le protocole est correctement mis en œuvre, il n’envoie pas le mot de passe lui-même au serveur pour prouver qu’il est connu.
« Se connecter sans envoyer de mot de passe » n’est donc pas la même chose que « se connecter sans avoir de mot de passe ». Le choix doit reposer sur le risque de phishing, la gestion des identifiants, la récupération et la qualité de l’implémentation, et non sur une étiquette générale « à connaissance nulle ».
Que change une passkey ?
Dans l’authentification par passkey, le service conserve la clé publique et l’utilisateur confirme la connexion en contrôlant la clé privée. Le lien entre l’identifiant, le service et l’origine concernés constitue une part importante de la résistance au phishing. Explication de FIDO sur les passkeys.
Toutes les passkeys ne sont pas nécessairement synchronisées dans le cloud. Certaines sont liées à un appareil ou à une clé de sécurité ; d’autres passent d’un appareil à l’autre par un fournisseur d’identifiants. Il faut examiner le modèle de récupération et la protection de la synchronisation propres à ce fournisseur. La seule « synchronisation dans le cloud » ne permet pas de conclure que l’entreprise conserve les clés sous une forme lisible.
La sécurité de la session après connexion est aussi une question distincte. Une passkey ne neutralise automatiquement ni un logiciel malveillant sur l’appareil ni le vol d’une session valide.
Que reçoit le serveur avec SRP ?
SRP appartient à la famille des échanges de clés authentifiés par mot de passe. Au lieu de conserver le mot de passe lui-même, le serveur stocke des données telles qu’un sel et un vérificateur. En échangeant les messages du protocole, les deux parties vérifient la connaissance du secret et la clé partagée.
Mais un vérificateur n’est pas une donnée inoffensive. La section 3.3 du RFC 5054 indique explicitement qu’un attaquant qui obtient le vérificateur peut mener une attaque par dictionnaire pour deviner le mot de passe. Affirmer que « le vol de la base de données ne permet aucune tentative hors ligne » est donc faux.
Un mot de passe robuste, la protection du serveur, des paramètres adaptés, la validation des entrées et le contrôle des tentatives de connexion restent nécessaires. SRP ne garantit pas non plus que la page sur laquelle vous saisissez votre mot de passe soit sûre : un code malveillant peut le récupérer avant l’exécution du protocole.
Une comparaison équitable
| Question | Passkey | SRP |
|---|---|---|
| L’utilisateur mémorise-t-il un mot de passe du service ? | Généralement non ; il doit contrôler l’identifiant | Oui, la méthode repose sur la connaissance du mot de passe |
| Que conserve le service pour la connexion ? | Une clé publique et les informations associées | Un vérificateur et les paramètres associés |
| D’où vient la résistance au phishing ? | Du lien de l’identifiant avec le service/l’origine dans la conception FIDO | Ne pas envoyer le mot de passe dans le protocole ne suffit pas à sécuriser une fausse page de saisie |
| Le cloud est-il obligatoire ? | Non ; il existe aussi des options liées à un appareil | Le protocole n’exige pas intrinsèquement un fournisseur d’identité tiers, mais il nécessite un service d’authentification |
| Comment fonctionne la récupération ? | Cela dépend du type d’identifiant et du fournisseur | Les politiques du compte et du produit la déterminent, pas le nom SRP |
Ce tableau ne permet pas d’établir un classement absolu de toutes les implémentations. Un processus de récupération faible peut compromettre l’avantage d’une méthode de connexion robuste.
Quel rapport entre connexion au compte et clés de discussion ?
L’authentification indique au service qui est autorisé à agir. Les clés de chiffrement des messages déterminent qui peut ouvrir le contenu. Un produit peut relier ces deux éléments, mais cette relation doit être documentée.
La documentation de sécurité de Livara décrit SRP pour la connexion et présente séparément le paquet de récupération v7 de l’identité chiffrée. Ce paquet restaure l’identité, pas l’historique des discussions. Ainsi, « le mot de passe de connexion est correct » ne signifie pas que « toutes les anciennes clés et tous les anciens messages sont revenus ».
Cet article est une comparaison conceptuelle, pas un test pratique de toutes les méthodes de connexion de Livara ni une certification de la mise en œuvre exacte d’un RFC particulier dans le produit.
Quelles questions poser au moment de choisir ?
- Si l’appareil est perdu, quelle autre voie de connexion existe et qui la contrôle ?
- La récupération est-elle plus faible que la connexion principale ?
- Comment consulter et révoquer les sessions inconnues ?
- Changer la méthode de connexion modifie-t-il les clés des messages ou les appareils liés ?
- Quel compte et quelles protections indépendantes sont nécessaires à la synchronisation des identifiants ?
Conclusion : Ne qualifiez pas les passkeys d’intrinsèquement « peu sûres parce qu’elles utilisent le cloud », ni SRP d’« invulnérable aux fuites parce qu’il est à connaissance nulle ». Les limites de chaque méthode et la politique de récupération du produit fondent une comparaison fiable.
