SRP évite d’envoyer le mot de passe lors de l’échange de connexion ; il ne rend pas inoffensif un vérificateur volé.
Secure Remote Password, ou SRP, permet à un client et à un serveur de s’authentifier à l’aide d’un mot de passe sans envoyer celui-ci lors de l’échange normal du protocole. Il peut réduire l’exposition à un serveur qui recevrait autrement le mot de passe pendant la connexion.
Il ne supprime pas du serveur tous les secrets liés au mot de passe. Le serveur conserve un vérificateur, et un vérificateur volé peut permettre de deviner le mot de passe hors ligne. Cette distinction est essentielle pour évaluer les affirmations de « connexion à connaissance nulle ».
Qu’est-ce qui change par rapport à une connexion classique par mot de passe ?
Dans une conception classique, le client envoie le mot de passe sur une connexion TLS authentifiée. Un serveur bien conçu compare un hachage de mot de passe salé approprié, évite de journaliser les identifiants secrets et applique des protections contre les tentatives de devinette. TLS protège la connexion ; le hachage protège différemment le secret d’authentification stocké.
SRP modifie l’échange. Lors de l’inscription, le système établit le sel et les éléments du vérificateur. À la connexion, les deux parties utilisent de nouvelles valeurs de protocole et leurs secrets respectifs pour établir et confirmer des éléments de clé partagés. Le client utilise le mot de passe ; le serveur utilise son vérificateur. Un client honnête ne soumet pas le mot de passe lui-même comme charge utile de connexion.
La spécification SRP dans la RFC 2945 explique les fondements du protocole. Les profils et implémentations ultérieurs exigent un examen de leurs paramètres exacts et des contrôles des messages ; appeler une conception « SRP » ne démontre pas que tous les choix d’implémentation sont solides.
| Question | Connexion classique par mot de passe sur TLS | Échange SRP correctement implémenté |
|---|---|---|
| Le serveur applicatif reçoit-il le mot de passe saisi lors de la connexion ? | Normalement oui | Pas dans le cadre de l’échange du protocole |
| Quels éléments sensibles d’authentification sont stockés ? | Généralement un hachage de mot de passe salé | Un sel et un vérificateur dérivé du mot de passe |
| Une base de données volée permet-elle des essais hors ligne ? | Oui, selon les éléments stockés | Oui, les éléments d’un vérificateur SRP volé peuvent permettre des essais |
| Cela protège-t-il contre un enregistreur de frappes ? | Non | Non |
| Cela chiffre-t-il automatiquement l’historique des messages ? | Non | Non |
Pourquoi un vérificateur volé reste important
La section 3.3 de la RFC 5054 traite explicitement des vérificateurs volés. Elle explique qu’un vérificateur peut permettre à un attaquant de se faire passer pour le serveur et d’effectuer des attaques par dictionnaire pour retrouver le mot de passe.
La distinction importante est que le vérificateur n’est pas simplement un jeton de connexion client réutilisable. Cela ne le rend pas inoffensif. Un attaquant peut tester des mots de passe candidats contre les éléments volés plutôt que résoudre un problème de logarithme discret pour chaque secret possible. Un mot de passe faible ou réutilisé reste un risque sérieux.
Les limitations de fréquence en ligne peuvent ralentir les tentatives contre un service actif, mais ne régissent pas les calculs effectués sur une base de données volée. La protection de la base, le traitement soigneux des mots de passe et des mots de passe forts et uniques restent nécessaires.
Ce contre quoi SRP ne protège pas
Un terminal compromis : Un logiciel malveillant peut capturer le mot de passe avant le début du protocole ou voler ensuite une session authentifiée.
Une page de connexion malveillante : Si la page qui demande le mot de passe est elle-même hostile, elle peut envoyer le texte saisi ailleurs. Une application web a toujours besoin d’un chemin de livraison fiable.
Toutes les voies de récupération : Un parcours par courriel, SMS ou assistance qui donne accès au compte a ses propres exigences. La méthode normale de connexion la plus robuste peut être fragilisée par une solution de repli plus faible.
Toutes les attaques actives sur le réseau : Les paramètres du protocole, la validation des entrées, la confirmation mutuelle et la connexion authentifiée qui l’entoure comptent. Ne remplacez pas les protections TLS prescrites pour un déploiement par le slogan « le mot de passe ne circule jamais ».
Les métadonnées ou le chiffrement des discussions : L’authentification détermine si une session doit être admise. Elle ne détermine pas quels enregistrements de conversation existent ni qui détient les clés de déchiffrement des messages.
Comment Livara sépare connexion et récupération d’identité
La présentation de la sécurité de Livara décrit l’authentification SRP séparément de son protocole de messagerie LVR1. Elle documente également une sauvegarde d’identité chiffrée de version 7, protégée par une clé de récupération aléatoire distincte de 256 bits.
La sauvegarde est scellée cryptographiquement avant son envoi et restaure l’identité cryptographique, pas l’historique des discussions. Connaître seulement le mot de passe du compte ne restaure pas ces clés de chiffrement. Inversement, affirmer que l’assistance ne peut pas reconstruire un secret de chiffrement ne démontre pas qu’aucune action de gestion du compte ni aucun processus de changement de mot de passe ne peuvent exister.
Le modèle de menace inclut également la compromission des appareils et les métadonnées de communication visibles. SRP ne doit pas servir à qualifier l’ensemble du service de « connaissance nulle » sur tous les aspects de l’activité d’un utilisateur.
Une liste pratique d’évaluation
En tant qu’utilisateur, choisissez un mot de passe fort et unique, protégez l’appareil, conservez les éléments de récupération dans un endroit approprié et séparé, et comprenez comment révoquer les sessions. Ne saisissez pas un secret sur un site non fiable simplement parce qu’il prétend utiliser SRP.
En tant qu’examinateur technique, demandez le profil exact du protocole, le traitement du mot de passe en vérificateur, la validation des entrées, la gestion des échecs, le parcours d’inscription et la conception de la réinitialisation. Examinez ensemble le client et le serveur. Incluez des tests de valeurs publiques invalides, de rejeu et de sessions interrompues plutôt que de vous fier uniquement à un test de connexion réussi.
SRP est un outil utile pour limiter la divulgation des mots de passe lors de l’authentification. Sa valeur apparaît plus clairement lorsque ses avantages réels sont décrits avec les risques de vol de vérificateur, de compromission des terminaux et de récupération, plutôt que comme la fin des problèmes de sécurité des mots de passe.
