Jak udržet svá hesla v bezpečí

V prostředí IT obecně, ale v dnešní době i v rámci každodenního života v online prostoru, si není možné představit využití všemožných služeb, bez nějaké varianty ověření identity uživatele. Asi nejstarším a nejjednodušším způsobem autentizace je použití přihlašovacího jména a hesla, tedy něčeho, co uživatel zná, a na základě čeho by mělo být možné důvěřovat tomu, že jde skutečně o danou osobu.

Problém je, že služeb, kam je nutné se autentizovat, je stále více a více. Pracovní e-mail, soukromý e-mail, banka, bezpočet e-shopů, sociální sítě… Ponechme nyní stranou, jak správně tvořit hesla, případně jakými metodami metody ověření uživatele zkvalitnit. Tomuto tématu se můžeme věnovat někdy příště. Ovšem jeden bod stojí za zdůraznění, a to je doporučení nepoužívat jedno a to samé heslo pro všechny služby.

Jenže to se snadno řekne. Jak zkombinovat požadavky na bezpečnost – minimální délku hesla, použití malých a velkých písmen, číslic, speciálních znaků, a to celé si zapamatovat? A teď ještě pro každou službu použít jiné heslo?

Pro většinu uživatelů není reálné udržet v hlavě dostatečně silná hesla pro větší množství služeb. I nejlepší paměť se občas unaví a déle nepoužité heslo hrozí zapomenutím. Částečné řešení problému je vytvářet si hesla podle nějakého algoritmu, který znáte jen vy, a dokážete si podle něj heslo zapamatovat. Ovšem v tomto případě hrozí obdobné riziko, jako použití shodného hesla všude, pokud někdo odhalí váš algoritmus pro generování hesel.

Co nemáš v hlavě, musíš mít v nohách…, tedy přesněji v tomto případě ve správci hesel. Webové prohlížeče již dlouhou dobu vycházejí uživatelům vstříc, a nabízejí ukládání hesel různých služeb, do šifrované databáze, nejčastěji zpřístupněné zadáním jednoho, hlavního, hesla. Tuto funkcionalitu nabízejí i v distribuované formě, takže hesla můžete mít dostupná na více zařízeních.

Toto řešení má svá pro i proti. Je nutné vycházet z předpokladu, že databáze hesel bude dostatečně zabezpečena (v tomto musíte důvěřovat tvůrci a provozovateli uložení hesel) a že hlavní heslo je dostatečně silné a znáte ho jen vy. Pokud jsou tyto podmínky splněny, nic nebrání použití dostatečně silných, ideálně náhodně generovaných hesel pro jednotlivé webové služby. Ponechme stranou potenciální rizika zcizení takto uložených hesel pomocí nedostatečného zabezpečení stránek, ke kterým přistupujete.

Ale co v případě, že jde o jinou situaci, než o přístup k webové stránce? I tam lze využít některého ze správců hesel. Služeb a aplikací je na výběr více.

V posledních týdnech došlo bohužel k hlášení o bezpečnostních problémech a úniku dat některých z nich (konkrétně LastPass a NortonLifeLock). Logicky se tedy rozproudila diskuse o bezpečnosti jednotlivých řešení a jednotlivé služby jsou nyní pod drobnohledem, což je správně. V rámci tohoto “auditu” došlo k upozornění na potenciální riziko v aplikaci KeePass, což je další správce hesel, který je oblíbený mimo jiné proto, že databáze s hesly je uložená lokálně a že aplikace je dostupná zdarma.

Objevené riziko není ani tak zranitelnost v pravém slova smyslu, a daná funkcionalita existuje v aplikaci již velmi dlouho. Riziko je ovšem v tom, že o její existenci běžní uživatelé nevědí, a v případě jejího zneužití ani nejsou nijak upozorněni na podezřelou aktivitu.

Nešťastná byla také reakce autora aplikace, který považoval její chování za správné, a neměl v úmyslu aplikaci v tomto směru upravit. V diskusích se vedly doslova filosofické debaty o tom, jestli riziko je nebo není relevantní, a jestli má vůbec smysl se jím zabývat.

