Novinky

Více než 30 IDM realizací v České republice i zahraničí

AMI Praha Vícefaktorová autentizace v praxi
Vícefaktorová autentizace v praxi

Vícefaktorová autentizace v praxi

Princip autentizace, který nespoléhá na jediný zdroj ověření identity uživatele, je již poměrně rozšířen nejen v bankovní sféře, kde jsme se s ním jako uživatelé setkávali nejdříve, ale i u dalších služeb, které obsahují citlivá data. Začínáme chránit své emaily, sociální sítě a fotogalerie před nechtěnou ztrátou důvěrnosti (tedy – vyzrazením nechtěné osobě).

Proč tomu tak je?

Donedávna by se zdálo, že nám hesla k ochraně informací budou dostačovat. Ale jak ukazují různé průzkumy, uživatelé nejsou příliš zodpovědní při jejich volbě. Například společnost SplashData, která vyvíjí systémy na úschovu hesel, provádí od roku 2011 výzkumy nejčastějších hesel.

Za rok 2014 [1] v nejčastější desítce skončila hesla 1234 až 12345678, password, qwerty, baseball, dragon, football. Ačkoli se situace zlepšuje a uživatelé používají častěji více náhodná hesla, stále ještě se lze s jedním z 25 nejčastějších hesel přihlásit do každého 50. účtu. Pomocnou ruku k lepšímu zabezpečení zde nabízí právě MFA.

Vícefaktorová autentizace (MFA)

Cílem MFA je zlepšit proces ověření identity – a tedy i snížit pravděpodobnost hacknutí účtu – přidáním dalšího způsobu autentizace uživatele, tedy dalšího faktoru. V principu se můžeme bavit o třech oblastech faktorů (viz obrázek 1):

1. Něco, co uživatel zná: tato kategorie představuje nejčastější způsob autentizace. Řadí se sem například heslo, PIN ke kartě, atributy („První kamarád z dětství“), rozpoznání „svého“ obrázku mezi jinými či kresba gesta na obrazovce.

2. Něco, co uživatel má: obecně to co uživatel dostal – kreditní kartu, hardwarový token na svazku klíčů, osobní doklady, mobilní aplikace, telefonní karta, SSH autentizační klíče, a též například sada vygenerovaných autentizačních kódů (Google Authenticator).

3. Něco, co uživatel je: zde se uplatní skenery biometrických dat, ať už se jedná o otisky prstů, sken rohožky, hlas či rozpoznání kontur obličeje. Pro zajímavost: Historie identifikace zločinců začínala právě s touto metodou (Antropometrie pana Bertillona [2]).

Obrázek 1 – Vícefaktorová autentizace, možnosti

Hlavní výhoda vícefaktorové autentizace je – jak jsme si ukázali – v její bezpečnosti. Aby útočník získal přístup ke chráněnému zdroji (bankovnímu kontu, účtu na počítačovém systému, cloudové službě), musí být schopen získat všechny faktory, kterými se dotyčná osoba přihlašuje (poznámka: mluvíme zde o osobě, ale v praxi se tento přístup používá i v automatizovaném styku, kdy spolu komunikují programy a systémy napřímo).

A v tom je právě síla metody MFA. Vynucenou autentizací více faktory zabráníme útočníkovi převzít kontrolu nad chráněným zdrojem při ovládnutí jednoho přihlašovacího přístupu.

Jak je to s bezpečností?

Slabina znalostních faktorů spočívá v jejich predikovatelnosti, což je vidět například z uvedeného seznamu nejčastějších hesel. Další riziko pak představuje lidský faktor – napsání PINu na platební kartu, hesla na lísteček a podobně. Události okolo krádeže fotek celebrit z Apple iCloud ukazují, že ani osobní otázky nejsou bezpečné, pokud jste známá osoba.

