Hesla na jedno použití

Řadu problémů popsaných ve výše uvedeném článku dokážeme účinně eliminovat, máme-li k dispozici zařízení (obvykle nazývané token), které generuje heslo, které se mění, například v závislosti na čase. Říkáme mu jednorázové heslo, anglicky one-time password, používá se též zkratka OTP.

V první řadě nepotřebujeme spojení SSL šifrovat[1], protože heslo je jednorázové, nelze ho použít opakovaně a nepředstavuje samo o sobě žádné tajemství.

Lze snadno zavést dvoufaktorovou autentizaci, druhým faktorem (například po zadání klasického statického hesla) je vlastnictví tokenu pro generování OTP. Valná většina hardwarových i softwarových tokenů aktuální heslo nijak nechrání, stačí stisknout tlačítko nebo se podívat na displej, není nutné zadávat žádný PIN nebo něco podobného. OTP je tedy doplňkem hesla, nikoliv jeho náhradou[2].

Výhodou je, že na straně autentizující se osoby není kromě tokenu třeba žádné zvláštní vybavení: jednorázové heslo má podobu 6–8 číslic, které stačí opsat, přímé propojení tokenu s počítačem není třeba[3]. Lze se tedy autentizovat na cizím počítači, v internetové kavárně atd.

Hardware nebo software?

Hardwarové tokeny jsou relativně levné (okolo 4 EUR při koupi jednoho kusu, s množstvím cena dramaticky klesá). Nicméně je nutné řešit jejich distribuci, výměny a podporu. Trvanlivost tokenů také není neomezená, vydrží většinou 3–5 let.

Alternativou je softwarové generování, aplikace existují pro všechny běžně používané mobilní platformy – Android, BlackBerry, iOS, J2ME, Windows Mobile i Windows Phone 7. Velká část potenciálních uživatelů tedy speciální hardware nebude potřebovat.

Hardwarové tokeny jsou jenom tak bezpečné, jak bezpečné jsou systémy jejich výrobců. V praxi se o tom přesvědčilo čtyřicet miliónů uživatelů zmiňovaného systému RSA SecurID, když v březnu společnost RSA vydala velmi vágní prohlášení[4] o tom, že se stala cílem úspěšného útoku, který mohl kompromitovat právě systém SecurID[5]. Hrozí nebezpečí, že unikl seznam seedů, tajných informací, které slouží jako základ pro generování hesla.

Softwarové tokeny mají (resp. mohou mít) tu výhodu, že seedy v nich nejsou zadané napevno, ale může si je volit autentizující strana, aniž by bylo nutné spoléhat se na výrobce.

Řešení pro jednorázová hesla existují desítky, nabízí je každá větší společnost, pohybující se v oblasti počítačové bezpečnosti, namátkou lze jmenovat RSA SecurID, Gemalto EasyOTP, PointSharp, Entrust IdentityGuard, SafeNet eToken a další. Většina těchto řešení je ovšem cílena spíše na velké zákazníky a nabízí komplexní (a patřičně drahá) řešení. Navíc i přes existenci sdružení OATH[6] je interoperabilita jednotlivých řešení spíše zbožným přáním, než realitou.

Varianty OTP

Existují ovšem i otevřené standardy, pomocí kterých může jednorázová hesla snadno implementovat kdokoliv. V následujícím textu se podíváme na zoubek dvěma technologiím, známým pod zkratkami HOTP a TOTP.

HOTP generuje nové heslo na požádání, typicky na základě stisku tlačítka na tokenu. TOTP generuje nové heslo automaticky v závislosti na čase, typicky každých 30 nebo 60 sekund.

Event-based OTP (HOTP)

V tomto případě se jedná skutečně o jednorázové heslo, vygenerované na žádost a použitelné nejvýše jednou. Zkratka HOTP znamená HMAC-based One Time Password, což je docela výstižný popis fungování. Algoritmus je detailně popsán v RFC4226[7], já popíšu jenom základní princip.

Každá ze stran komunikace (token a ověřující server) musí znát dvě informace: tajemství a počítadlo. Tajemství (angl. secret nebo také seed) je obecně hromádka náhodně vygenerovaných bajtů, sdílené tajemství mezi serverem a klientem. Zde je jedno ze slabých míst systému: tuto informaci si musí mezi sebou strany nějak bezpečně předat. Nicméně předání funguje jednorázově, není nutné pro běžný provoz. V případě hardwarových tokenů bývá „tajemství“ pevně zadrátováno a dostanete jej při koupi tokenu od výrobce napsané na papírku[8]. V případě softwarových tokenů je obvykle nutné jej zadat při inicializaci. Druhým klíčovým parametrem je počítadlo (counter) již vygenerovaných he­sel.

