Autentizační pověření

Autentizace je proces ověřující identitu uživatele. Aby měl operační systém jistotu, že uživatel je opravdu tím kým tvrdí, že je, požaduje po uživateli nějaký důkaz. Pro tento důkaz se v literatuře používá označení uživatelské pověření (user credentials), dále jen pověření. Pověření reprezentuje nějaký typický znak nebo jedinečnou informaci, která je v okamžiku autentizace dostupná všem zúčastněným stranám. Pověření se obvykle dělí do tří tříd. Může to být:

  1. Něco, co známe. Tajemství, které známe a sdílíme ho se systémem, ke kterému chceme získat přístup, představuje nejjednodušší a nejobvyklejší formu pověření. Typickým příkladem je heslo.
  2. Něco, co máme. Druhá třída pověření předpokládá, že uživatel vlastní nějaký autentizační předmět, například čipovou kartu, nějaké USB zařízení nebo RSA SecurID zařizení generující hesla na jedno použití.
  3. Něco, co jsme. Třetí třída pověření zahrnuje širokou škálu biometrických informací jako jsou otisky prstů, oční duhovka, charakteristika hlasu, atd.

Autentizace může být jednofaktorová nebo vícefaktorová, podle toho, kolik různých typů pověření se při ní použije.

Standardně jsou operačním systémem Windows podporovány jen pověření prvních dvou typů.

Ukládání pověření

Pověření použitá uživateli při autentizaci si operační systém musí někam ukládat. Hesla se standardně v otevřeném tvaru nikam neukládají, místo toho se ukládají jejich hash hodnoty. Hash hodnoty hesel k lokálním uživatelským účtům jsou uloženy přímo v počítači, kde byly účty založeny, v tzv. SAM databázi. Doménové účty se nacházejí v aktivním adresáři počítače, který vykonává funkci řadiče domény, a v jednom z atributů doménového účtu je uložena hash hodnota hesla. Pro zvýšení bezpečnosti uložení hash hodnot používají některé systémy tzv. solení hesel, ale Windows k nim bohužel nepatří. To znamená, že dva uživatelé, kteří si náhodou zvolí stejné heslo, budou mít i stejnou hash.

Z důvodů zpětné kompatibility s operačním systémem LAN Manager jsou již od roku 1993 ve Windows řady NT podporovány méně bezpečné LM hashe. LAN Manager povolal maximálně heslo dlouhé 14 znaků a v něm, kromě číslic a dalších povolených znaků jen velké znaky anglické abecedy. Postup při vytváření LM hashe je následující:

  1. všechny znaky hesla se převedou na velké znaky,
  2. heslo se dále doplní nulami na 14 znaků,
  3. těchto 14 znaků se rozdělí na dvě skupiny po sedmi znacích,
  4. každá skupina se použije jako klíč v algoritmu DES k zašifrování konstanty AAD3B435B51404EE,
  5. zřetězením vznikne hash hodnota dlouhá 32 znaků.

Problém je, že pokud by se útočník dostal k těmto hash hodnotám, velmi rychle z nich získá původní hesla. Proto se v praxi generování LM hashe vypíná a používá se jen bezpečnější NT hash, která vzniká jako výstup z algoritmu MD4.

Pokud se uživatel úspěšně přihlásí do systému Windows pomocí doménové účtu, tak se standardně vytvoří lokální kopie hash hodnoty hesla, která mu později umožní se opakovaně přihlásit i v případě, že řadič domény nebude k dispozici. Toto “kešované pověření” je ale uloženo bezpečněji, protože standardní NT hash hodnota se spolu se jménem účtu (toto je jediný případ, kdy Windows použijí solení hesel) znovu zpracuje algoritmem MD4. Windows Vista a vyšší navíc přidávají ještě jeden krok: výsledná hodnota se zpracuje ještě algoritmem PKCS#5.

Přihlášení k lokálnímu účtu

Nejjednodušší varianta autentizace nastává v situaci, kdy se uživatel přihlašuje interaktivně na lokální účet.

  1. Uživatel stiskne kombinaci kláves Ctrl + Alt + Delete, načež část bezpečnostního podsystému Windows nazvaná LSASS (Local Security Authority Sub-System) vytvoří novou relaci a spustí proces WinLogon, který zobrazí přihlašovací dialogové okno.
  2. Uživatel zadá jméno účtu a heslo.
  3. Proces WinLogon z hesla vytvoří NT hash, kterou porovná s hodnotou v SAM databázi. Jsou-li obě hodnoty stejné, je přihlášení úspěšně dokončeno.

Pokud se ovšem hlásíme přes síť k vzdálenému počítači nebo pomocí doménového účtu, situace se komplikuje, protože se musíme strachovat o to, v jakém tvaru putuje autentizační informace po síti. Ve Windows v takovém případě vzniká mnoho různých scénářů, které však mají společné to, že se v nich využívá nějaká varianta protokolu typu výzva – odpověď. Obecné schéma protokolu zachycuje obrázek 1. Uživatel zahájí přihlašování tím, že vznese požadavek na vzdálený server. Server vytvoří tzv. výzvu, což je nějaká náhodná hodnota, kterou pošle klientovi. Klient má k dispozici informaci, kterou uživatel zadal při lokálním příhlášení, a tuto informaci zpracuje spolu s výzvou v kryptografické operaci jejímž výstupem je odpověď serveru.