Za sebe mohu říci, že se kloním na stranu implementace jakéhokoli řešení, které bezpečnost zvýší, i s vědomím toho, že existují i jiné vektory útoku, které lze použít. Nemá smysl pokrčit rameny, že dokonalé řešení stejně neexistuje, a hesla útočníkovi naservírovat na stříbrném podnose.

Medializace a tlak veřejnosti nakonec vedly k tomu, že autor do aplikace implementoval částečné řešení, ale ani stávající stav není úplně optimální.

KeePass obsahuje možnost nastavit triggery (aktivity vykonané při nějaké údálosti) na různé operace, což lze zneužít v případě, že útočník má možnost zápisu na váš disk.

To bohužel může nastat relativně snadno, například nevhodným povolením skriptů v Excelu, případně zneužitím chyby v jiné aplikaci. Útočník následně může upravit konfiguraci KeePassu tak, aby obsahovala trigger, který vyexportuje hesla v čitelném formátu v okamžiku, kdy KeePass databázi odemknete.

Aplikace vás na tuto událost bohužel ani neupozorní. Vy tedy pracujete s aplikací jak jste zvyklí a jako kdyby se nic nestalo. Na disku ale mezitím vznikne seznam vašich hesel, který může útočník v dalších krocích zneužít.

Momentálně není žádné definitivní a spolehlivé řešení než KeePass opustit. Pokud ale chcete u aplikace zůstat, doporučuji vám aktualizovat na poslední verzi (v této chvíli 2.53.1), která situaci zlepšila. Nicméně ani toto řešení není příliš uživatelsky přívětivé a z bezpečnostního hlediska “neprůstřelné”.

Trigger pro export hesel si totiž nyní vyžádá opakované zadání hesla databáze pro provedení exportu. Pokud by se tedy stalo, že útočník upraví konfiguraci KeePass tak, aby při otevření databáze hesel provedla jejich export, vypadalo by to takto.

KeePass se Vás při otevření databáze zeptá na heslo, jako vždy:

Pokud ho zadáte správně, databáze se otevře, a pokud v konfiguraci je útočníkem podvržený požadavek na export, dojde k jeho spuštění. Ale v nové verzi je tato operace autorizována opakovaným dotazem na heslo:

Jak vidíte, dialog se kromě nadpisu neliší. Uživatel tedy může v rychlosti nabýt dojmu, že napoprvé zadal heslo špatně, vyplní ho znovu, a tím autorizuje nechtěný export.

Jako rychlý workaround, který alespoň minimalizuje rizika, můžete provést toto:

1. Spusťte Notepad jako administrátor (Start / Notepad / kliknout pravým tlačítkem / Spustit jako správce)

2. Vložte následující obsah:

<?xml version=“1.0″ encoding=“utf-8″?>
<Configuration xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“ xmlns:xsd=“http://www.w3.org/2001/XMLSchema“>
<Security>
<Policy>
<Export>false</Export>
<Print>false</Print>
</Policy>
</Security>
</Configuration>

3. Text uložte jako soubor KeePass.config.enforced.xml do složky C:\Program Files\KeePass Password Safe 2\ (případně do jiné cesty, kde máte KeePass nainstalovaný). Podstatné je, aby soubor KeePass.config.enforced.xml byl uložený tam, kde je KeePass.exe, který používáte. Pokud používáte portable verzi, zajistěte, aby do ní nebylo možné zapisovat s právy obyčejného uživatele.

Pokud používáte KeePass na Linuxu, je potřeba výše zmíněný obsah uložit do souboru /usr/lib/keepass2/KeePass.config.enforced.xml

Cílem této úpravy je znemožnění akce exportu hesel do souboru mimo hlavní databázi. Její úspěšnost je založená na tom, že je tato konfigurace uložená v souboru, do kterého nemá běžný uživatel právo na zápis, bez toho, aby ho systém vyzval k udělení přístupu. Pokud k tomuto dotazu na udělení oprávnění dojde při běžných operacích, měl by uživatel vždy zpozornět.

I s tímto rizikem je stále lepší použít správce hesel, než mít hesla zapsaná v čitelném formátu v textovém souboru nebo v Excelu na ploše, nebo používat opakovaně stejné heslo pro více služeb. Zvažte tedy, jestli děláte vše pro to, abyste udrželi svá hesla a v důsledku i svá nebo firemní data, v bezpečí.