Digest adgangsgodkendelse - Digest access authentication

HTTP
Anmod om metoder
Overskriftsfelter
Svarstatuskoder
Sikkerhedsadgangskontrolmetoder
Sikkerhedsrisici

Digest-adgangsgodkendelse er en af ​​de aftalte metoder, en webserver kan bruge til at forhandle legitimationsoplysninger, f.eks. Brugernavn eller adgangskode, med en brugers webbrowser . Dette kan bruges til at bekræfte en brugers identitet, før du sender følsomme oplysninger, f.eks. Online banktransaktionshistorik. Det anvender en hash -funktion til brugernavnet og adgangskoden, før de sendes over netværket. I modsætning hertil basistilslutning autentificering anvender let reversible Base64 koder i stedet for hashing, hvilket gør det ikke-sikre medmindre anvendes i forbindelse med TLS .

Teknisk er fordøjelsesgodkendelse en applikation af MD5 -kryptografisk hash med brug af nonce -værdier for at forhindre gentagelsesangreb . Den bruger HTTP -protokollen.

Oversigt

Digest -adgangsgodkendelse blev oprindeligt specificeret af RFC 2069 ( en udvidelse til HTTP: Digest Access Authentication ). RFC 2069 specificerer nogenlunde et traditionelt fordøjelsesgodkendelsesskema med sikkerhed opretholdt af en servergenereret nonce-værdi . Godkendelsessvaret dannes som følger (hvor HA1 og HA2 er navne på strengvariabler): 

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)

En MD5-hash er en værdi på 16 byte. HA1- og HA2 -værdierne, der bruges til beregning af svaret, er henholdsvis den hexadecimale repræsentation (i små bogstaver) af MD5 -hash -hash.

RFC 2069 blev senere erstattet af RFC 2617 ( HTTP Authentication: Basic and Digest Access Authentication ). RFC 2617 introducerede en række valgfrie sikkerhedsforbedringer til at fordøje godkendelse; "kvalitet af beskyttelse" (qop) , nonce-tæller øget af klienten og en klientgenereret tilfældig nonce. Disse forbedringer er designet til at beskytte mod for eksempel valgt-klartekst angreb kryptoanalyse .

Hvis algoritmedirektivets værdi er "MD5" eller uspecificeret, så er HA1 

HA1 = MD5(username:realm:password)

Hvis algoritmedirektivets værdi er "MD5-sess", så er HA1 

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

Hvis qop -direktivets værdi er "auth" eller ikke er specificeret, er HA2 det 

HA2 = MD5(method:digestURI)

Hvis qop-direktivets værdi er "auth-int", så er HA2 

HA2 = MD5(method:digestURI:MD5(entityBody))

Hvis qop-direktivets værdi er "auth" eller "auth-int", skal du beregne svaret som følger: 

response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

Hvis qop -direktivet er uspecificeret, skal du beregne svaret som følger: 

response = MD5(HA1:nonce:HA2)

Ovenstående viser, at når qop ikke er specificeret, følges den enklere RFC 2069 -standard.

I september 2015 erstattede RFC 7616 RFC 2617 ved at tilføje 4 nye algoritmer: "SHA-256", "SHA-256-sess", "SHA-512-256" og "SHA-512-256-sess". Kodningen svarer til "MD5" og "MD5-sess" algoritmer, med MD5 hashfunktion erstattet med SHA-256 og SHA-512-256 . Fra juli 2021 understøtter imidlertid ingen af ​​populære browsere, inklusive Firefox og Chrome, SHA-256 som hash-funktionen. Fra oktober 2021 understøtter Firefox 93 officielt "SHA-256" og "SHA-256-sess" algoritmer til fordøjelsesgodkendelse. Understøttelse af "SHA-512-256", "SHA-512-256-sess" -algoritmer og brugernavn-hash mangler dog stadig.

Virkning af MD5 -sikkerhed på fordøjelsesgodkendelse

