Salted Challenge Response Authentication Mechanism

Den här artikeln handlar om lösenordsautentisering. För annan användning, se Scram (disambiguation) .

Inom kryptografi är SCRAM (Salted Challenge Response Authentication Mechanism ) en familj av moderna, lösenordsbaserade autentiseringsmekanismer för utmaningssvar som tillhandahåller autentisering av en användare till en server . Eftersom det är specificerat för SASL ( Simple Authentication and Security Layer) , kan det användas för lösenordsbaserade inloggningar till tjänster som SMTP och IMAP ( e-post ), XMPP (chatt) eller MongoDB och PostgreSQL (databaser). För XMPP är det obligatoriskt att stödja det.

Motivering

Alice vill logga in på Bobs server. Hon måste bevisa att hon är den hon utger sig för att vara. För att lösa detta autentiseringsproblem har Alice och Bob kommit överens om ett lösenord som Alice känner till och som Bob vet hur man verifierar.

Nu kunde Alice skicka sitt lösenord via en okrypterad anslutning till Bob i en klartextform, så att han kunde verifiera det. Det skulle dock göra lösenordet tillgängligt för Mallory, som avlyssnar linjen. Alice och Bob kunde försöka kringgå detta genom att kryptera anslutningen. Men Alice vet inte om krypteringen sattes upp av Bob, och inte av Mallory genom att göra en man-i-mitten-attack . Därför skickar Alice istället en hashad version av sitt lösenord, som i CRAM-MD5 eller DIGEST-MD5 . Eftersom det är en hash, får Mallory inte själva lösenordet. Och eftersom hashen är saltad med en utmaning, kunde Mallory bara använda den för en inloggningsprocess. Men Alice vill ge lite konfidentiell information till Bob, och hon vill vara säker på att det är Bob och inte Mallory.

För att lösa detta har Bob registrerat sig hos en certifikatutfärdare (CA), som undertecknade hans certifikat. Alice kunde enbart lita på det signatursystemet, men hon vet att det har svagheter . För att ge henne ytterligare försäkran om att det inte finns någon man-i-mitten-attack skapar Bob ett bevis på att han känner till lösenordet (eller en saltad hash därav) och inkluderar sitt certifikat i detta bevis. Denna inkludering kallas kanalbindning, eftersom den lägre krypteringskanalen är "bunden" till den högre applikationskanalen.

Alice har då en autentisering av Bob, och Bob har autentisering av Alice. Tillsammans har de ömsesidig autentisering . DIGEST-MD5 aktiverade redan ömsesidig autentisering, men den var ofta felaktigt implementerad.

När Mallory kör en man-i-mitten-attack och förfalskar en CA-signatur, kan hon hämta en hash av lösenordet. Men hon kunde inte utge sig för att vara Alice ens för en enda inloggningssession, eftersom Alice inkluderade Mallorys krypteringsnyckel i sin hash, vilket resulterade i ett inloggningsfel från Bob. För att göra en helt transparent attack, skulle Mallory behöva känna till lösenordet som används av Alice, eller Bobs hemliga krypteringsnyckel.

Bob har hört talas om dataintrång i serverdatabaser och han bestämde sig för att han inte vill lagra sina användares lösenord i klartext. Han har hört talas om inloggningsschemana CRAM-MD5 och DIGEST-MD5, men han vet, för att erbjuda dessa inloggningsscheman till sina användare, måste han lagra svagt hashade, osaltade lösenord. Han gillar inte idén, och därför väljer han att kräva lösenorden i klartext. Sedan kan han hasha dem med säkra hash-scheman som bcrypt , scrypt eller PBKDF2 , och salta dem som han vill. Men då skulle Bob och Alice fortfarande möta problemen som beskrivs ovan. För att lösa detta problem använder de SCRAM, där Bob kan lagra sitt lösenord i ett saltat format, med hjälp av PBKDF2. Under inloggningen skickar Bob Alice sitt salt och iterationsantalet för PBKDF2-algoritmen, och sedan använder Alice dessa för att beräkna det hashade lösenordet som Bob har i sin databas. Alla ytterligare beräkningar i SCRAM baseras på detta värde som båda känner till.

Protokollöversikt

Även om alla klienter och servrar måste stödja hashalgoritmen SHA-1 , är SCRAM, till skillnad från CRAM-MD5 eller DIGEST-MD5 , oberoende av den underliggande hashfunktionen. Alla hash-funktioner som definieras av IANA kan användas istället. Som nämnts i avsnittet Motivation använder SCRAM PBKDF2 -mekanismen, vilket ökar styrkan mot brute-force-attacker , när en dataläcka har inträffat på servern. Låt H vara den valda hashfunktionen, givet av namnet på algoritmen som annonseras av servern och valts av klienten. 'SCRAM-SHA-1' använder till exempel SHA-1 som hashfunktion.

Lösenordsbaserad nyckel, eller saltat lösenord

Klienten härleder en nyckel, eller saltat lösenord, från lösenordet, ett salt och ett antal beräkningsiterationer enligt följande:

SaltedPassword = H( password , salt , iteration-count ) = PBKDF2 ( HMAC , password , salt , iteration-count , output length of H) .

Meddelanden