Obrázek 1: Obecné schéma protokolu typu výzva – odpověď.

NTLM a Kerberos jsou jsou dva standardní protokoly Windows odpovídající výše popsanému schématu.

Protokol NTLM

NTLM označuje rodinu autentizačních protokolů, která byla postupně vylepšována v závislosti na tom, jaké bezpečnostní hrozby se objevovaly. Všechny verze Windows řady NT až do Windows Server 2003, posílaly současně LM odpověď i NT odpověď dle obrázku 2. Žádná domluva o tom, která z variant prokolu se použije neprobíhala. Od verze Windows Server 2003 je standardně zasílána jen NT odpověď, Windows Vista a vyšší upřednostňují bezpečnější variantu protokolu označovanou jako NTLM v2. Starší verze Windows mohou NTLM v2 používat také, ale musí být tak nakonfigurovány, nejedná se tedy o standardní chování. Konfigurovatelná položka registru se v originále nazývá LMCompatibilityLevel, ale administrátor ji typicky nemodifikuje přímo v registru, místo toho používá nástroj Local Security Policy nebo modifikuje GPO objekt v aktivním adresáři. (V češtině se položka nazývá Zabezpečení sítě: Úroveň ověřování pro systém LAN Manager.)

Obrázek 2: Starší verze Windows posílaly současně oba typy odpovědí.

Vylepšení NTLM v2 používá původní NT hash, kterou doplňuje výzva od klienta a v odpovědi se používá algoritmus HMAC-MD5. Odpověď obsahuje také časovou známku, která má zabránit útokům typu opakování zprávy.

Protokol Kerberos

Protokol Kerberos je preferovaným autentizačním protokolem v doméně od verze Windows 2000. Pouze v situaci, kdy nelze použít, přejde se na některou z variant protokolu NTLM. Protože využívá tzv. plně kvalifikovaná doménová jména, nelze ho použít například tehdy, když chce uživatel využívat prostředky vzdáleného počítače identifikovaného jen IP adresou.

Kerberos umožňuje na rozdíl od NTLM vzájemnou autentizaci klienta i serveru. Protokol Kerberos také předpokládá, že síť představuje nepřátelské prostředí ve kterém může útočník odposlouchávat síťový provoz, zachycovat, mazat a modifikovat autentizační zprávy. Aby dosáhl bezpečné autentizace používá Kerberos nejen šifrování dat, ale také časovou synchronizaci. Kerberos ve verzi 5, který je implementován ve Windows, standardně předpokládá, že čas na klientovi a na serveru se neliší o více než pět minut.

Tok požadavků a odpovědí protokolu Kerberos ilustruje obrázek 3:

  1. Po spuštění počítače jsou vytvořena tzv. předautentizační data, obsahující mimo jiné i časovou známku. Předautentizační data jsou zašifrována klíčem odvozeným z hesla a zaslána jako KRB_AS_REQ paket (Kerberos Authentication Service Request) autentizační službě, která se ve Windows označuje jako KDC (Key Distribuiton Center) a běží na řadiči domény.
  2. Autentizační služba vytvoří speciální datovou strukturu označovanou jako TGT lístek (Ticket Granting Ticket). Dále vytvoří klíč relace, který klient použije při komunikaci s další službou běžící na řadiči domény – TGS (Ticket Granting Service, služba poskytující lístky). Tento klíč je klientovi zaslán šifrovaně jako KRB_AS_REP paket.
  3. Klient nyní pošle požadavek službě poskytující lístky s žádostí o přístup ke vzdálenému serveru. Tento požadavek obsahuje TGT lístek, identifikaci služby na serveru a další informace, to vše šifrované klíčem relace.
  4. Služba poskytující lístky odpoví zprávou obsahující lístek pro požadovanou službu, který obsahuje mimo jiné informaci získanou od klienta v předchozím kroku. Celé je to zašifrované veřejným klíčem serveru, takže pro klienta je to nečitelné. Stejná služba vytvoří také relační klíč pro utajenou komunikaci mezi klientem a serverem.
  5. Nakonec klient pošle serveru získaný lístek. Informace od klienta a relační klíč pro jejich vzájemnou komunikaci je zašifrován veřejným klíčem serveru.

Obrázek 3: Tok požadavků a odpovědí při přihlášení do domény a při přístupu na server.

Kerberos je poměrně komplikovaný protokol, ale je velmi robustní a rozšiřitelný. Místo průchozí autentizace, kterou využívá protokol NTLM, je použit systém lístků, což autentizaci zrychluje. Kerberos umožňuje i tzv. tranzitivní důvěru v hierarchické struktuře domén.

Naposledy změněno: úterý, 14. února 2012, 14.18