De MD5 beregninger, der anvendes i HTTP fordøje godkendelse er beregnet til at være " en vej ", hvilket betyder, at det skal være vanskeligt at bestemme den oprindelige indgang, når kun output er kendt. Hvis adgangskoden i sig selv er for simpel, kan det dog være muligt at teste alle mulige input og finde et matchende output (et brute-force-angreb )-måske hjulpet af en ordbog eller passende opslagsliste, som let kan bruges til MD5 ledig.

HTTP-ordningen blev designet af Phillip Hallam-Baker på CERN i 1993 og indeholder ikke efterfølgende forbedringer i godkendelsessystemer, såsom udvikling af keyed-hash-meddelelsesgodkendelseskode ( HMAC ). Selvom den kryptografiske konstruktion, der bruges, er baseret på MD5 -hashfunktionen, blev det i 2004 generelt antaget , at kollisionsangreb ikke påvirker applikationer, hvor klarteksten (dvs. adgangskoden) ikke kendes. Krav i 2006 medfører imidlertid også tvivl om andre MD5 -applikationer. Indtil videre har MD5 -kollisionsangreb imidlertid ikke vist sig at udgøre en trussel mod fordøjelse af autentificering, og RFC 2617 giver servere mulighed for at implementere mekanismer til at opdage nogle kollisioner og afspille angreb .

Overvejelser vedrørende HTTP -fordøjelsesgodkendelse

Fordele

HTTP-fordøjelsesgodkendelse er designet til at være mere sikker end traditionelle fordøjelsesgodkendelsesordninger, for eksempel "betydeligt stærkere end (f.eks. CRAM-MD5 ..." (RFC 2617).

Nogle af sikkerhedsstyrkerne ved HTTP -fordøjelsesgodkendelse er:

  • Adgangskoden sendes ikke klar til serveren.
  • Adgangskoden bruges ikke direkte i fordøjelsen, men derimod HA1 = MD5 (brugernavn: realm: password). Dette tillader nogle implementeringer (f.eks. JBoss ) at gemme HA1 frem for cleartext -adgangskoden (se dog ulemper ved denne tilgang)
  • Client nonce blev introduceret i RFC 2617, som gør det muligt for klienten at forhindre udvalgte klartekstangreb , f.eks. Regnbue-borde, der ellers kunne true fordøjelsesgodkendelsesordninger
  • Server nonce må indeholde tidsstempler. Derfor kan serveren inspicere nonce -attributter indsendt af klienter for at forhindre gentagelsesangreb
  • Serveren har også lov til at føre en liste over nyligt udstedte eller brugte server -nonce -værdier for at forhindre genbrug
  • Det forhindrer phishing, fordi den almindelige adgangskode aldrig sendes til nogen server, det være sig den korrekte server eller ej. (Offentlige nøglesystemer er afhængige af, at brugeren kan kontrollere, at webadressen er korrekt.)

Ulemper

Der er flere ulemper ved godkendelse af fordøjelsesadgang:

  • Websitet har ingen kontrol over brugergrænsefladen, der præsenteres for slutbrugeren.
  • Mange af sikkerhedsmulighederne i RFC 2617 er valgfri. Hvis beskyttelseskvalitet (qop) ikke er angivet af serveren, fungerer klienten i en sikkerhedsreduceret ældre RFC 2069-tilstand
  • Digest-adgangsgodkendelse er sårbar over for et menneske-i-midten-angreb (MITM) . For eksempel kan en MITM -angriber fortælle klienter at bruge grundlæggende adgangsgodkendelse eller ældre RFC2069 -adgangsgodkendelsestilstand. For at udvide dette yderligere giver Digest Access -godkendelse ingen mekanisme for klienter til at verificere serverens identitet
  • En server kan gemme HA1 = MD5 (brugernavn: realm: password) i stedet for selve adgangskoden. Men hvis den lagrede HA1 lækker, kan en angriber generere gyldige svar og få adgang til dokumenter i riget lige så let, som hvis de havde adgang til selve adgangskoden. Tabellen med HA1 -værdier skal derfor beskyttes lige så sikkert som en fil, der indeholder almindelige tekstadgangskoder.
  • Digest access -godkendelse forhindrer brug af en stærk password -hash (f.eks. Bcrypt ) ved lagring af adgangskoder (da enten adgangskoden eller det fordøjede brugernavn, rige og adgangskode skal kunne gendannes)