Výpočet jednorázového hesla pak probíhá tím způsobem, že po stisku tlačítka token uchopí aktuální hodnotu počítadla a zahashuje ji pomocí HMAC-SHA1[9], přičemž použije „tajemství“ jako klíč. Výsledkem je 160-bitová hodnota, která by sama o sobě byla použitelná jako jednorázové heslo. Bylo by ovšem poněkud nepohodlné opisovat těch čtyřicet hexadecimálních číslic, které hash obvykle tvoří.

Proto RFC4226 definuje postup, kterým se ze 160-bitové hodnoty vyextrahuje několik (obvykle 6–8) desítkových číslic. To sice sníží odolnost algoritmu (a vyžaduje, aby na straně serveru byla implementována nějaká funkce, která omezí velké množství požadavků), ale učiní celý systém použitelným.

Ztráta synchronizace

Pro úspěšnou autentizaci je nutné, aby mělo počítadlo vygenerovaných hesel na obou koncích stejnou hodnotu. Ale může snadno dojít k tomu, že token vygeneruje více hesel, než kolik se jich dostane k serveru (stačí, aby si nikdo nic zlého netuše pohrál s tlačítkem). V praxi se postupuje tak, že pokud heslo nesouhlasí, předpokládá server, že mohlo dojít k narušení synchronizace a zkusí vygenerovat několik následujících hesel. Pokud se shodují, prohlásí heslo za správné a posune si počítadlo o patřičný počet kroků dopředu. Vhodný počet hesel je záležitostí konfigurace a kompromisem mezi uživatelskou přívětivostí a bezpečností.

Pokud toto selže, token lze za určitých okolností resynchronizovat – pokračovat s generováním hesel tak dlouho, dokud se „netrefíme“ a poté si vyžádat několik dalších hesel jako potvrzení. Nemusí to být ale možné vždy a dále to snižuje bezpečnost.

Důvěryhodnější ověření zadáním více hesel

Pro kritické operace (jako je třeba změna hesla, zrušení účtu atd.) lze zvýšit bezpečnost tím, že budeme požadovat zadání ne jednoho, ale několika po sobě následujících hesel. Pokud by se útočníkovi podařilo třeba „brute force“ metodou odhalit jedno heslo, pravděpodobnost, že odhalí dvě po sobě následující, je výrazně nižší.

Vzájemné ověření

Jednorázová hesla na principu HOTP lze využít ke vzájemnému ověření, tedy lze potvrdit uživateli, že komunikuje skutečně se správným serverem. Stačí, když po úspěšném přihlášení server vygeneruje další heslo v pořadí a zobrazí jej uživateli. Ten může udělat totéž a hesla se musejí shodovat.

Problém se zálohou tokenu

V případě hardwarového tokenu tento problém nemusíme řešit. Nicméně v případě tokenů softwarově emulovaných může nastat problém při „přeinstalaci“ daného zařízení. Aby přihlášení fungovalo, musí si token pamatovat stav počítadla, což by znamenalo po každém použití zálohovat, nestačí zálohovat třeba jednou denně.

Jeden token = jeden systém

Použití HOTP tokenu musí být exkluzivní. Tentýž token není možné použít pro přihlášení do několika různých systémů, které spolu nejsou propojené. Všechny systémy totiž musejí sdílet společný čítač vygenerovaných hesel. Platí to i obráceně, nelze mít několik tokenů k jednomu systému, pokud s tím systém nebude přímo počítat ve svém návrhu, tokeny (byť by měly stejné „tajemství“, nejsou vzájemně nahraditelné).

Papírový token

Vzhledem k tomu, že sekvence hesel je předem daná, není v zásadě nutné, aby se heslo počítalo v okamžiku potřeby. Hesla je možné předpočítat dopředu a „tokenem“ se může stát obyčejný kus papíru, na který je vytiskneme[10]. Není to řešení právě elegantní, ale své kouzlo má jako nouzové a dočasné řešení. Lze si představit například scénář, kdy z nějakých důvodů chceme zaměstnanci dát dočasně přístup do vnitrofiremní VPN, chráněné jednorázovými hesly. Například po dobu výjimečné služební cesty nebo dovolené.

Time-based OTP (TOTP)

Druhý způsob je závislý nikoliv na počtu vygenerovaných hesel, ale na aktuálním čase. Zkratka TOTP znamená Time-based One Time Password.

Princip generování hesla je stále stejný, jenom se místo počítadla použije aktuální čas. RFC6238[11] předpokládá, že se jako pohyblivý faktor použije počet celých třicetisekundových intervalů, které uběhly od 1. 1. 1970 00:00:00 UTC, ačkoliv implementace často používají i šedesátisekundové intervaly.

