SRP : protocole de mot de passe sécurisé à distance

Le protocole Secure Remote Password (SRP) a été mis au point par Tom Wu à Stanford et publié sous la forme de la RFC 2945 en 2000, une version améliorée, SRP-6a, ayant été définie ultérieurement. SRP permet une authentification mutuelle fondée sur un mot de passe partagé sans jamais transmettre le mot de passe lui-même, même sous forme chiffrée.

Lors de l’inscription à SRP, le client calcule un vérificateur de mot de passe v = g^x mod N, où x = H(salt || password) et N est un grand nombre premier sûr. Le serveur ne stocke que le sel et le vérificateur v. Même si la base de données du serveur est compromise, le vérificateur stocké ne révèle pas directement le mot de passe.

Lors de la connexion SRP, le client et le serveur effectuent tous deux un échange de type Diffie-Hellman qui génère une clé de session partagée. Le calcul effectué de chaque côté intègre la valeur dérivée du mot de passe ; la clé de session obtenue ne peut donc être calculée correctement que par une personne qui connaît respectivement le mot de passe et le vérificateur.

SRP fournit une authentification mutuelle : le client prouve qu’il connaît le mot de passe et le serveur prouve qu’il détient le vérificateur légitime. Cela empêche les attaques d’hameçonnage dans lesquelles un faux serveur tenterait de recueillir des informations sur le mot de passe, car un faux serveur ne peut pas terminer correctement l’échange SRP sans le véritable vérificateur.

Le vérificateur est calculé comme v = g^x mod N où x = H(salt || password), g est un générateur et N est un nombre premier sûr de 2048 bits ou plus. Le problème du logarithme discret rend pratiquement impossible le calcul de x à partir de v. Le mot de passe ne peut être vérifié qu’en menant à bien l’échange SRP complet.

SRP-6a corrige les faiblesses des conceptions SRP-3 et SRP-6 originales en introduisant un paramètre multiplicateur k = H(N, g) et en modifiant l’ordre des calculs effectués par le client et le serveur. Ces changements empêchent certaines attaques de devinette permettant de tester deux hypothèses pour le coût d’une seule et garantissent que la contribution du serveur est liée dès le début du protocole.

SRP a connu un déploiement important dans le monde réel. Apple utilise SRP pour synchroniser le trousseau iCloud et permettre aux appareils de récupérer ses données sans révéler le mot de passe du compte aux serveurs d’Apple. 1Password a utilisé SRP dans son modèle d’authentification afin d’empêcher l’exposition des identifiants côté serveur.

Comme SRP génère une clé de session qui lie à la fois le mot de passe et le vérificateur du serveur, un serveur d’hameçonnage ne peut pas terminer correctement l’échange SRP. Une connexion à un site d’hameçonnage via SRP échouera à l’authentification, ce qui fournit une protection intégrée contre l’hameçonnage, absente de la soumission traditionnelle de mots de passe.

SRP est coûteux en calcul et nécessite une exponentiation modulaire sur de grands entiers (d’au moins 2048 bits). Sa mise en œuvre correcte est complexe, car la validation des paramètres comporte de nombreuses subtilités qui ont entraîné des vulnérabilités. Le protocole nécessite également un canal sécurisé (TLS) pour empêcher l’écoute passive de l’échange lui-même.

La RFC 5054 définit des suites cryptographiques TLS-SRP qui intègrent directement l’authentification mutuelle SRP à l’échange TLS. Cela élimine le besoin de certificats de serveur tout en fournissant une authentification mutuelle chiffrée. Toutefois, TLS-SRP a été peu adopté en pratique, car FIDO2 et OPAQUE se sont imposés comme des alternatives plus modernes.

Bien que SRP ait été révolutionnaire, des alternatives modernes comme OPAQUE offrent de meilleures garanties de sécurité (notamment une résistance au précalcul), et FIDO2 et les clés d’accès éliminent entièrement les mots de passe. Pour les nouveaux systèmes, OPAQUE ou FIDO2 sont préférables, mais SRP reste un choix valable pour les systèmes qui nécessitent une authentification mutuelle par mot de passe sans vulnérabilité à l’hameçonnage.

SRP stocke un vérificateur de mot de passe, et non le mot de passe, génère une clé de session partagée au moyen d’un échange de type DH et fournit une authentification mutuelle résistante à l’hameçonnage. SRP-6a améliore la version originale en résistant aux attaques de devinette. Le trousseau iCloud d’Apple et 1Password utilisent SRP en production. OPAQUE et FIDO2 sont les successeurs modernes à privilégier pour les nouveaux systèmes.