Da MD5-algoritmen ikke er tilladt i FIPS , fungerer HTTP Digest-godkendelse ikke med FIPS-certificerede kryptomoduler.

Alternative godkendelsesprotokoller

Langt den mest almindelige tilgang er at bruge en HTTP+HTML- formbaseret godkendelse- klartekstprotokol, eller mere sjældent Grundlæggende adgangsgodkendelse . Disse svage klartekstprotokoller, der bruges sammen med HTTPS -netværkskryptering, løser mange af de trusler, som fordøjelse af adgangsgodkendelse er designet til at forhindre. Denne brug af HTTPS er imidlertid afhængig af, at slutbrugeren præcist validerer, at de får adgang til den korrekte URL hver gang for at forhindre, at deres adgangskode sendes til en server, der ikke er betroet, hvilket resulterer i phishing -angreb. Brugere undlader ofte at gøre dette, og derfor er phishing blevet den mest almindelige form for sikkerhedsbrud.

Nogle stærke godkendelsesprotokoller til webbaserede applikationer, der lejlighedsvis bruges, omfatter:

Eksempel med forklaring

Følgende eksempel blev oprindeligt givet i RFC 2617 og udvides her til at vise den fulde tekst, der forventes for hver anmodning og svar . Bemærk, at kun beskyttelseskodens "auth" (godkendelse) kvalitet er dækket-fra april 2005 er det kun Opera og Konqueror webbrowsere, der vides at understøtte "auth-int" (godkendelse med integritetsbeskyttelse). Selvom specifikationen nævner HTTP -version 1.1, kan skemaet tilføjes til en version 1.0 -server, som vist her.

Denne typiske transaktion består af følgende trin:

  1. Klienten beder om en side, der kræver godkendelse, men ikke angiver et brugernavn og en adgangskode. Dette skyldes typisk, at brugeren simpelthen har indtastet adressen eller fulgt et link til siden.
  2. Serveren reagerer med 401 "Uautoriseret" svarskode, der giver godkendelsesområdet og en tilfældigt genereret engangsværdi kaldet en nonce .
  3. På dette tidspunkt præsenterer browseren autentificeringsområdet (typisk en beskrivelse af computeren eller systemet, der er adgang til) for brugeren og beder om et brugernavn og en adgangskode. Brugeren kan beslutte at annullere på dette tidspunkt.
  4. Når et brugernavn og en adgangskode er angivet, sender klienten den samme anmodning igen, men tilføjer et godkendelsesoverskrift, der indeholder svarskoden.
  5. I dette eksempel accepterer serveren godkendelsen, og siden returneres. Hvis brugernavnet er ugyldigt og/eller adgangskoden er forkert, returnerer serveren muligvis "401" -svarskoden, og klienten beder brugeren igen.
Klientanmodning (ingen godkendelse)
GET /dir/index.html HTTP/1.0
Host: localhost

(efterfulgt af en ny linje , i form af en vognretur efterfulgt af et liniefoder ).