TOTP také počítá s použitím novějších hashovacích algoritmů z rodiny SHA-2. Nicméně pro účely generování jednorázových hesel je z praktických důvodů dostatečně dobré i SHA-1 a dokonce i mírně antikvární MD5. Proč? Protože všechny známé útoky, vedené na hashovací algoritmy, směřují k nalezení kolizních dokumentů, nikoliv k nalezení původního textu před provedením hashe. Nalezení kolizního dokumentu představuje problém pro situaci, kdy hash slouží k ověření integrity nebo k vzájemnému propojení dvou dokumentů (jako je tomu v případě elektronického podpisu), ale nikoliv v případě HMAC. Podrobnější popis problematiky lze najít matematicky vyjádřen v pojednání „M. Bellare: New Proofs for NMAC and HMAC: Security without Collision-Resistance“[12] nebo v běžným smrtelníkům poněkud srozumitelnější podobě v příloze B již citované RFC4226.

První dávka výhod a nevýhod je v podstatě inverzí bodů, které jsem uváděl jako vlastnosti HOTP v předchozích odstavcích. TOTP token nelze použít ke vzájemnému ověření ani k vygenerování několika následujících hesel pro zvýšení bezpečnosti. Na druhou stranu, není problém jeden token používat k několika nezávislým systémům ani mít k jednomu systému tokenů několik (ačkoliv to z bezpečnostního hlediska není nápad příliš šťastný). Rovněž není problém se zálohou a obnovením softwarového tokenu, protože jediné, co potřebujete, je znát „tajemství“.

Ztráta časové synchronizace

V případě, že se rozejdou hodiny na straně serveru a na straně klienta, znamená to samozřejmě problém. Serverové implementace obvykle postupují tak, že si vygenerují heslo pro předchozí a následující časový interval a ten zkusí použít.

V případě softwarových tokenů je pomoc snadná – stačí nastavit správný čas (předpokládáme, že server v takové aplikaci bude mít čas synchronizovaný přes NTP s důvěryhodným zdrojem). U hardwarového tokenu je víceméně nejjednodušší token zahodit a používat jiný. Server si nicméně může při přihlášení zaznamenat obvyklé zkreslení a přizpůsobit se [13].

Ne tak úplně jednorázové

TOTP negeneruje jednorázová hesla, ale hesla s omezenou dobou platnosti. Budeme-li uvažovat interval změny 30 sekund a server bude akceptovat jedno heslo „dopředu“ a jedno „dozadu“, heslo bude platné teoreticky 90 sekund, prakticky nejvýše 60.

Pokud nepřijmeme dodatečná opatření na straně serveru (který si např. bude pamatovat hesla zadaná v poslední době a opakované zadání odmítne), může odposlouchávající útočník jednorázové heslo zneužít ke druhému přihlášení, bude-li dostatečně rychlý.

Vestavěná obrana proti brute-force útokům

V případě event-based OTP musíme na straně serveru přijmout dodatečná opatření proti útokům hrubou silou – po zadání většího množství chybných hesel účet zablokovat a nebo lépe zpomalit odezvu[14].

Time-based OTP má takovou obranu fakticky vestavěnou, protože na uskutečnění brute-force útoku má útočník jenom 90 sekund (při intervalu 30 s a jedním akceptovaným heslem na každou stranu). Je dosti nepravděpodobné, že by za takovou dobu bylo možné úspěšný brute-force útok provést.

Závěrem

Klasická hesla jsou sice nejrozšířenější a na implementaci nejjednodušší řešení autentizace na Internetu, ale zároveň z hlediska bezpečnosti patrně nejproblematič­tější. Vícefaktorová autentizace se s rozšířením „chytrých“ mobilních telefonů stala dostupnější než kdy předtím. Některé weby již jednorázová hesla používají jako volitelný doplněk pro zvýšení bezpečnosti, například většina služeb od Google.

Vzhledem k existenci otevřených standardů pro jednorázová hesla lze snadno a levně implementovat tuto formu autentizace do vlastních systémů. Na výběr je ze dvou metod pro generování hesel, jedna je založená na počtu vygenerovaných hesel a druhá na aktuálním čase. Obě metody mají své výhody i nevýhody, které byly popsány výše.

Pro většinu technologií používaných pro vývoj webových aplikací existují knihovny podporující jednorázová hesla. V rámci full disclosure se sluší poznamenat, že autor tohoto článku je autorem jedné z nich pro Microsoft .NET Framework, Altairis OTP Authentication Library. Jedná se o open source projekt, který lze nalézt na http://otpauth­.codeplex.com/.