Autentizace je proces, při kterém se ověřuje, zda je uživatel nebo entita opravdu ten, za koho se vydává.
[20] rozděluje autentizaci principielně na dva typy, uživatelskou a entitní. K uživatelské autentizaci dochází ve webových aplikacích obvykle při přihlašování zadáním uživatelského jména a hesla. Poté server zašle klientovi session token, což je nejčastěji náhodně vygenerovaný identifikátor aktuální session. Ten si prohlížeč obvykle uchovává v podobě cookie ve své paměti. Společně s každým dalším požadavkem pak prohlížeč zasílá i tento session token, čímž je prováděna autentizace entitní. Ta úzce souvisí se správou aktuální session a bude o ní řeč v příští kapitole.
[12] uvádí tři možné způsoby, jak je možné provádět úvodní uživatelskou autentizaci. Při každé autentizaci se vždy jeden nebo více z nich používá:
Drtivá většina webových aplikací implementuje pro svou jednoduchost a relativně dostačující bezpečnost první přístup, tedy autentizaci zadáním uživatelského jména a hesla. Tu budeme předpokládat i v následujícím textu. Ostatní dvě metody se používají zejména v systémech náročných na bezpečnost, a to ještě v různých vzájemných kombinacích. V principu se ale stále jedná o totéž. Ať už zadáním hesla, protažením identifikační karty či sejmutím otisku prstu poskytuje uživatel počítači nějakou informaci, která je typická jen pro něj a kterou je pro kohokoliv jiného nesnadné napodobit.
Webová aplikace má obecně dvě hlavní možnosti, jak provádět přihlášení uživatele přes uživatelské jméno a heslo. První je využití možností protokolu HTTP [10]. S pomocí odezvy 401 Unauthorized a následné hlavičky WWW-Authenticate sdělí server klientovi, že má od uživatele získat přihlašovací údaje. Ty si pak prohlížeč pamatuje a automaticky je zasílá s každým dalším požadavkem. Server pak jejich platnost ověřuje buď přímo v aplikaci [17], nebo dokonce ještě na úrovni webového serveru. Například u Apache toto zajišťují moduly mod_auth, mod_auth_db a mod_auth_dbm.
HTTP autentizace má několik nevýhod. Práce s ní je obecně méně pohodlná než s autentizací formulářovou. Uživatelské jméno a heslo při ní putuje sítí znovu a znovu s každým dalším požadavkem (což ale lze zabezpečit šifrovaným přenosem či použitím HTTP Digest autentizace [11]). Zásadním problémem však zůstává nemožnost jakýmkoliv spolehlivým způsobem donutit klientský prohlížeč k „odhlášení“, to znamená aby zadané údaje zapomněl a přestal je posílat.
Druhou a mnohem častěji používanou možností je tak formulářová autentizace. Aplikace v případě potřeby sama zašle klientovi stránku s klasickým přihlašovacím HTML formulářem. Po jeho odeslání data ověří a provedené úspěšné přihlášení spojí s aktuální session. Nadále tak klient s požadavky zasílá jen session token, ne však už login a heslo. Server má navíc možnost kdykoliv, například při timeoutu, uživatele odhlásit – buď zruší propojení provedeného přihlášení a session, anebo zruší celou session.
Při formulářové autentizaci doporučuje [20] pro zadání hesla jednoznačně používat vstupní pole typu password. Prohlížeče text do něj psaný nezobrazují, a tak jej nelze prostým způsobem odpozorovat. Navíc není toto pole nikdy automaticky předvyplňováno na základě předchozích vstupů, jak činí novější prohlížeče u běžných textových polí. Vstupní pole pro heslo by v žádném případě nemělo být předvyplněno ani ze strany aplikace pomocí atributu value.
Přihlašovací formulář by měl být odesílán výhradně HTTP metodou POST. Podoba GET požadavku se totiž včetně všech odesílaných parametrů ukládá do historie prohlížeče i do případných logů po cestě, a tudíž je snadno odcizitelná. Komunikace mezi klientem a serverem by měla být zabezpečená, přinejmenším alespoň právě během uživatelské autentizace, kdy sítí putuje uživatelské jméno a heslo. K tomuto účelu slouží například protokoly SSL a TLS. Alternativní možností je použití metody challenge/response.
Challenge/response [22] umožňuje autentizaci i přes nechráněný komunikační kanál bez jakékoliv nutnosti přenášet samotné heslo. Využívá se při tom skriptování na straně prohlížeče. Společně s přihlašovací stránkou zašle aplikace klientovi i náhodně vygenerovaný řetězec. Po zadání loginu a hesla uživatelem se tyto údaje hned neodesílají serveru. Skript v prohlížeči zřetězí zadané heslo s obdrženým náhodným řetězcem, celé to prožene jednocestnou hashovací funkcí (například MD5) a teprve takto získaný výsledný řetězec zašle místo hesla zpět. Server, který zná uživatelovo heslo a zároveň si pamatuje vygenerovaný náhodný řetězec, je schopen provést stejný postup. Porovnáním svého výsledného řetězce s řetězcem získaným od klienta ověří, zda bylo heslo zadáno správně.
Aplikace příslušným způsobem uchovává, eviduje a spravuje přihlašovací, osobní i jiné údaje registrovaných uživatelů. Zejména registrační údaje, jako jsou uživatelská jména a hesla, by měla být na serveru uložena na bezpečném místě, typicky v databázi s omezeným přístupem. Hesla navíc není vhodné ukládat v čisté podobě, ale upravená některou jednocestnou hashovací funkcí, například SHA nebo MD5 [13]. Nebudou tak čitelná pro administrátora, ale ani pro případného narušitele, který by se nějakým způsobem k databázi hesel dostal. Jeho jedinou možností, jak původní podobu hesla odhalit, pak zůstává útok hrubou silou, tzn. zkoušet stejnou jednocestnou funkcí šifrovat jedno potenciální heslo za druhým a porovnávat je s uloženými záznamy. Proto by měla být zvolená hashovací funkce dostatečně silná, aby byl takový postup v přiměřeném čase výpočetně nedosažitelný.
Hesla volená uživateli musí být nesnadno odhadnutelná. Rozhodně by neměla být tvořena normálními slovy běžně používanými v některém jazyce, a už vůbec ne výrazy úzce spojenými s daným uživatelem, jako jméno manželky, rodné číslo, poštovní adresa či snad dokonce heslem shodným s přihlašovacím jménem. Tradičně se doporučuje vymyslet alespoň osmiznakové heslo, v němž budou zkombinovány číslice, verzálky, mínusky a nealfanumerické znaky. Zdánlivě protichůdnou podmínkou je, aby se samotnému uživateli dobře pamatovalo. Toho lze ale snadno docílit třeba určením hesla jako akronymu z nějaké pro uživatele snadno zapamatovatelné věty. Pokročilejší systémy implementují algoritmy, které požadovanou složitost a neodhadnutelnost nastavovaného hesla kontrolují. Myslí při tom třeba i na takové věci, jako symetrická kombinace kláves na klávesnici apod.
Pro případ, že uživatel své heslo zapomene, poskytují aplikace často nějakou funkci automatického obnovení přístupu k účtu, aniž by bylo nutné osobně kontaktovat administrátora. Je nutné si uvědomit, že taková možnost představuje bezpečnostní riziko, protože se tak účet zpřístupňuje uživateli, který není schopen se dostatečně autentifikovat. První možností je zodpovězení kontrolní otázky, kterou si uživatel nastavil při registraci. Toto je silně nedoporučovaný přístup, neboť většina běžně používaných kontrolních otázek má nějakou přímou souvislost s daným uživatelem (rodné jméno manželky, číslo řidičského průkazu apod.), kterou si snadno odvodí i případný narušitel.
O něco lepší je zasílání přístupových údajů e-mailem na adresu, kterou uživatel určil při původní registraci. Ale i zde existují značná bezpečnostní rizika. Největším je, že e-mail putuje po síti v otevřené nešifrované podobě a je tedy po cestě čitelný pro kohokoliv. Pokud aplikace tento způsob obnovy přístupu podporuje, měla by zasílat náhodně vygenerované jednorázové heslo. To by mělo mít omezenou dobu platnosti v řádu několika málo hodin. Po jeho prvním použití by měl být uživatel ihned vyzván ke změně hesla na jinou hodnotu.
Všem heslům v aplikaci je obecně dobré nastavit určitou omezenou životnost. Systém pak například každé dva měsíce vyzve uživatele, aby si své aktuální heslo změnil. Po každé editaci registračních údajů by měla aplikace zasílat uživateli na jeho adresu notifikační e-mail o provedených změnách.
Pokročilejší vlastností některých aplikací při autentizaci je zamykání účtů. Když se útočník bude pokoušet přihlásit na jeden účet a několikrát po sobě zadá chybné heslo, účet se zamkne. Opětovné odemčení účtu pak může provést jen administrátor, anebo k němu dojde automaticky, ale až po určité časové prodlevě. Mechanizmus uzamykání chrání uživatelské účty před útokem hrubou silou. Povolený počet pokusů se pohybuje zpravidla mezi 5 až 10, doba uzamčení účtu pak v řádech desítek minut až několika hodin.
Je zřejmé, že autentizace a správa uživatelů je závislá na každé konkrétní aplikaci či alespoň frameworku. Existují ale i některá zobecnění. V oblasti jazyka PHP obsahuje například knihovna PEAR standardní obecnou třídu Auth a pro autentizaci založenou na HTTP dokonce zvláštní třídu Auth_HTTP.
Obsah stránek vyjadřuje osobní názory, postoje a zkušenosti autora. Copyright © 2004–2010 Jan Tichý.