SRP: Secure Remote Password Protocol

Secure Remote Password (SRP)-protokollen blev udviklet af Tom Wu på Stanford og udgivet som RFC 2945 i 2000, og en forbedret version, SRP-6a, blev senere defineret. SRP muliggør gensidig autentifikation baseret på en delt adgangskode uden nogensinde at overføre selve adgangskoden, heller ikke i krypteret form.

Under SRP-registrering beregner klienten en adgangskodeverifikator v = g^x mod N, hvor x = H(salt || password), og N er et stort sikkert primtal. Serveren gemmer kun saltet og verifikatoren v. Selv hvis serverens database kompromitteres, afslører den lagrede verifikator ikke adgangskoden direkte.

Under SRP-logon udfører klienten og serveren en Diffie-Hellman-lignende udveksling, som genererer en delt sessionsnøgle. Beregningen på hver side inkorporerer den adgangskodeafledte værdi, så den resulterende sessionsnøgle kun kan beregnes korrekt af en, der henholdsvis kender adgangskoden og verifikatoren.

SRP giver gensidig autentifikation: Klienten beviser, at den kender adgangskoden, og serveren beviser, at den har den legitime verifikator. Det forhindrer phishingangreb, hvor en falsk server forsøger at indsamle adgangskodeoplysninger, fordi en falsk server ikke kan fuldføre SRP-udvekslingen korrekt uden den rigtige verifikator.

Verifikatoren beregnes som v = g^x mod N, hvor x = H(salt || password), g er en generator, og N er et sikkert primtal på 2048 bit eller mere. Problemet med den diskrete logaritme gør det beregningsmæssigt umuligt i praksis at genskabe x ud fra v. Adgangskoden kan kun verificeres ved at fuldføre hele SRP-udvekslingen korrekt.

SRP-6a håndterer svagheder i de oprindelige SRP-3- og SRP-6-udformninger ved at indføre en multiplikatorparameter k = H(N, g) og ændre rækkefølgen af beregningerne på klienten og serveren. Disse ændringer forhindrer visse to-for-én-gætteangreb og sikrer, at serverens bidrag bindes tidligt i protokollen.

SRP er blevet anvendt betydeligt i virkelige systemer. Apple bruger SRP i synkroniseringen af iCloud Keychain, så enheder kan hente nøgleringsdata uden at afsløre kontoens adgangskode for Apples servere. 1Password har brugt SRP i sin autentifikationsmodel for at forhindre eksponering af legitimationsoplysninger på serversiden.

Fordi SRP genererer en sessionsnøgle, der knytter både adgangskoden og serverens verifikator sammen, kan en phishingserver ikke fuldføre SRP-håndtrykket korrekt. En bruger, der opretter forbindelse til et phishingwebsted via SRP, vil ikke kunne autentificere sig, hvilket giver en indbygget egenskab mod phishing, som ikke findes ved traditionel indsendelse af adgangskoder.

SRP er beregningsmæssigt krævende, fordi det kræver modulær eksponentiering med store heltal (2048 bit eller mere). Det er komplekst at implementere korrekt, og mange subtile faldgruber i parametervalideringen har ført til sårbarheder i implementeringer. Protokollen kræver også en sikker kanal (TLS) for at forhindre passiv aflytning af selve udvekslingen.

RFC 5054 definerer TLS-SRP-krypteringspakker, der integrerer SRP-gensidig autentifikation direkte i TLS-håndtrykket. Det fjerner behovet for servercertifikater og giver stadig krypteret gensidig autentifikation. TLS-SRP har dog i praksis fået begrænset udbredelse, fordi FIDO2 og OPAQUE er kommet frem som mere moderne alternativer.

Selvom SRP var banebrydende, giver moderne alternativer som OPAQUE stærkere sikkerhedsgarantier (modstand mod forudberegning), og FIDO2/adgangsnøgler fjerner adgangskoder helt. Til nye systemer foretrækkes OPAQUE eller FIDO2, men SRP er stadig et gyldigt valg til systemer, der kræver adgangskodebaseret gensidig autentifikation uden sårbarhed over for phishing.

SRP gemmer en adgangskodeverifikator, ikke adgangskoden, genererer en delt sessionsnøgle gennem en DH-lignende udveksling og giver gensidig autentifikation, der modstår phishing. SRP-6a forbedrer den oprindelige version med modstandsdygtighed over for gætteangreb. Apples iCloud Keychain og 1Password bruger SRP i produktion. OPAQUE og FIDO2 er moderne efterfølgere til nye systemer.