autentificare de acces Digest

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Digest autentificare de acces este o metodă de acord că un server de web se poate utiliza pentru a negocia acreditările, cum ar fi numele de utilizator sau parola, de web al utilizatorului browser - ul . Acesta poate fi folosit pentru a confirma identitatea unui utilizator înainte de a trimite informații sensibile, cum ar fi istoricul tranzacțiilor bancare. Se aplică o funcție hash pentru numele de utilizator și parola înainte de a le trimite prin rețea. Acest mecanism este mai sigur decât trimiterea prin autentificarea de acces de bază , care utilizează Base64 codifică mai degrabă decât folosind un algoritm de criptare, pe care îl face nesigur , cu excepția cazului utilizat în conjuncție cu Transport Layer Security . Digest autentificare de acces utilizează HTTP protocol și este o aplicație a MD5 hash criptografic funcția folosind o nOdată valoare pentru a preveni un atac de reluare .

Descriere

Autentificarea de acces Digest a fost specificat inițial în RFC 2069 (o extensie a HTTP: Digest Access autentificare). RFC 2069 pe scurt specifică o schemă de autentificare tradițională în care securitatea este garantată de un nDupă generat de server. Răspunsul de autentificare este format ca aceasta (HA1, HA2, A1, A2 sunt variabile string):

RFC 2069 a fost ulterior înlocuit cu RFC 2617 (HTTP autentificare: de bază și Digest Access autentificare). RFC 2617 introduce o serie de îmbunătățiri de securitate opționale pentru a digera autentificare; „calitatea de protecție“ (qop), nonce contor incrementat de către client și un nonce generat aleator de către client.

Dacă algoritmul hash este MD5 sau nu este specificată, atunci HA1 este:

Dacă algoritmul hash este „MD5-sess“, atunci HA1 este:

În cazul în care valoarea qop este „AUT“ sau nu este specificat, atunci HA2 este:

În cazul în care valoarea qop este "auth-int", atunci HA2 este:

În cazul în care valoarea qop este „autorizare“ sau „auth-int“, atunci calculul de răspuns este:

În cazul în care nu este specificat q sau p, atunci calculul răspunsului este:

Impactul securității MD5 privind autentificarea de acces Digest

Cele MD5 calculele utilizate în HTTP digest autentificare sunt utilizate „ într - un fel “, este dificil de a determina intrarea originală cunoașterea de ieșire. Cu toate acestea, în cazul în care parola este prea simplu, puteți încerca toate intrările posibile și de a găsi o ieșire de potrivire (un atac brute-force ) - eventual cu ajutorul unui dicționar sau a unui tabel de curcubeu , care sunt disponibile pentru MD5 [1] .

Schema HTTP a fost conceput de Phillip Hallam-Baker la CERN în 1993 și nu include îmbunătățiri ulterioare în sistemele de autentificare, cum ar fi dezvoltarea keyed-hash cod de autentificare mesaj ( HMAC ). Deși construcția criptografică utilizată se bazează pe funcția hash MD5, în 2004 , se credea că ciocnirile hash nu a afectat în cazul în care aplicațiile plaintext ( de exemplu , parola) nu a fost cunoscut [2] . Cu toate acestea, cererile în 2006 [3] au cauzat îndoieli pentru unele aplicații ale MD5. Până în prezent, cu toate acestea, atacurile de coliziune MD5 nu au dovedit a fi o amenințare pentru a digera autentificare și RFC 2617 permite serverelor să pună în aplicare mecanisme care vizează detectarea unor coliziuni și atacurile de reluare .

HTTP digera considerente de autentificare

Beneficii

Http digest de autentificare a fost proiectat pentru a fi mai sigur decât tradiționale digera scheme de autentificare, de exemplu , „semnificativ mai puternic decât de exemplu CRAM-MD5 ...“ ( RFC 2617 ).

