Hesla jsou pravděpodobně zcela zbytečná

První obrannou linií jsou hesla uživatelů. Často jsou však velmi snadno prolomitelná. Minulý týden jsme provedli a...


První obrannou linií jsou hesla uživatelů. Často jsou však velmi snadno
prolomitelná.

Minulý týden jsme provedli audit hesel v naší doméně i v dceřiné společnosti,
se kterou máme nastaven obousměrný vztah důvěry. Po zhlédnutí výsledků
uvedených ve zprávě jsem byla sklíčená. Zavolala jsem si celý bezpečnostní tým
a řekla jim: "Klidně můžeme jít domů. Nemá smysl, abychom tu nadále tloukli
hlavou do zdi." K čemu je nám dobrý firewall, když lze uhádnout více než 50 %
hesel na síti?
Náš audit hesel byl ojedinělou událostí a nikoli pravidelným bezpečnostním
opatřením. Ptáte se proč? Skutečnost je taková, že máme na práci tolik věcí, že
jsou někdy nejvíce očividné aspekty bezpečnosti přehlíženy. Trpíme nedostatkem
zaměstnanců, nástrojů, času, povědomím zaměstnanců o bezpečnosti i
nedostatečným prosazováním stanovených bezpečnostních pravidel. Když jsem do
firmy nastoupila, udělala jsem zásadní chybu, když jsem předpokládala, že
stanovená politika hesel je pracovníky IT skutečně prosazována v celé naší
firmě i v jejích dceřiných společnostech. Moje vlastní uvědomování si
důležitosti bezpečných hesel mi svým způsobem uškodilo; protože se snažím, aby
moje heslo nebylo prolomeno, zvolila jsem si jej tak, aby bylo bezpečné, takže
mě vůbec nenapadlo politiku hesel naší společnosti testovat.


Politika hesel
Ale vraťme se zpátky na začátek. Co záleží na tom, zda firewall provádí správně
logování, zda je heslo na SQL Server prázdné či zda jsou naše záplaty aktuální,
pokud chybí správně prosazovaná politika hesel uživatelů? Hesla jsou první
linií obrany.
V síti Windows se politika hesel nastavuje na úrovni domény, u nás to zajišťuje
služba Active Directory. Naše současná politika zahrnuje následující pravidla:
lUchovává se deset posledních hesel, čili znovu použít první heslo můžete až po
té, co zadáte jedenácté.
lHesla expirují nejpozději za 45 dní.
lHesla musejí splňovat požadavky komplikovanosti: nesmějí obsahovat žádnou část
uživatelského jména, musejí být alespoň 8 znaků dlouhá a znaky musejí být
nejméně ze třech ze čtyř kategorií: malá písmena anglické abecedy, velká
písmena anglické abecedy, číslice a speciální znaky jako !, $ nebo #.
Tohle všechno možná zní dobře, ale tato politika není dost přísná a připouští
hesla jako Password1 či Password2. Překvapí někoho, že takové typy hesel jsme v
naší síti objevili?

Kroky k nápravě
Když jsem dostala seznam uživatelů, jejichž hesla byla snadno uhádnutelná,
hledala jsem mezi nimi klíčové manažery, doménové administrátory a další
potenciálně rizikové uživatele. Našla jsem zástupce všech těchto skupin. Byli
mezi nimi hodně viditelní manažeři s velmi hloupými hesly. Mým prvním krokem
byl e-mail jednomu z administrátorů domény se žádostí, aby si změnil heslo tak,
aby bylo bezpečnější. Následně jsem poslala seznam vedení a požádala je o
souhlas kontaktovat viceprezidenta IT naší dceřiné společnosti, aby pomohl při
zavedení přísnější politiky hesel.
Dalšími kroky je takovou politiku sestavit, získat souhlas od vedení, politiku
publikovat, upravit podle ní technickou správu hesel a pak čekat na hlasité
protesty koncových uživatelů. Přijetí přísnějších pravidel zní jako logický
záměr, ale jako profesionálové na bezpečnost víme, že co dává dobrý smysl nám,
často naráží u jiných na všechny myslitelné druhy odporu.

Jak na to
Zajímavou otázkou ale je, jak bude naše nová politika hesel vypadat. Jeden z
mých bezpečnostních inženýrů prosazuje implementaci OTP (One-Time Password,
heslo na jedno použití) generované pomocí tokenů SecurID. V současnosti již
máme autentizační schéma s tokeny pro vzdálené přihlašování přes VPN, ale
interně je zatím nepoužíváme. Stále mu ale říkám, že tímto přístupem nijak
nepomůžeme našim uživatelům čelícím problémům s hesly. Mnoho z nich potřebuje
řadu hesel pro přihlášení do nesčetného množství aplikací, a tak si prostě
poznamenávají svá hesla na monitory. Předpokládám, že by tomu bylo stejně i s
tokeny. Nebo ještě hůř, uživatelé by své tokeny obden ztráceli. Doporučila
jsem, abychom místo toho začali prosazovat projekt jednotného přihlašování
(single-sign-on). Velmi zajímavou možností je použití přístupových frází
(passphrases) místo hesel. Proč? Jsou delší než hesla a obtížnější na
prolomení. Přístupovou frázi typu "Všechno, co si přeji k Vánocům, jsou mé dva
přední zuby!" je statisticky mnohem obtížnější prolomit právě díky počtu znaků,
přidání mezer, různým délkám slov a jejich umístění.
Když jsem se zabývala tímto problémem, narazila jsem na nedávno publikovanou
sérii článků od Jespera M. Johanssona, který je manažerem v bezpečnostní
obchodní a technologické divizi Microsoftu. Jak užitečný objev!
Johanssonova třídílná série zkoumá otázku, zda jsou přístupové fráze lepší než
hesla. První část poskytuje základní informace o použití frází, druhá část se
zaměřuje na matematickou statistiku, která je na pozadí prolamování hesel i
frází a poslední část poskytuje rady, jak volit hesla a definovat politiku
hesel.
Ve druhé části Johansson tvrdí, že si uživatelé mohou pamatovat i dlouhé
přístupové fráze, že delší fráze jsou silnější a že fráze v sobě obsahují více
náhody než hesla.
Debata fráze versus hesla mě fascinuje a jsem nedočkavá zajímá mě, co se z toho
vyklube. V naší společnosti jsme se snažili naučit koncové uživatele, aby do
svých hesel přidávali speciální znaky a aby vymýšleli (a pamatovali si) hesla
nedávající smysl. Nebylo by bezvadné, kdybychom jim mohli ukázat snazší a
mnohem bezpečnější způsob přístupu?
Řešíte podobné problémy jako C. J. Kellyová? Podělte se o svoje zkušenosti s
námi i se čtenáři Computerworldu. Můžete psát na adresu bezpecnost@idg.cz.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.