Autentizace: politika účtů a hesel

Je možné nechat odpovědnost za kvalitu hesla zcela na uživateli nebo by to měl být systém, který by měl použití silného hesla vynucovat?

Jsme přesvědčeni, že na uživatele se nelze zcela spolehnout a že by systém sám měl kontrolovat, zda zadávané heslo obsahuje velká a malá písmena, čísla, speciální znaky a neobsahuje slova uvedená ve slovníku. Dále by měl systém kontrolovat, jakou má heslo délku, zda již nebylo uživatelem jednou použito nebo zda není jen drobnou obměnou hesla předchozího. Stejně tak by měla být omezena doba platnosti hesla a po uplynutí této doby by měl být uživatel vyzván k jeho změně. Pokud je uživateli nastaveno tzv. defaultní heslo, měl by ho systém vyzvat ke změně hesla hned po prvním přihlášení do systému. Systém by také neměl vyzrazovat, který ze zadávaných údajů je špatný, zda jméno nebo heslo.

Doba platnosti hesla by měla vycházet z funkční závislosti mezi délkou hesla, množinou použitých znaků a dobou potřebnou k jeho prolomení, tak jak jsme si uvedli v příspěvku jak vytvořit bezpečné heslo. Většina běžně používaných systémů je schopna tyto parametry kontrolovat. Případně je možné tuto funkcionalitu získat nahrazením příslušné knihovny nebo instalací odpovídajícího modulu a slovníku. S kontrolou kvality hesla se lze setkat i u nejrůznějších webových aplikací, kde bývá kvalita hesla dost často znázorněna i graficky. Na základě výše uvedených skutečností si můžeme definovat následující požadavky:

• Password history – kolik hesel si má systém pamatovat. Jde o to, aby uživatel opakovaně nepoužíval např. jen dvě různá hesla. Na druhou stranu je nutné si uvědomit, že pokud má systém kontrolovat, zda dané heslo již nebylo použito, tak musí být toto heslo v systému nějak uloženo.
• Account lockout threshold – počet pokusů o přihlášení, po vyčerpání těchto pokusů se účet uzamkne. V minulosti se často povolovaly jen tři pokusy, v současnosti se lze setkat s pěti a více pokusy o přihlášení. Ukazuje se, že tři pokusy je opravdu málo, neboť k uzamčení stačí (ne)aktivovaný Caps Lock, Num Lock nebo přepnutá klávesnice.
• Account lockout duration – doba po kterou je účet uzamčen. Účet je možné uzamknout trvale. V takovém případě může být odemknut pouze administrátorem systému. Nebo je možné ho uzamknout dočasně např. na půl hodiny. Po uplynutí této doby se účet odemkne sám.
• Minimum password age – minimální doba platnosti hesla. Někteří bezpečnostní experti doporučují hodnotu 0, aby si uživatel mohl změnit heslo kdykoliv, třeba ihned poté co si nastavil heslo nové. Např. když má podezření, že jeho heslo mohlo být odchyceno nebo odpozorováno. Jiní zase požadují, aby minimální hodnota byla nastavena na 1, aby si uživatel nemohl snadno nastavit původní heslo a obešel tak Password history omezení.
• Maximum password age – maximální doba platnosti hesla by měla vycházet z délky a komplexity hesla a měla by být nižší než doba, za kterou je útočník schopen heslo prolomit hrubou silou.
• Display the number of unsuccessful login attempts since last login – systém by měl zobrazovat informace o posledních neúspěšných pokusech o přihlášení od posledního úspěšného přihlášení.
• Display previous logon information – systém by měl zobrazit informaci o tom, kdy a kde se uživatel naposledy přihlásil.
• Concurrent logons – užitečná může být i informace o tom, že je uživatel již přihlášen. Buď je opravdu přihlášen na více systémech, případně ve více oknech nebo se na jeho účet přihlásil někdo jiný.

Uživatelské účty

Doposud jsme se zabývali jen parametry hesla, ale jde i o samotnou identifikaci uživatele. Pokud je použit identifikátor, který je vytvářen nějakým systémem a vykazuje určitou pravidelnost, je možné takové účty snadno zablokovat jednoduchým skriptem, který se na ně bude postupně nebo zcela náhodně hlásit a opakovaně zadávat libovolný řetězec znaků. Doporučujeme uživateli zobrazovat nejen počet neúspěšných pokusů od posledního přihlášení, ale i datum, čas a název stanice, ze které k poslednímu přihlášení došlo. Jedině tak se může uživatel alespoň zpětně dozvědět, že jeho účet byl zneužit.

Administrátorské účty

Identifikátor resp. název účtu by neměl vyzrazovat, k čemu slouží. Tento požadavek nesplňuje např. účet Administrator nebo root. Na takové účty je velice snadné vést útok a pokusit se heslo prolomit hrubou silu, protože tyto účty se běžně nezamykají. Určitým řešením je defaultní účty přejmenovat tak, aby nevyzrazovaly, k čemu slouží. Postup útočníka se tím minimálně zpomalí. V systému MS Windows je také možné účet Administrator (RID=500) po určitém počtu neplatných pokusů o přihlášení uzamknout a umožnit se na něj přihlásit jen lokálně. Nastavení se provádí přes passprop.exe (NT4) resp. pwdProperties (pozdější verze) viz Microsoft KB885119.

Systémové a aplikační účty

Účty, které jsou používány systémem a aplikacemi, mají obvykle silná práva, neuzamykají se. Použití těchto účtů je vhodné omezit pouze na konkrétní stroje, aby se na ně nemohl nikdo hlásit ze své stanice. Vzhledem k tomu, že se tyto účty neuzamykají, je vhodné je monitorovat a v případě neúspěšného pokusu o přihlášení generovat alert. Samozřejmě, že můžete stejným způsobem monitorovat i uživatelské a administrátorské účty, ale je vhodné si stanovit nějaké priority.

A co vy, zaznamenáváte a vyhodnocujete úspěšné a neúspěšné pokusy o přihlášení?

Štítky: autentizace, informační bezpečnost

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.