Ověření přístupu Digest

Ověření přístupu Digest je dohodnutá metoda, kterou může webový server použít k vyjednání přihlašovacích údajů, jako je uživatelské jméno nebo heslo, webového prohlížeče uživatele . Lze jej použít k potvrzení identity uživatele před odesláním citlivých informací, jako je historie bankovních transakcí. Použijte hashovací funkci na uživatelské jméno a heslo před jejich odesláním přes síť. Tento mechanismus je bezpečnější než odesílání prostřednictvím základního ověřování přístupu , které používá kódování Base64 spíše než šifrovací algoritmus, což jej činí nezabezpečeným, pokud není použito ve spojení s Transport Layer Security . Autentizace přístupu Digest používá protokol HTTP a je aplikací kryptografické hašovací funkce MD5 využívající hodnotu nonce k zabránění opakovanému útoku .

Popis

Autentizace přístupu Digest byla původně specifikována v RFC 2069 ( An Extension to HTTP: Digest Access Authentication ). RFC 2069 stručně specifikuje tradiční schéma ověřování, ve kterém je bezpečnost zaručena nonce generovanou serverem. Ověřovací odpověď je vytvořena takto (HA1, HA2, A1, A2 jsou řetězcové proměnné):

{\ displaystyle \ mathrm {HA1} = \ mathrm {MD5} {\ Big (} \ mathrm {A1} {\ Big)} = \ mathrm {MD5} {\ Big (} \ mathrm {uživatelské jméno}: \ mathrm {realm }: \ mathrm {heslo} {\ velké)}}

{\ displaystyle \ mathrm {HA2} = \ mathrm {MD5} {\ Big (} \ mathrm {A2} {\ Big)} = \ mathrm {MD5} {\ Big (} \ mathrm {metoda}: \ mathrm {digestURI } {\ Velký)}}

{\ displaystyle \ mathrm {answer} = \ mathrm {MD5} {\ Big (} \ mathrm {HA1}: \ mathrm {nonce}: \ mathrm {HA2} {\ Big)}}

RFC 2069 byl později nahrazen RFC 2617 ( HTTP Authentication: Basic and Digest Access Authentication ). RFC 2617 zavádí řadu volitelných bezpečnostních vylepšení pro zpracování ověřování; "kvalita ochrany" (qop), čítač nonce inkrementovaný klientem a nonce generovaný náhodně klientem.

Pokud je hashovací algoritmus MD5 nebo není zadán, pak HA1 je:

{\ displaystyle \ mathrm {HA1} = \ mathrm {MD5} {\ Big (} \ mathrm {A1} {\ Big)} = \ mathrm {MD5} {\ Big (} \ mathrm {uživatelské jméno}: \ mathrm {realm }: \ mathrm {heslo} {\ velké)}}

Pokud je hashovací algoritmus „MD5-sess“, pak HA1 je:

{\ displaystyle \ mathrm {HA1} = \ mathrm {MD5} {\ Velký (} \ mathrm {A1} {\ Velký)} = \ mathrm {MD5} {\ Velký (} \ mathrm {MD5} {\ Velký (} \ mathrm {uživatelské jméno}: \ mathrm {realm}: \ mathrm {heslo} {\ Big)}: \ mathrm {nonce}: \ mathrm {cnonce} {\ Big)}}

Pokud je hodnota qop "auth" nebo není specifikována, pak HA2 je:

{\ displaystyle \ mathrm {HA2} = \ mathrm {MD5} {\ Big (} \ mathrm {A2} {\ Big)} = \ mathrm {MD5} {\ Big (} \ mathrm {metoda}: \ mathrm {digestURI } {\ Velký)}}

Pokud je hodnota qop "auth-int", pak HA2 je:

{\ displaystyle \ mathrm {HA2} = \ mathrm {MD5} {\ Big (} \ mathrm {A2} {\ Big)} = \ mathrm {MD5} {\ Big (} \ mathrm {metoda}: \ mathrm {digestURI }: \ mathrm {MD5} (entityBody) {\ Big)}}

Pokud je hodnota qop "auth" nebo "auth-int", pak výpočet odezvy je:

{\ displaystyle \ mathrm {answer} = \ mathrm {MD5} {\ Big (} \ mathrm {HA1}: \ mathrm {nonce}: \ mathrm {nonceCount}: \ mathrm {clientNonce}: \ mathrm {qop}: \ mathrm {HA2} {\ Big)}}

Pokud q nebo p není specifikováno, pak výpočet odpovědi je:

{\ displaystyle \ mathrm {answer} = \ mathrm {MD5} {\ Big (} \ mathrm {HA1}: \ mathrm {nonce}: \ mathrm {HA2} {\ Big)}}

Vliv zabezpečení MD5 na ověřování přístupu pomocí digestu

Výpočty MD5 používané při ověřování HTTP digest se používají " jednosměrně ", je obtížné určit původní vstup se znalostí výstupu. Pokud je však heslo příliš jednoduché, můžete vyzkoušet všechny možné vstupy a najít odpovídající výstup ( útok hrubou silou ) - případně pomocí slovníku nebo duhové tabulky , které jsou k dispozici pro MD5 ^[1] .

Schéma HTTP bylo navrženo Phillipem Hallamem-Bakerem v CERNu v roce 1993 a nezahrnuje následná vylepšení autentizačních systémů, jako je vývoj autentizačního kódu zprávy s klíčovanou hash ( HMAC ). Přestože je použitý kryptografický konstrukt založen na hašovací funkci MD5, v roce 2004 se mělo za to, že hašovací kolize neovlivňují aplikace, kde nebyl znám prostý text (např. heslo) ^[2] . Prohlášení z roku 2006 ^[3] však vyvolala pochybnosti o některých aplikacích MD5. Doposud se však kolizní útoky MD5 neprokázaly jako hrozba pro trávení autentizace a RFC 2617 umožňuje serverům implementovat mechanismy pro detekci určitých kolizí a útoků opakovaného přehrávání .

Aspekty ověřování HTTP digest

Výhody

Http digest autentizace byla navržena tak, aby byla bezpečnější než tradiční autentizační schémata digest, např. „výrazně výkonnější než např . CRAM-MD5 ...“ ( RFC 2617 ).

Některé silné stránky, pokud jde o zabezpečení ověřování HTTP digest, jsou:

Heslo není odesláno na server srozumitelně, což zabraňuje phishingovým útokům , pokud uživatel vstoupí na nesprávnou webovou stránku.
Heslo není použito přímo v přehledu, ale spíše HA1 = MD5 (uživatelské jméno: realm: heslo). To umožňuje některým implementacím (např . JBoss ^[4] ) uložit HA1 místo samotného hesla.
V RFC 2617 byly zavedeny nonce na straně klienta, které umožňují klientovi zabránit vybraným útokům v otevřeném textu , jako jsou duhové tabulky , které by jinak mohly ohrozit schémata ověřování digest.
Nonce na straně serveru mohou obsahovat časová razítka. Server proto může zkontrolovat atributy nonce zaslané klienty, aby se zabránilo útokům opakovaného přehrávání .
Server může také vést seznam nedávno použitých nonces, aby se zabránilo opětovnému použití.

Nevýhody

Autentizace přístupu Digest je bezpečnostní kompromis. Nahrazuje nešifrované HTTP základní ověřování přístupu . Neměl by však nahrazovat robustní ověřovací protokoly, jako je ověřování veřejným klíčem nebo Kerberos .

Pokud jde o zabezpečení, existuje několik nevýhod používání ověřování přístupu digest:

Mnoho možností zabezpečení v RFC 2617 je volitelných. Pokud není kvalita ochrany specifikována serverem, klient bude pracovat v nejméně zabezpečeném režimu, RFC 2069 .
Autentizace přístupu Digest je zranitelná vůči útokům typu man-in-the-middle (MITM) . Útočník MITM může například sdělit klientům, aby použili základní ověřování přístupu nebo režim ověřování přístupu RFC 2069 digest. Navíc autentizace přístupu pomocí digestu neposkytuje klientům mechanismy k ověření identity serveru.
Některé servery vyžadují ukládání hesel pomocí reverzibilního šifrování. Je však možné uložit zpracovanou hodnotu uživatelského jména, realmu a hesla ^[5] .
Zabraňuje použití silnějších hodnot hash hesel (např. bcrypt ) při ukládání hesel (protože heslo nebo zpracované uživatelské jméno, sféra a heslo musí být obnovitelné.

Vzhledem k tomu, že algoritmus MD5 není použitelný ve FIPS , nebude ověřování HTTP digest fungovat s certifikovanými kryptografickými moduly ve FIPS ^[6] .

Alternativní autentizační protokoly

Některé robustní ověřovací protokoly pro webové aplikace:

Autentizace veřejným klíčem pomocí klientského certifikátu (obvykle se používá s HTTPS / SSL klientským certifikátem ).
Autentizace Kerberos nebo SPNEGO , kterou používá například Microsoft IIS pro Integrated Windows Authentication.
Protokol Secure Remote Password (nejlépe používaný ve vrstvě HTTPS / TLS ). I když se nepoužívá v běžných prohlížečích.

Nejběžnějším přístupem je použití autentizačního protokolu založeného na formuláři HTTP + HTML nebo méně běžné základní ověřování přístupu .

Tyto méně robustní protokoly s čistým textem používané ve spojení se síťovým šifrováním HTTPS jsou řešením mnoha hrozeb, pro které byla navržena autentizace přístupu. Toto použití HTTPS však spoléhá na to, že klient ověří adresu URL, ke které přistupuje, aby neodesílal heslo nedůvěryhodnému serveru, což by mohlo vést k phishingovému útoku. Ale uživatel to často nedělá, takže phishing se stal nejčastější bezpečnostní dírou.

Příklad

Následující příklad byl původně navržen v RFC 2617 , zde byl rozšířen o očekávané požadavky a odpovědi . Všimněte si, že se jedná pouze o kvalitu ochranného kódu "auth" (autentizace) - od dubna 2005 pouze Opera a Konqueror podporují "auth-int" (ověření ochrany integrity). Ačkoli se v příkladu zmiňuje HTTP verze 1.1, schéma lze přidat na server pomocí verze 1.0, jak je znázorněno zde.

Tato typická transakce se skládá z následujících kroků:

Klient požádá o stránku, která vyžaduje ověření, ale neposkytne uživatelské jméno a heslo. Obvykle se to stane, protože uživatel zadal adresu nebo sledoval odkaz na stránku.
Server odpoví kódem 401 „Unauthorized“ , který poskytne autentizační sféru a náhodně vygenerovanou jednorázovou hodnotu, tj . nonce .
V tomto okamžiku prohlížeč uživateli představí autentizační sféru (obvykle popis počítače nebo systému, ke kterému se přistupuje) a požaduje uživatelské jméno a heslo. Nyní se uživatel může rozhodnout transakci zrušit.
Jakmile je zadáno uživatelské jméno a heslo, klient vrátí stejný požadavek přidáním ověřovací hlavičky, která obsahuje kód odpovědi.
V tomto příkladu server přijme ověření a odpoví požadovanou stránkou. Pokud jsou poskytnuté přihlašovací údaje neplatné nebo nesprávné, server může odpovědět kódem „401“ a vrátíte se k bodu 3.

Žádost klienta (bez ověření)

 GET  /dir/index.html  HTTP / 1.0 
 Host: localhost

Odpověď ze serveru

HTTP / 1.0  401  Neautorizovaný 
server :  HTTPd / 0.9 
Datum :  Ne, 10. dubna 2014 20:26:47 GMT 
WWW-Authenticate :  Digest realm = "[email protected]", 
                        qop = "auth, auth-int", 
                        nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", 
                        neprůhledný = "5ccc069c403ebaf9f0171e9517f40e41" 
Typ obsahu :  text / html 
Délka obsahu :  153

DOCTYPE html> 
< html > 
  < head > 
    < meta  charset = "UTF-8"  /> 
    < title > Chyba </ title > 
  </ 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 :  Uživatelské jméno Digest = "Mufasa", 
                     realm = "[email protected]", 
                     nonce = "dcd98b7102dd2f0e8b11d0f600bfb0c093", 
                     uri = "/ dir / index.html", 
                     = auth, 
                     nc = 00000001, 
                     cnonce = "0a4f113b", 
                     odpověď = "6629fae49393a05397450978507c4ef1", 
                     neprůhledné = "5ccc069c403ebaf9f0171e9417"f40

(následuje prázdný řádek jako dříve).

Odpověď ze 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 odezvy se vypočítá ve třech krocích (kde jsou hodnoty kombinovány, jsou odděleny dvojtečkami).

Vypočítá se MD5 hash sféry, uživatelského jména a hesla. Výsledkem je HA1.
Vypočítá se MD5 hash metody a digestu Uniform Resource Identifier (například „GET“ a „/dir/index.html“). Výsledkem je HA2.
Vypočítá se MD5 hash HA1, server nonce (nonce), čítač požadavků (nc), klient nonce (cnonce), kvalita ochranného kódu (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ásledujícím způsobem, kde MD5()představuje funkci použitou pro výpočet MD5 hash , zpětná lomítka (\) představují pokračování a uvedené citace nejsou ve výpočtech použity.

Každý krok má v příkladu následující výsledky:

   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 odeslat další požadavek, přičemž znovu použije hodnotu nonce serveru (server dodá novou hodnotu nonce pro každou odpověď 401 ), ale poskytne nový klient nonce (cnonce). hex požadavku (nc) musí být větší než poslední použitá hodnota – jinak by útočník mohl opakovat starý požadavek se stejnými přihlašovacími údaji. Je na serveru, aby se ujistil, že hodnota čítače se zvýší pokaždé, když poskytne novou hodnotu nonce a odmítne nesprávné požadavky. Je zřejmé, že změna metody, URI nebo hodnoty čítače povede k jiné hodnotě odezvy.

Server musí uložit hodnoty nonce, které nedávno vygeneroval. Může si také zapamatovat, kdy dodal hodnoty nonce, což způsobí, že po určité době vyprší. Je-li použita hodnota s vypršenou platností, server by měl odpovědět „401“ a přidat stale=TRUEdo autentizační hlavičky, což znamená, že klient musí provést nový požadavek s novým nonce, aniž by uživatele vyzval k zadání uživatelského jména a hesla.

Server nemusí obsahovat hodnoty nonce – může jednoduše předpokládat, že platnost jakékoli neznámé hodnoty vypršela. Platnost serveru nonce nebude možné okamžitě vypovědět, protože klient nebude moci používat server nonce.

Soubor .htdigest

.htdigest je plochý soubor používaný pro ukládání uživatelských jmen, realmů a hesel pro autentizaci Apache HTTP Server . Název souboru je předán do konfigurace htaccess a lze jej volat pod jinými jmény, ale ".htdigest" je nejběžnější název. Název začíná tečkou, protože většina operačních systémů podobných Unixu považuje jakýkoli soubor, který obsahuje tečku na začátku svého názvu, za skrytý soubor. Tento soubor je aktualizován příkazem "htdigest" shellu, který může přidávat a aktualizovat uživatele a šifrovat hesla pro použití.

Příkaz "htdigest" se nachází v balíčku apache2-utils obsaženém v systémech dpkg a v httpd-tools obsažených v systémech RPM Package Manager .

Syntaxe příkazu htdigest je následující: ^[7]

htdigest [-c] passwdfile realm uživatelské jméno

Formát souboru .htdigest je následující: ^[7]

uživatel1: Oblast: 5ea41921c65387d904834f8403185412
uživatel2: Oblast: 734418f1e487083dc153890208b79379

Ověření SIP digest

Session Initiation Protocol (SIP) používá prakticky stejný algoritmus ověřování digest. Je specifikováno v RFC 3261 .

Podporované prohlížeče

Ověření přístupu Digest implementuje většina prohlížečů, některé implementace obsahují funkce, jako je kontrola auth-int nebo algoritmus MD5-sess. Pokud server vynutí použití těchto volitelných funkcí, připojení některých klientů se nemusí podařit.

Amaya
Gecko založené : (nezahrnujte auth-int ^[8] )
iCab 3.0.3+
Založeno na KHTML - a WebKit : (nezahrnujte auth-int ^[9] )
- iCab 4
- Konqueror
- Google Chrome
- Safari
Na základě Tasmana :
- Internet Explorer Macintosh Edition
Na základě Tridentu :
- Internet Explorer 5+ ^[10] (nezahrnují auth-int)
Na základě Presto :
- Opera
- Opera Mobile
- Opera Mini
- Prohlížeč Nintendo DS
- Prohlížeč Nokia 770
- Prohlížeč Sony Mylo
- Wii internetový prohlížeč kanálů

Poznámky

^ Seznam Rainbow Tables, projekt Rainbowcrack . Obsahuje několik duhových tabulek pro MD5.
^ Hash Collision Q&A , na cryptography.com , Cryptography Research, 16. února 2005 (archivováno z originálu 6. března 2010) .
^ Jongsung Kim, Alex Biryukov, Bart Preneel a Seokhie Hong, O bezpečnosti HMAC a NMAC na základě HAVAL, MD4, MD5, SHA-0 a SHA-1 ( PDF ), na eprint.iacr.org , IACR .
^ Scott Stark, DIGEST Authentication (4.0.4+) , na community.jboss.org , JBoss , 8. října 2005.
^ HTTP Authentication: Basic and Digest Access Authentication: Storing passwords , na tools.ietf.org , IETF , červen 1999.
^ Příloha A: Schválené bezpečnostní funkce pro FIPS PUB 140-2, Bezpečnostní požadavky pro kryptografické moduly ( PDF ), na csrc.nist.gov , Národní institut pro standardy a technologie, 31. ledna 2014.
^ ^a ^b htdigest - správa uživatelských souborů pro ověřování digest na apache.org .
^ Emanuel Corthay, Chyba 168942 – Ověření Digest s ochranou integrity , v Mozille , 16. září 2002. Načteno 16. prosince 2017 (archivováno z originálu 9. června 2011) .
^ Timothy D. Morgan, Integrita HTTP Digest: Jiný pohled ve světle nedávných útoků ( PDF ), na secure.vsecurity.com , vsecurity.com, 5. ledna 2010 (z originálu archivováno 14. července 2014) .
^ TechNet Digest Authentication , na technet.microsoft.com , srpen 2013.

[1] Seznam Rainbow Tables, projekt Rainbowcrack . Obsahuje několik duhových tabulek pro MD5.

[CryptoRes-2004-2] Hash Collision Q&A , na cryptography.com , Cryptography Research, 16. února 2005 (archivováno z originálu 6. března 2010) .

[3] Jongsung Kim, Alex Biryukov, Bart Preneel a Seokhie Hong, O bezpečnosti HMAC a NMAC na základě HAVAL, MD4, MD5, SHA-0 a SHA-1 ( PDF ), na eprint.iacr.org , IACR .

[4] Scott Stark, DIGEST Authentication (4.0.4+) , na community.jboss.org , JBoss , 8. října 2005.

[5] HTTP Authentication: Basic and Digest Access Authentication: Storing passwords , na tools.ietf.org , IETF , červen 1999.

[FIPS_approved_functions-6] Příloha A: Schválené bezpečnostní funkce pro FIPS PUB 140-2, Bezpečnostní požadavky pro kryptografické moduly ( PDF ), na csrc.nist.gov , Národní institut pro standardy a technologie, 31. ledna 2014.

[htdigest-7] tdigest - správa uživatelských souborů pro ověřování digest na apache.org .

[8] Emanuel Corthay, Chyba 168942 – Ověření Digest s ochranou integrity , v Mozille , 16. září 2002. Načteno 16. prosince 2017 (archivováno z originálu 9. června 2011) .

[9] Timothy D. Morgan, Integrita HTTP Digest: Jiný pohled ve světle nedávných útoků ( PDF ), na secure.vsecurity.com , vsecurity.com, 5. ledna 2010 (z originálu archivováno 14. července 2014) .

[10] TechNet Digest Authentication , na technet.microsoft.com , srpen 2013.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]