Unele puncte forte în ceea ce privește HTTP digest de securitate de autentificare sunt:

  • Parola nu este trimisă la server în clar, prevenind phishing atacuri în cazul în care utilizatorul accesează un site greșit.
  • Parola nu este utilizat în mod direct în digest, ci mai degrabă HA1 = MD5 (nume de utilizator: tărâm: parola). Acest lucru permite unele implementări ( de exemplu , JBoss [4] ) pentru a stoca HA1 în locul parolei în sine.
  • Nonces client-side au fost introduse în RFC 2617 , care permite clientului pentru a preveni atacurile de necriptate alese , cum ar fi tabele de curcubeu , care altfel ar putea amenința digera scheme de autentificare.
  • nonces server-side pot conține marcaje de timp. Prin urmare , serverul poate inspecta atributele nonce trimise de clienti, pentru a preveni atacurile de reluare .
  • Serverul poate păstra, de asemenea, o listă de nonces utilizat recent pentru a împiedica reutilizarea.

Dezavantaje

Digest autentificare de acces este un compromis de securitate. Acesta înlocuiește necriptat HTTP autentificare de acces de bază . Cu toate acestea, nu ar trebui să înlocuiască protocoalele de autentificare robuste, cum ar fi cheia publică autentificarea sau Kerberos .

