Autentizace Digest

Ověření přístupu Digest je jednou z běžných metod používaných webovým serverem ke zpracování přihlašovacích údajů uživatele webového prohlížeče . Obdobný způsob se používá v rámci protokolu SIP VoIP pro autentizaci serverem požadavku ze strany klienta, tzn. koncový terminál. Tato metoda posílá hash součet přihlašovacích údajů, hesla, adresy serveru a náhodných dat po síti a poskytuje vyšší úroveň ochrany než základní autentizace , při které jsou data odesílána jako prostý text .

Technicky je autentizace digest použití kryptografické hašovací funkce MD5 na tajemství uživatele pomocí náhodných hodnot, aby byla kryptanalýza obtížná a aby se zabránilo opakovaným útokům . Pracuje na vrstvě protokolu HTTP .

Přehled

Ověřování přístupu Digest bylo původně definováno v RFC 2069 (Rozšíření k HTTP: Ověřování přístupu Digest). RFC 2069 definuje téměř klasické schéma ověřování digest, ve kterém je zabezpečení udržováno prostřednictvím serverem generovaných náhodných hodnot. Odpověď na žádost o ověření je tvořena následovně (kde HA1, HA2, A1, A2 jsou názvy řetězcových proměnných):

RFC 2069 byl později nahrazen RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication). RFC 2617 zavedlo řadu dalších bezpečnostních vylepšení pro ověřování Digest; "kvalita ochrany" (QOP), klientem navýšené počítadlo náhodných hodnot a klientem generované náhodné hodnoty. Tato vylepšení jsou určena k ochraně například před předem vybraným útokem v otevřeném textu .

Pokud je hodnota direktivy QOP "auth" nebo nedefinovaná, pak HA2 je:

Pokud je hodnota direktivy QOP "auth-int", pak HA2 je:

Pokud je hodnota direktivy QOP "auth" nebo "auth-int", pak se odpověď na požadavek vypočítá takto:

Pokud direktiva QOP není definována, pak se odpověď vypočítá takto:

Výše uvedené ukazuje, že když QOP není definována, použije se jednodušší standard RFC 2069 .

Vliv zabezpečení MD5 na autentizaci digest

Výpočty MD5 používané při ověřování HTTP digest musí být „ jednosměrné “, což znamená, že je obtížnější určit počáteční vstup, když je znám pouze výstup. Pokud je však heslo příliš jednoduché, pak je možné iterovat všechny možné vstupy a najít odpovídající výstupy ( útok hrubou silou ) - například pomocí slovníku nebo vhodného vyhledávacího seznamu.

Schéma HTTP bylo vyvinuto v CERNu v roce 1993 a nezahrnuje pozdější vylepšení autentizačních systémů, jako je hash Key Message Authentication Encoding ( HMAC ).

Ačkoli je použitý kryptografický design založen na použití MD5 hashovací funkce, v roce 2004 bylo obecně dohodnuto, že kolizní útoky ( Collision attack ) neovlivňují aplikace, kde není znám prostý text (jako je heslo). [jeden]

V roce 2006 [2] však bylo zpochybněno, zda jiné aplikace MD5 byly tak úspěšné. Nebylo však dosud prokázáno, že by kolizní útoky MD5 představovaly hrozbu pro trávení autentizace a RFC 2617 umožňuje serverům implementovat mechanismy pro detekci určitých kolizních útoků ( Collision attack ) a replay útoků ( Replay attack ).

Charakteristika HTTP Digest Authentication

Výhody

HTTP Digest Authentication je navrženo tak, aby bylo bezpečnější než tradiční schémata Digest Authentication, například je „výrazně bezpečnější než CRAM-MD5 …“ ( RFC 2617 ).

Některé silné stránky ověřování HTTP Digest Authentication:

Nevýhody

