Autentizace: Jednorázová hesla – HOTP

V tomto příspěvku se podíváme, na jakém principu funguje generování jednorázových hesel pomocí algoritmu HOTP.

HMAC-Based One-Time Password, zkr. HOTP, který je popsán v RFC4226, využívá pro generování jednorázového hesla (One-Time Password, zkr. OTP) algoritmus, který může být vzhledem ke své jednoduchosti a nízkým požadavkům na výpočetní výkon provozován v podstatě na jakémkoliv HW. Není tedy divu, že je tento algoritmus používán např. i v SW tokenech, které jsou k dispozici v podstatě pro všechny nejpoužívanější mobilní OS.

Poznámka: Asi nejznámějším SW tokenem, který tento algoritmus implementoval, je např. Google Authenticator, který slouží ke generování OTP, jež je dalším faktorem použitým v rámci dvoufaktorové autentizace ke službám společnosti Google.

Pro vygenerování OTP tímto algoritmem je nutné zvolit nějaké číslo C (counter), které se s každým vygenerovaným OTP zvyšuje a dále pak statický symetrický klíč K (key), který představuje sdílené tajemství mezi klientem a serverem. Oba tyto parametry pak vstupují do výpočtu OTP. Aby bylo zajištěno, že každé nově vygenerované OTP bude jedinečné, musí C logicky nabývat pokaždé jiné hodnoty. A protože útočník nezná hodnotu K, není schopen vygenerovat OTP a nepomůže mu ani zachycení OTP.

Poznámka: Zachycení OTP sice útočníkovi neumožní z něj odvodit OTP, které bude tokenem vygenerováno příště, nicméně nelze mu jednoduše zabránit v tom, aby toto OTP nezneužil, viz minulý příspěvek, ve kterém jsme zabývali tím, zda jsou jednorázová hesla opravdu bezpečná.

Sdílené tajemství K mezi klientem a serverem může být generováno jako náhodné číslo pomocí SW nebo HW generátoru, což popisuje např. RFC4086. Přičemž toto sdílené tajemství musí být dobře chráněno. Na tokenu se sice může nacházet jen seed, tedy pokud je K generováno až v okamžiku stisku tlačítka např. z HW, ale na straně serveru, vůči kterému se autentizujeme, se K negeneruje, nýbrž je zpravidla uloženo v nějaké DB. Je zřejmé, že aby byla zajištěna bezpečnost, je nutné tuto DB šifrovat, řídit k ní přístup a zavést i další bezpečnostní opatření.

Vzhledem k tomu, že v rámci HOTP resp. HMAC je použita hashovací funkce SHA-1, musí být její výstup, o délce 20bytů zkrácen a převeden na číselnou hodnotu v dekadické soustavě, kterou je uživatel schopen snadno přepsat. Výsledkem proto zpravidla bývá minimálně 6ciferné číslo, ale může být i delší. Nejprve musíme z 20bytového řetězce vyříznout řetězec o délce 4bytů, přičemž nejméně významný bit 160bitového řetězce udává pozici offsetu. Rozuměj pozice, na které začíná 4bytový řetězec. (Tato operace se v RFC4226 označuje jako dynamic truncation.) Následně provedeme logický součin s 7fffffff, výsledek převedeme do desítkové soustavy a podělíme ho 10^X, přičemž nás bude zajímat zbytek po dělení, kterým je Xmístné OTP. Chceme-li 6místné OTP, je X=6, chceme-li 9místné, je X=9. Jednoduché, že?

Zkrácením délky původně 20bytového řetězce na 4bytový se však podstatně zvyšuje šance, že se útočníkovi podaří toto OTP hrubou silou uhodnout, a proto je nutné zavést opatření k omezení počtu pokusů o přihlášení (A=attempt) např. na 3 nebo s každým chybně zadaným OTP prodlužovat čas (T=time). To znamená, že s každým neúspěšným pokusem o přihlášení bude prodleva (D=delay) narůstat. D=T*A. Pokud bude T=5, tak po prvním neúspěšném pokusu o přihlášení se D=5, po druhém D=10, po třetím D=15.

Pokud se však hodnota C na serveru zvýší o jednu vždy, když dojde k úspěšné autentizaci, zatímco na straně klienta, kde je OTP generováno, se hodnota C zvyšuje o jednu s každým vygenerovaným OTP, tedy i s tím, které uživatel třeba vůbec nezadá, je nutné, aby se server dokázal se skutečností, že na klientovi i na serveru nabývá C jiných hodnot, nějak vyrovnat. V okamžiku, kdy server obdrží OTP, které neočekával a C(klient)>C(server), požádá klienta o zaslání ještě jednoho OTP a pak generuje OTP tak dlouho, dokud nenarazí na OTP, která od klienta obdržel a tím dojde i ke sjednocení hodnoty C.

Zkoušet však C do nekonečna není možné, to by mohlo dojít k odepření služby, a proto musí dojít po určitém počtu pokusů k zablokování účtu. Jiným řešením je, že klient pošle serveru kromě OTP i hodnotu C, server tak bude vědět, pro jaké C má OTP spočítat.

Tímto způsobem generované OTP nemusí sloužit jen k autentizaci uživatele, ale může posloužit i uživateli k ověření, že komunikuje se správným serverem. Klient zadá OTP. Server též spočte OTP, a pokud se OTP rovnají, může klientovi zobrazit další OTP a klient si tak může ověřit, že komunikuje se správným serverem.

Výstupem HOTP nemusí být jen PIN, ale může jím být i alfanumerický řetězec, který je při stejné délce podstatně bezpečnější. Zatímco v případě 6místného PIN máme k dispozici jen 10^6 kombinací, tak v případě 6místného alfanumerického řetězce to je 36^6 kombinací. Osobně však doporučuji některé znaky raději nepoužívat, protože občas bývá problém je rozpoznat. Napadá vás, které znaky to jsou? Napište.

Štítky: autentizace, OTP

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.