Faktory, které má uživatel v držení, jsou náchylné k okopírování, jakmile se k nim útočník dostane. Stará metoda otisku klíče od bytu se zde zmodernizovala do kopírování magnetických proužků platebních karet nástavbou nad bankomatem. Velmi časté jsou i krádeže a ztráta faktoru jako takového (mobilní telefon, USB token). Dalším rizikem je takzvaný man-in-the-middle útok: vetřelec vstoupí do komunikace mezi například softwarovým tokenem a autentizačním serverem a odposlechne zasílaný kód.

To u biometrických faktorů to s bezpečnostní není tak jednoznačné. Na jednu stranu jejich velká výhoda je unikátnost (papilární linie, sítnice), na druhou stranu se nedají tak snadno změnit. V případě jejich mechanického zkopírování je pak daný faktor do budoucna už napořád zatížen rizikem prolomení.

Obrázek 2 – Ukázka dvoufaktorové autentizace na úvěrovém webu pro BTC

Ztráta faktoru

Právě druhá skupina – faktory v držení – zaznamenávají v poslední době velký rozmach, především v souvislosti s online službami. V této oblasti začínají dominovat takzvané softwarové tokeny – aplikace na chytrém zařízení (Google Authenticator, Amazon AWS MFA, Authy), která ve spojení s autentizačním serverem generuje pseudonáhodné řetězce čísel (obecně znaků), které uživatel přepisuje do autentizačního formuláře.

Noční můrou těchto uživatelů je pak ztráta mobilního zařízení, a tím i odepření přístupu ke svému účtu. Co tedy lze v případě ztráty faktoru dělat? Možností je více, a záleží na konkrétním poskytovateli služby.

V případě offline služby (přístup do konzole serveru) bude pravděpodobně zapotřebí osobní návštěva zástupce vydavatele s žádostí o nové vydání/spárování tokenu. U online služeb, kdy je uživatel od vydavatele více či méně odstíněn, je třeba buď prokázat svoji identitu jinak (příklad: Bitstamp [3]: zasláním naskenovaných dokladů), nebo se spolehnout na svépomoc: Buď si uživatel uložil autentizační kód pro znovuspárování (Google Authenticator), nebo provede reinicializaci přes SMSku. Některá řešení tomuto vycházení vstříc, a dokáží se spárovat sama, pokud uživatel použije stejnou SIM kartu (Authy). E-mailová zpráva, běžný komunikační kanál u resetu hesla, se v případě tohoto faktoru nepoužívá kvůli své nízké bezpečnosti.

Praktické příklady

Jak můžou taková řešení používající vícefaktorovou autentizaci vypadat, si ukážeme na následujících případech sofistikovanějších MFA mechanismů. Jeden je z oblasti bitcoinové ekonomiky, druhý z oblasti správy unixových serverů.

Dvoufaktorová autentizace v Bitstampu není vynucená, je čistě na uživateli, zda chce své prostředky lépe ochránit. Zajímavostí je, že v případě Bitstampu lze za jeden z faktorů považovat i přihlašovací jméno. To je totiž uživateli přiděleno, přičemž se jedná o náhodně vypadající shluk číslic, sloužící interně jako zákaznické číslo.

BitGo – step-up autentizace

Jednou z ambiciózních peněženek pro virtuální měnu Bitcoin [3] je projekt BitGo [4]. Za hlavní devizu své služby považují přístup k zabezpečení měny v uživatelské peněžence, který chrání vlastním řešením vícefaktorové autentizace, nazývaném „2 ze 3“.

MFA je v tomto případě nasazené hned dvakrát: při přístupu k účtu, a při finanční operaci s bitcoiny (odesílání).

Obrázek 3 – BitGo, přihlášení do služby

Pro základní přístup do svého účtu v BitGo použije uživatel dvoufaktorovou autentizaci: zadá své jméno a heslo, načež mu na spárovaném mobilním telefonu vygeneruje aplikace Authy jednorázový přístupový kód (One-Time Password, OTP). Po přihlášení je uživatel vpuštěn do svého účtu. Nemá však zatím možnost odesílat ze své peněženky prostředky. K tomu musí provést takzvanou step-up autentizaci