Ověření přístupu Digest je kompromisním řešením. Je určen k nahrazení nešifrovaného ověřování HTTP Basic Access Authentication . Není však určen k tomu, aby nahradil bezpečnější ověřovací protokoly, jako je veřejný klíč nebo ověřování Kerberos .

Ověření přístupu Digest má z bezpečnostního hlediska několik nevýhod:

Alternativní autentizační protokoly

Některé silné autentizační protokoly pro webové aplikace :

Slabě zabezpečené protokoly otevřeného typu se často používají v:

Tyto slabé, otevřené protokoly, používané ve spojení se síťovým šifrováním HTTPS, zabraňují mnoha hrozbám, proti kterým je ověřování navrženo.

Příklad s vysvětlením

Následující příklad byl původně uveden v RFC 2617 a zde byl rozšířen tak, aby zobrazoval úplný text očekávaný pro každý požadavek a odpověď. Upozorňujeme, že je zahrnuta pouze kvalita zabezpečení ověřovacího kódu - v době psaní tohoto článku podporovaly "AUTH-INT" (autentizace s integritou zabezpečení) pouze prohlížeče Opera a Konqueror . Ačkoli specifikace uvádí HTTP verze 1.1, schéma lze úspěšně přidat na server verze 1.0, jak je znázorněno zde.

Toto typické schéma zasílání zpráv se skládá z následujících kroků.

Poznámka: Klient již může obsahovat uživatelské jméno a heslo, aniž by se uživatel musel dotázat, například pokud byly dříve uloženy webovým prohlížečem.

Požadavek klienta (žádné ověření) GET /dir/index.html HTTP / 1.0 Host : localhost Odezva serveru HTTP / 1.0 401 Neautorizovaný server : HTTPd/0.9 Datum : Ne, 10. dubna 2005 20:26:47 GMT WWW-Authenticate : Digest realm="[email protected]", qop="auth,auth-int", nonce= "dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Typ obsahu : text/html Délka obsahu : 311 PUBLIKACE: 311 PUBLIKACE W1C9/EN.0org HTML1 Převod W1C9 /EN /ORG html401-19991224/loose.dtd"> < HTML > < HEAD > < TITLE > Chyba </ TITLE > < META HTTP-EQUIV = "Content-Type" CONTENT = "text/html; znaková sada =ISO-8859-1" > </ HEAD > < BODY >< H1 > 401 Neoprávněné. </ H1 ></ BODY > </ HTML > Žádost klienta (uživatelské jméno "Mufasa", heslo "Circle Of Life") GET /dir/index.html HTTP / 1.0 Host : localhost Autorizace : Digest username="Mufasa", realm="[email protected]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/qopindex.html", . =auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" Odezva serveru HTTP / 1.0 200 OK Server : HTTPd/0.9 Datum : Ne, 10. dubna 2005 20:27:03 GMT Typ obsahu : text/html Délka obsahu : 7984

Hodnota odpovědi se vypočítá ve třech krocích následovně. Pokud jsou hodnoty kombinovány, jsou odděleny dvojtečkou.

  1. Vypočítá se kombinovaný MD5 hash uživatelského jména, autentizační sféry a hesla. Výsledkem je HA1.
  2. Vypočítá se hash MD5 kombinované metody a výtah URI , jako například "GET"a "/dir/index.html". Výsledek se nazývá HA2.
  3. Vypočítá se MD5 hash kombinovaného výsledku HA1, náhodné hodnoty serveru, čítače požadavků, náhodné hodnoty klienta, kódu kvality ochrany (QOP) a HA2. Výsledkem je hodnota „odpovědi“ poskytnutá klientem.

Protože server má stejné informace jako klient, lze odpověď ověřit provedením stejných výpočtů. Ve výše uvedeném příkladu je výsledek vytvořen následovně, kde MD5()je funkce použitá k výpočtu hashe MD5, zpětná lomítka představují pokračování a ve výpočtech nejsou použity uvozovky.