În ceea ce privește securitatea, există mai multe dezavantaje la utilizarea de autentificare de acces Digest:

  • Multe dintre opțiunile de securitate în RFC 2617 sunt opționale. În cazul în care calitatea-de-protecție nu este specificată de către server, clientul va funcționa în modul cel mai puțin sigure, RFC 2069 .
  • Digest autentificare de acces este vulnerabil la (MITM) atacurilor man-in-the-middle . De exemplu, un atacator poate spune MITM clienților să utilizeze autentificarea de acces de bază sau RFC 2069 modul de autentificare de acces Digest. Mai mult decât atât, digest autentificare de acces nu prevede mecanisme pentru clienții pentru a verifica identitatea serverului.
  • Unele servere necesită parole pentru a fi stocate folosind criptare reversibila. Cu toate acestea, este posibil pentru a stoca valoarea digerată a numelui de utilizator, parola și domeniul [5] .
  • Împiedică utilizarea parolele HASH mai puternice ( de exemplu , bcrypt ) în stocarea parolelor (ca parola sau numele de utilizator digerate, domeniul și parola trebuie să fie recuperate.

De asemenea, din moment ce MD5 algoritmul nu este utilizabil în FIPS , HTTP digest de autentificare nu va lucra cu module criptografice certificate în FIPS [6] .

Protocoale de autentificare alternative

Unele protocoale de autentificare robuste pentru aplicații bazate pe web:

Abordarea cea mai comună este de a protocolului de utilizare [10] sau mai puțin frecvente autentificare de acces de bază .

Aceste protocoale clartext mai puțin robuste folosite în combinație cu criptare a rețelei HTTPS sunt o soluție pentru multe amenințări că autentificarea de acces Digest a fost proiectat pentru. Cu toate acestea, această utilizare a HTTPS se bazează pe client pentru a valida URL-ul îl accesează pentru a nu trimite parola de la un server nu este de încredere, care ar putea duce la un atac de phishing. Dar utilizatorul de multe ori nu, asa phishing a devenit cea mai comună gaura de securitate.

Exemplu

Exemplul următor a fost propusă inițial în RFC 2617 , aici a fost extins pentru a arăta așteptate solicitări și răspunsuri . Rețineți că aceasta este doar calitatea codului de protecție „autorizare“ (autentificare) - din aprilie 2005, doar Opera si Konqueror suport „auth-int“ (autentificare de protecție de integritate). Deși exemplul menționează versiunea HTTP 1.1, schema poate fi adăugat la un server folosind versiunea 1.0, așa cum se arată aici.

Această tranzacție tipică constă din următoarele etape:

  1. Clientul solicită o pagină care necesită autentificare, dar nu oferă un nume de utilizator și o parolă. De obicei se întâmplă, deoarece utilizatorul a introdus adresa sau a urmat un link către pagina.
  2. La server cu Reacția produsă 401 „neautorizat“ , cod, oferind un domeniu de autentificare și un generat aleator valoare de o singură dată, și anume nonce .
  3. În acest moment, prezintă browser-tărâmul de autentificare (de obicei, o descriere a calculatorului sau a sistemului de accesare) pentru utilizator și solicită un nume de utilizator și o parolă. Acum, utilizatorul poate decide să anuleze tranzacția.
  4. Odată ce sunt furnizate numele de utilizator și parola, clientul returnează aceeași cerere prin adăugarea antetul de autentificare care include codul de răspuns.
  5. În acest exemplu, serverul acceptă autentificare și răspunde cu pagina solicitată. În cazul în care acreditările furnizate sunt incorecte sau greșite, serverul poate răspunde cu codul „401“ și se va întoarce la punctul 3.

Cererea de clienți (fără autentificare)
 GET /dir/index.html HTTP / 1.0
 Realizator: localhost
Răspunsul de la server
 HTTP / 1.0 401 neautorizat
Server: HTTPd / 0,9
Data: dum zece/04/2014 20:26:47 GMT
WWW-autentificaþi: Digest tărâm = "[email protected]",
                        qop = "auth, auth-int",
                        Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opac = "5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text / html
Conținut-Lungime: 153

<! DOCTYPE html>
< html >
  < cap >
    < meta charset = "UTF-8" />
    <Title> Eroare </ title>
  </ head >
  < corp >
    <H1> 401 neautorizat. </ H1>
  </ body >
</ html >
Cererea de clienți (nume de utilizator "Mufasa", parola "Circle Of Life")
 GET /dir/index.html HTTP / 1.0
Realizator: localhost
Autorizare: Nume de utilizator Digest = "Mufasa",
                     tărâm = "[email protected]",
                     Nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri = "/ dir / index.html",
                     qop = auth,
                     nc = 00000001,
                     cnonce = "0a4f113b",
                     răspuns = "6629fae49393a05397450978507c4ef1",
                     opac = "5ccc069c403ebaf9f0171e9517f40e41"

(Urmat de o linie goală, ca mai înainte).

Răspunsul de la server
 HTTP / 1.0 200 OK
Server: HTTPd / 0,9
Data: dum 2005-4-zece 20:27:03 GMT
Content-Type: text / html
Conținut-Lungime: 7984

Valoarea de răspuns se calculează în trei etape (în cazul în care valorile sunt combinate, acestea sunt delimitate de două puncte).

  1. MD5 hash a Realm, numele de utilizator și parola se calculează. Rezultatul este HA1.
  2. MD5 hash a metodei și digest Uniform Resource Identifier este calculat (de exemplu , "GET" și "/dir/index.html"). Rezultatul este HA2.
  3. Hash MD5 HA1, nOdată serverul (nOdată), cererea contor (nc), nOdată client (cnonce), calitatea codului de protecție (qop) și HA2 se calculează. Rezultatul este valoarea de răspuns furnizat de client.

Deoarece serverul are aceleași informații ca și client, răspunsul poate fi verificată prin efectuarea acelorași calcule. In exemplul de mai sus rezultatul se formează în felul următor, în cazul în care MD5() reprezintă o funcție utilizată pentru calcularea MD5 hash a backslash (\) reprezintă o continuare și citatele prezentate nu sunt utilizate în calcule.

Fiecare pas are următoarele rezultate în exemplul:

 HA1 = MD5 ( "Mufasa: [email protected]: Cercul Vieții")
       = 939e7578ed9e3c518a452acee763bce9

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

   Răspuns = MD5 ( "939e7578ed9e3c518a452acee763bce9: \
                    dcd98b7102dd2f0e8b11d0f600bfb0c093: \
                    00000001: 0a4f113b: auth: \
                    39aff3a2bab6126f332b942af96d3366 „)
            = 6629fae49393a05397450978507c4ef1

În acest moment, clientul poate trimite o altă cerere prin reutilizarea valoarea nDupă a serverului (serverul ofera un nou nOdată pentru fiecare răspuns 401 ), oferind , de asemenea , un nou client nOdată (cnonce) .Pentru cereri ulterioare, valoarea contor cerere hexazecimal ( nc) trebuie să fie mai mare decât ultima valoare folosită - în caz contrar un atacator ar putea repeta o cerere de vechi , cu aceleași acreditări. Depinde de la server pentru a vă asigura că valoarea contorului gradat de fiecare dată oferă o nouă valoare nonce, respingând cererile greșite. Evident schimbarea metodei, URI sau valoarea contorului va avea ca rezultat o valoare de răspuns diferit.

Serverul trebuie să stocheze valorile nOdată care le-a generat recent. Se poate, de asemenea, să memoreze atunci când le-a furnizat valori nOdată, determinându-l să expire după o perioadă de timp. Dacă se utilizează o valoare expirată, serverul ar trebui să răspundă cu „401“ și se adaugă stale=TRUE antetul de autentificare, indicând faptul că clientul trebuie să facă o nouă cerere cu noul nonce, fără a solicita confirmarea utilizatorului pentru numele de utilizator și parola.

Serverul nu are la valori nOdată hold - se poate presupune pur și simplu că orice valoare necunoscută a expirat. Nu va fi posibil să expire imediat serverul nDupă, deoarece clientul nu ar putea folosi nonce.

.Htdigest Fișierul

.htdigest este un fișier plat utilizat pentru stocarea nume de utilizator, tărâmuri și parole pentru autentificare Digest a Apache HTTP Server . Numele fișierului este trecut în configurația [11] , și poate fi numit de către alte nume, dar „.htdigest“ este numele cel mai frecvent. Numele începe cu o perioadă, deoarece cele mai multe Unix de operare sisteme de a trata orice fișier care conține o perioadă de la începutul numelui său ca un fișier ascuns. Acest fișier este actualizat cu shell - ului „htdigest“ comandă care poate adăuga și actualizarea conturilor de utilizatori și parole de criptare pentru utilizare.

Comanda „htdigest“ se găsește în pachetul apache2-utils conținute în dpkg sistemele și în Httpd-tools conținute în RPM Package Manager sisteme.

Sintaxa comenzii htdigest este după cum urmează: [12]

 htdigest [-c] passwdfile username domeniu

Formatul fișierului .htdigest este după cum urmează: [12]

 user1: Realm: 5ea41921c65387d904834f8403185412
utilizator2: Realm: 734418f1e487083dc153890208b79379

Autentificare SIP Digest

Session Initiation Protocol (SIP) utilizează practic același digest algoritmul de autentificare. Este specificat în RFC 3261 .

browsere acceptate

Autentificarea de acces Digest este implementat de cele mai multe browsere, unele implementări conțin caracteristici, cum ar fi verificarea auth-int sau algoritmul MD5-sess. Dacă serverul forțează utilizarea acestor caracteristici opționale, unii clienți poate să nu reușească să se conecteze.

Notă

  1. ^ Lista tabelelor Rainbow, Proiectul rainbowcrack . Include mai multe tabele de curcubeu pentru MD5.
  2. ^ Hash coliziune Q & A , la cryptography.com, en: Criptografie Research , 16 februarie 2005 (arhivate de original pe 06 martie 2010).
  3. ^ Jongsung Kim, Alex Biryukov, Bart Preneel și Seokhie Hong, privind securitatea HMAC și NMAC Bazat pe Haval, MD4, MD5, SHA-0 și SHA-1 (PDF), pe eprint.iacr.org, IACR .
  4. ^ Scott Stark, DIGEST Authentication (4.0.4+) , la community.jboss.org, JBoss 8 October, 2005.
  5. ^ Autentificare HTTP: Basic și Digest Access autentificare: parolele Salvarea , pe tools.ietf.org, IETF , iunie 1999.
  6. ^ Anexa A: Funcții de securitate aprobate pentru FIPS PUB 140-2, Cerințe de securitate pentru criptografic Module (PDF), pe csrc.nist.gov, Institutul Național de Standarde și Tehnologie, 31 ianuarie 2014.
  7. ^ En: SPNEGO
  8. ^ Ro: Autentificarea integrată Windows
  9. ^ Ro: protocol securizat parolă la distanță
  10. ^ En: HTTP + HTML autentificare bazată pe formular
  11. ^ En: .htaccess
  12. ^ A b htdigest - gestiona fișierele de utilizator pentru autentificare Digest , în apache.org.
  13. ^ Emanuel Corthay, Bug 168942 - autentificarea Digest cu protecție integritate , în Mozilla , 16 septembrie 2002. Adus de 16 decembrie 2017 (arhivate de original pe 09 iunie 2011).
  14. ^ Timothy D. Morgan, HTTP Digest Integritate: Un alt aspect, în lumina atacurilor recente (PDF), la secure.vsecurity.com, vsecurity.com, 05 ianuarie 2010 (arhivate de original pe 14 iulie 2014).
  15. ^ TechNet Digest autentificare , pe technet.microsoft.com, august 2013.
  16. ^ Nintendo DS Browser
  17. ^ Sony Mylo
  18. ^ Browser Wii Canal internet
Securitate IT Portal de securitate cibernetică : Accesați intrările Wikipedia care se ocupă de securitatea cibernetică