Obrázek 4 – BitGo, step-up autentizace při finanční operaci

Princip step-up autentizace je rozdělení bezpečnostních oprávnění do různých úrovní. Každá úroveň pak definuje minimální úroveň autentizace pro její použití. V našem případě je jedna úroveň pro práci s účtem (ta vyžaduje heslo+Authy), a druhá úroveň pro práci s Bitcoiny (vyžaduje znalost přístupového klíče).

Při vytváření peněženky si uživatel zvolí přístupový klíč. Na základě toho se mu vygenerují dva zámky na peněženku: soukromý, který má pouze u sebe, a v BitGo. Peněženku pak lze odemknout libovolným z nich (například v případě, pokud by BitGo bylo nedostupné). Tento princip adresuje velkého strašáka online služeb – hacknutí služby za účelem obohacení se. Pokud se tak stane v tomto případě, dostanou se útočníci k datům na první bezpečnostní úrovni, ale pro odemknutí peněženky budou potřebovat znát přístupový kód, který se v BitGo neukládá.

Key Distribution Manager – 3FA

Lepšího zabezpečení privilegovaných (administrátorských) účtů na serverech s operačním systémem Linux/Unix se snaží dosáhnout produkt KDM [5]. Používá k tomu třífaktorovou autentizaci: Něco, co uživatel zná (passphrase), něco, co má svého (SSH klíč) a něco, co znát nemůže (druhý SSH klíč). Fungování si opět ukážeme na schématu (Obrázek 6).

Privilegovaný uživatel zde k úspěšnému přihlášení potřebuje znát své přístupové údaje (jméno, heslo) a dále passphrase, pomocí které si vygeneruje nový SSH autentizační klíč (krok 1). Veřejnou část svého vlastního klíče už předtím na KDM server nahrál.

Obrázek 5 – Key Distribution Manager, třífaktorová autentizace

KDM server vygeneruje nový pár SSH autentizačního klíče. Privátní část zašle uživateli (2), a obě veřejné části nahraje na cílový server (3). Privátní části jsou tedy uloženy u uživatele, bezpečně v autentizačním agentovi (Pageant). Nyní pokaždé, když uživatel chce přistoupit na cílový server, proběhne autentizace pomocí obou privátních částí SSH autentizačního klíče (4).

Kombinací těchto faktorů je jednak zabezpečen přístup na koncový systém, jednak je zajištěna nepopiratelnost přístupu administrátora i v případě, kdy dojde k útoku na KDM server. Zároveň je bezpečnost posílena tím, že uživatel je jediným vlastníkem obou privátních klíčů.

Závěr

V tomto článku jsme se nahlédli do oblasti vícefaktorové autentizace. Ukázali jsme si proč je důležitá, a probrali bezpečnostní otázky spojené s jejím používáním. Také jsme si na dvou praktických ukázkách předvedli, jak vypadá robustnější nasazení MFA v praxi.

Ať už provozujete bankovní služby, e-shop nebo věrnostní portál, vícefaktorová autentizace vám výrazně pomůže zvýšit zabezpečení uživatelského přístupu. Jen nepodceňte schopnost uživatelů zapomínat a ztrácet přístupové prostředky, a dejte jim možnost, jak MFA dočasně bezpečně vypnout, nebo zresetovat.

Autor: Petr Gašparík pracuje posledních 5 let jako solution architect pro oblast IT bezpečnosti. Ve společnosti AMI Praha působí 17. rokem a má za sebou řadu významných IT projektů pro zákazníky z komerční i veřejné správy např. ČEZ, Česká pošta, UniCredit Bank Czech Republic and Slovakia.

Zdroje

[1] http://splashdata.com/press/worst-passwords-of-2014.htm

[2] http://www.quido.cz/osobnosti/bertillon.htm

[3] http://cs.wikipedia.org/wiki/Bitcoin

[4] http://bitgo.com

[5] http://www.ami-kdm.cz/

Článek byl publikován v časopise IT Systems 4/2015.