Abychom dokončili příklad uvedený v RFC 2617 , ukažme si výsledky pro každý krok.

HA1 = MD5( "Mufasa:[email protected]:Circle Of Life" ) = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5( "GET:/dir/index.html" ) = 39aff3a2bab6126f332b942af96d3366 Odpověď = MD5( "939e7578ed9e3c518a452acee763bce9:\ dcd98b7102dd2f0e8b11d0f600bfb0c093:\ 00000001:0a4f113b:auth:\ 39aff3a2bab6126f332b942af96d3366" ) = 6629fae49393a05397450978507c4ef1

V tomto okamžiku může klient vytvořit nový požadavek, znovu použít náhodnou hodnotu serveru (server vydá novou náhodnou hodnotu pro každou odpověď "401"), ale poskytne klientovi novou náhodnou hodnotu. Pro následné požadavky musí být hodnota počítadla hexadecimálních požadavků větší než dříve použitá hodnota - jinak může útočník jednoduše " zopakovat " starý požadavek se stejnými daty. Úkolem serveru je zajistit, aby se čítač zvýšil pro každou vrácenou náhodnou hodnotu, a ignorovat všechny neodpovídající požadavky. Je zřejmé, že změna metody, URI a/nebo hodnoty čítače může vést k různým hodnotám odezvy.

Server si musí pamatovat náhodné hodnoty, které byly nedávno vygenerovány. Může si také pamatovat, kdy byla vydána každá náhodná hodnota, a po určité době je vyřadit. Je-li použita zastaralá hodnota, MUSÍ server předat stavový kód "401" a přidat stale=TRUEjej do autentizační hlavičky indikující, že klient by měl znovu odeslat požadavek s novou náhodnou hodnotou, aniž by uživatele nutil odeslat jiné uživatelské jméno a heslo.

Server nemusí ukládat všechny zastaralé náhodné hodnoty – může jednoduše předpokládat, že jakékoli nevhodné hodnoty jsou zastaralé. Je také možné, aby server vrátil každou náhodnou hodnotu pouze jednou, ačkoli to nutí klienta opakovat každý požadavek. Všimněte si, že platnost náhodné hodnoty serveru nemůže vypršet okamžitě, protože klient by ji nikdy neměl šanci použít.

SIP Digest Authentication

Protokol SIP , který zdědil ideologii a schopnosti HTTP, používá v podstatě stejný autentizační algoritmus digest. Je definován v RFC 3261 v kapitole "22.4 Schéma ověřování Digest".

Implementace prohlížeče

Většina prohlížečů implementuje základní specifikace, s výjimkou některých specifických funkcí, jako je kontrola AUTH-INT nebo algoritmus relace MD5. Pokud server vyžaduje zpracování těchto dodatečných funkcí, klienti nemusí být schopni se ověřit (ačkoli je třeba poznamenat, že mod_auth_digest Apache také plně neimplementuje RFC 2617 ).

Viz také

Poznámky

  1. ↑ Otázky a odpovědi o hash Collision . Kryptografický výzkum (datum nezjištěno). Datum přístupu: 2. července 2010. Archivováno z originálu 1. září 2004. POZNÁMKA: Specifické informace nejsou uvedeny; potřebuje citaci z přesné verze této původně citované stránky.
  2. ↑ Kim, Biryukov2, Preneel, Hong, „O bezpečnosti HMAC a NMAC na základě HAVAL MD4 MD5 SHA-0 a SHA-1“ Archivováno 12. května 2013 na Wayback Machine
  3. ↑ RFC 2617 – HTTP Authentication: Základní a Digest Access Authentication . Datum přístupu: 18. prosince 2011. Archivováno z originálu 4. července 2010.
  4. ↑ mod_auth_digest - Apache HTTP Server . Získáno 18. prosince 2011. Archivováno z originálu 11. listopadu 2012.

Odkazy

 http
Obecné pojmy
Metody
Tituly
Stavové kódy