Server svar
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="testrealm@host.com",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>
Klientanmodning (brugernavn "Mufasa", adgangskode "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

(efterfulgt af en tom linje, som før).

Server svar
HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

(efterfulgt af en tom linje og HTML -tekst på den begrænsede side).

"Svar" -værdien beregnes i tre trin som følger. Hvor værdier kombineres, afgrænses de af kolon.

  1. MD5 -hash for det kombinerede brugernavn, godkendelsesområde og adgangskode beregnes. Resultatet kaldes HA1.
  2. MD5 -hash for den kombinerede metode og fordøjelses -URI beregnes, fx af "GET"og "/dir/index.html". Resultatet kaldes HA2.
  3. MD5 -hash for det kombinerede HA1 -resultat, server nonce (nonce), anmodningstæller (nc), klient nonce (cnonce), kvalitet af beskyttelseskode (qop) og HA2 -resultat beregnes. Resultatet er "svar" -værdien fra klienten.

Da serveren har de samme oplysninger som klienten, kan svaret kontrolleres ved at udføre den samme beregning. I eksemplet ovenfor er resultatet dannet som følger, hvor MD5()repræsenterer en funktion, der bruges til at beregne en MD5 -hash , tilbagestrækninger repræsenterer en fortsættelse, og de viste citater bruges ikke i beregningen.

Afslutning af eksemplet i RFC 2617 giver følgende resultater for hvert trin. 

   HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
       = 939e7578ed9e3c518a452acee763bce9

   HA2 = MD5( "GET:/dir/index.html" )
       = 39aff3a2bab6126f332b942af96d3366

   Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
                    dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                    00000001:0a4f113b:auth:\
                    39aff3a2bab6126f332b942af96d3366" )
            = 6629fae49393a05397450978507c4ef1

På dette tidspunkt kan klienten fremsætte en anden anmodning og genbruge serverens nonce -værdi (serveren udsteder kun en ny nonce for hvert "401" -svar), men giver en ny klient -nonce (cnonce). For efterfølgende anmodninger skal den hexadecimale anmodningstæller (nc) være større end den sidste værdi, den brugte - ellers kunne en angriber simpelthen " afspille " en gammel anmodning med de samme legitimationsoplysninger. Det er op til serveren at sikre, at tælleren stiger for hver af de nonce -værdier, den har udstedt, og afviser eventuelle dårlige anmodninger korrekt. Det er klart, at ændring af metoden, URI og/eller tællerværdi vil resultere i en anden responsværdi.

Serveren skal huske nonce -værdier, som den for nylig har genereret. Det kan også huske, hvornår hver nonce -værdi blev udstedt, og udløbe dem efter et bestemt stykke tid. Hvis der bruges en udløbet værdi, skal serveren svare med "401" -statuskoden og tilføje stale=TRUEtil godkendelsesoverskriften, hvilket angiver, at klienten skal sende igen med den nye nonce, uden at anmode brugeren om et andet brugernavn og en adgangskode.

Serveren behøver ikke beholde nogen udløbne nonce -værdier - den kan simpelthen antage, at eventuelle ukendte værdier er udløbet. Det er også muligt for serveren kun at tillade hver nonce -værdi at blive returneret én gang, selvom dette tvinger klienten til at gentage hver anmodning. Bemærk, at udløb af en server nonce med det samme ikke virker, da klienten aldrig ville få en chance for at bruge den.

.Htdigest -filen

.htdigest er en flad-fil bruges til at gemme brugernavne, rige og adgangskoder til fordøje autentificering af Apache HTTP Server . Filens navn er angivet i .htaccess -konfigurationen og kan være alt, men ".htdigest" er det kanoniske navn. Filnavnet starter med en prik, fordi de fleste Unix-lignende operativsystemer anser enhver fil, der begynder med prik, for at være skjult. Denne fil vedligeholdes ofte med shell -kommandoen "htdigest", som kan tilføje og opdatere brugere og korrekt vil kode kodeordet til brug.

Kommandoen "htdigest" findes i apache2-utils- pakken på dpkg- pakkehåndteringssystemer og httpd-værktøjspakken på RPM-pakkehåndteringssystemer .

Syntaksen for htdigest -kommandoen: 

htdigest [ -c ] passwdfile realm username

Formatet på .htdigest -filen: 

user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379

SIP -fordøjelsesgodkendelse

Session Initiation Protocol (SIP) bruger stort set den samme fordøjelsesgodkendelsesalgoritme. Det er specificeret af RFC 3261.

Browserimplementering

De fleste browsere har i det væsentlige implementeret specifikationen, nogle udelukker visse funktioner såsom autorisationskontrol eller MD5-sess-algoritmen. Hvis serveren kræver, at disse valgfrie funktioner håndteres, kan klienter muligvis ikke godkendes (selvom note mod_auth_digest for Apache heller ikke fuldt ud implementerer RFC 2617).

Afskrivninger

På grund af ulemperne ved Digest -godkendelse sammenlignet med Basic -godkendelse over HTTPS er den blevet forældet af en masse software, f.eks .:

Se også

Noter

Referencer

eksterne links