RFC 5802 namnger fyra på varandra följande meddelanden mellan server och klient:

klient-först Meddelandet
klient -först består av en GS2- header (innefattande en kanalbindningsflagga och valfritt namn för behörighetsinformation), det önskade användarnamnet och en slumpmässigt genererad klient nonce c-nonce .
server-first
Servern lägger till den här klienten nonce sin egen nonce s-nonce , och lägger till det i server-first -meddelandet, som också innehåller ett salt som används av servern för att salta användarens lösenords-hash, och en iteration count iteration-count .
client-final
Efter det skickar klienten det slutliga klientmeddelandet som innehåller kanalbindning , GS2-huvudet och kanalbindningsdata kodade i base64, sammanlänkningen av klienten och servern nonce, och klientbeviset, proof .
server-final
Kommunikationen avslutas med server- slutmeddelandet, som innehåller serversignaturen, verifier .

Bevis

Klienten och servern bevisar för varandra att de har samma Auth -variabel, bestående av:

Auth = klient-först-utan-rubrik + , + server-först + , + klient-slutlig-utan-bevis (sammanfogat med kommatecken)

Mer konkret tar detta formen:

= r= c‑nonce ,[ extensions ,]r= c‑nonce ‖ s‑nonce ,s= salt ,i= iteration-count ,[ extensions ,]c=base64( channel-flag ,[a= authzid ], kanal ‑bindande ),r= c‑nonce ‖ s‑nonce [, tillägg ]

Bevisen beräknas enligt följande:

ClientKey = HMAC( SaltedPassword , 'Client Key')
ServerKey = HMAC( SaltedPassword , 'Server Key')
ClientProof = p = ClientKey XOR HMAC(H( ClientKey ), Auth )
ServerSignature = v = HMAC( ServerKey , Auth )

där XOR- operationen tillämpas på bytesträngar av samma längd, är H( ClientKey ) en normal hash av ClientKey . 'Client Key' och 'Server Key' är ordagrant strängar.

Servern kan auktorisera klienten genom att beräkna ClientKey från ClientProof och sedan jämföra H(ClientKey) med det lagrade värdet.

Klienten kan auktorisera servern genom att beräkna och jämföra ServerSignature direkt.

Lagrat lösenord

Servern lagrar endast användarnamn, salt , iteration-count , H( ClientKey ) , ServerKey . Servern har tillfällig åtkomst till H( ClientKey ) ClientKey när den återställs från klientbeviset, efter att ha krypterats med .

Klienten behöver bara lösenordet .

Kanalbindning

Termen kanalbindning beskriver man-in-the-middle-attackförebyggande strategi för att "binda" ett applikationslager , som ger ömsesidig autentisering, till ett lägre (oftast krypterings-) lager, vilket säkerställer att ändpunkterna för en anslutning är desamma i båda skikten. Det finns två allmänna riktningar för kanalbindning: unik och slutpunktskanalbindning . Den första säkerställer att en specifik anslutning används, den andra att ändpunkterna är desamma.

Det finns flera kanalbindningstyper, där varje enskild typ har ett unikt kanalbindningsprefix . Varje kanalbindningstyp specificerar innehållet i kanalbindningsdata , vilket ger unik information över kanalen och slutpunkterna. Till exempel, för tls-server-end-point- kanalbindningen är det serverns TLS-certifikat.

Ett exempel på kanalbindning med SCRAM som applikationslager kan vara med Transport Layer Security (TLS) som lägre lager. TLS skyddar mot passiv avlyssning, eftersom kommunikationen är krypterad. Men om klienten inte autentiserar servern (t.ex. genom att verifiera serverns certifikat), förhindrar detta inte man-in-the-middle-attacker. För detta måste slutpunkterna försäkra sina identiteter till varandra, vilket kan tillhandahållas av SCRAM.

gs2 -cbind-flag SCRAM-variabeln anger om klienten stöder kanalbindning eller inte, eller tror att servern inte stöder kanalbindning, och c-bind-ingången innehåller gs2-cbind-flaggan tillsammans med kanalbindningens unika prefix och själva kanalbindningsdata .

Kanalbindning är valfritt i SCRAM, och variabeln gs2-cbind-flag förhindrar nedgraderingsattacker .

När en server stöder kanalbindning lägger den till teckensekvensen '-PLUS' till det annonserade SCRAM-algoritmnamnet.

Styrkor

  • Stark lösenordslagring: När den implementeras på ett rätt sätt kan servern lagra lösenorden i ett saltat , itererat hashformat, vilket gör offlineattacker svårare och minskar effekten av databasintrång.
  • Enkelhet: Att implementera SCRAM är lättare än DIGEST-MD5.
  • Interoperabilitet: RFC kräver att UTF-8 används för användarnamn och lösenord, till skillnad från CRAM-MD5.
  • Eftersom endast den saltade och hashade versionen av ett lösenord används i hela inloggningsprocessen, och saltet på servern inte ändras, kan en klient som lagrar lösenord lagra de hashade versionerna och inte exponera klartextlösenordet för angripare. Sådana hashade versioner är bundna till en server, vilket gör detta användbart vid återanvändning av lösenord.

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Salted_Challenge_Response_Authentication_Mechanism&oldid=1137787820 "