Novinky

Takřka každý informační systém potřebuje znát identitu uživatele, který k němu přistupuje. A každý z nich potřebuje mít také akceptovatelnou úroveň jistoty, že přistupující uživatel je tím, za koho se vydává. Pryč jsou doby, kdy stačilo ověření jménem a heslem. S nástupem bankovních aplikací se uživatelé seznámili s použitím certifikátů jako autentizačního nástroje. V korporátní sféře zase existuje povědomí o přihlašování pomocí hardwarových tokenů. O těchto rozličných způsobech identifikace uživatele, a jejich vhodném použití, je vícefaktorová autentizace (MFA).

Co je vícefaktorová autentizace?

Vícefaktorová autentizace (anglicky multi-factor authentication, zkráceně MFA) je metoda ochrany přístupu k prostředku (například webu či informačnímu systému), založená na kombinaci zabezpečení ve třech oblastech (takzvaných „faktory“):

• Znalost – něco, co uživatel zná nebo je mu sděleno
• Vlastnictví – něco, co má uživatel ve svém držení
• Biometrie – něco, co představuje uživatele samotného – čím uživatel sám je

O MFA mluvíme v případech, kde je třeba zajistit ověření identity přistupující k informačnímu systému více způsoby.

Větší bezpečnosti je zde dosáhnuto diverzifikací zabezpečení nejen co do počtu, ale i co do různých faktorů. Pokud útočník například získá přístup k něčemu, co uživatel zná (hesla uložená na počítači), není zabezpečení heslem a PINem tak bezpečné, jako například heslem a HW tokenem.

Příklad vícefaktorové autentizace

Standardní situace při přihlášení pomocí vícefaktorové autentizace může vypadat takto: Uživatel zná svoje přihlašovací jméno ve specifickém tvaru (i to lze považovat za formu znalostního faktoru, byť je veřejně zjistitelné) a heslo (znalostní faktor). Na klíčích má pověšen hardwarový token (faktor v držení), který navíc může být doplněn o PIN (opět znalostní faktor).

Máme zde tedy tři informace, které musí uživatel znát, z toho dvě tajné, a jednu věc, kterou musí mít při sobě. V praxi pak přihlášení může vypadat podobně, jako na následujícím obrázku:

Vícefaktorová autentizace – příklad přihlášení pomocí hesla, PINu a hardwarového tokenu

Faktory

Představme si krátce příklady autentizačních mechanismů v jednotlivých faktorech:

Faktor „Znalost“

Zde se jedná prakticky o cokoli, na co si je uživatel schopen vzpomenout. Klasickým příkladem je heslo a PIN (ať už ke kartě, nebo k mobilnímu telefonu), ale patří sem i výběr obrázků podle vlastní preference (např. SW Confident ImageShield), nakreslení gesta/znaku (odemčení Androidu, volba přihlášení do Windows 8), či stále oblíbené osobní otázky („Jméno matky za svobodna““) a osobní atributy (RČ, město narození). Patří sem ale i vygenerované jednorázové kódy, které lze použít například jako obálkovou zálohu k jinému faktoru.

Příklad gesta na obrazovce mobilního telefonu s OS Android

Faktor „Vlastnictví“

Tento faktor představuje zjednodušeně to, co lze nosit v kapse nebo peněžence. To zahrnuje například hardwarové tokeny (RSA SecurID, Yubikey), platební karty, mobilní telefony (aplikace využívající IMEI) a SIM karty (ověření zpětným voláním a pomocí SMS OTP, např. Eset Secure Authentication) a v zobecněné podobě i osobní doklady (občanský, řidičský průkaz, pas).

Faktor „Biometrie“

Faktor „Biometrie“ zahrnuje charakteristiky svého nositele. Čtenáře snadno napadne otisk prstu, rozšířený jak ve sféře notebooků (podpora přihlašování například ve Windows 7,8), tak mobilní techniky (příkladem jsou zařízení iPhone generace 5 a 6). Další možnosti je například sken očnice, který známe zatím spíše z akčních filmů, anebo rozpoznávání obličeje, které je naopak známé především uživatelům OS Android (podpora od verze 4.2 Jellybean; ve verzi 5 Lollipop je tento sken prováděn automaticky; u jiných mobilních OS je tohoto možno dosáhnout aplikačně). Autentizace hlasem je naproti tomu stále doménou speciálních programů (například řešení od firem Nuance, Autentify, Voxeo). Speciální kategorií je pak charakteristika „jsem člověk“, která se používá například v CAPTCHA mechanismu, nebo obecně tam, kde je řešení jednoduché, ale špatně algoritmizovatelné („klikněte na obrázek psa“).

V diskuzi jsou další faktory, jako je geolokace (kde se uživatel nachází) a čas (kdy se tam nachází). Ty se dají využít v boji s útoky na MFA, jak je popsáno v závěru článku.

Rizika a trendy autentizačních tokenů

Pojďme se nyní podívat na zoubek tomu, co je nového ve slibně se rozvíjející oblasti tokenů, která tvoří velmi častou komponentu dvoufaktorové autentizace.

Hardwarové (HW) tokeny

V korporátní sféře jsou hardwarové tokeny převládajícím způsobem realizace autentizačních tokenů.

Klasickým představitelem je RSA token, který používá pro generování kódu čas. Novější variantou je například Yubikey, který slouží jako jednoúčelová klávesnice a ke generování přístupového kódu používá sekvenční metodu.

Hardwarové tokeny v praxi – RSA SecurID a Yubikey Standard

Princip fungování je následující:

1. Každý token je unikátně identifikován
2. Autentizační server má tento token přiřazen k uživateli
3. Token generuje přístupový kód dle definovaného algoritmu (na základě času či sekvenční metodou)
4. Server zaslaný kód porovná na své straně s kódem, který si vygeneruje stejným algoritmem
5. Pokud se kódy shodují, je uživatel tímto faktorem ověřen

Výhoda tohoto přístupu je zjevná: aby někdo zfalšoval přístup někoho jiného, musí kromě uživatelského jména a hesla získat i fyzický přístup k tokenu.

Nevýhody HW tokenů jsou především v nenulové pořizovací ceně a potřebě fyzicky spravovat životní cyklus tokenu (vydání, obměna, skartace). V případě osamostatněných tokenů je též vyšší riziko man-in-the-middle útoku.

Softwarové (SW) tokeny

Trendem, řešící některé nevýhody svých hardwarových protějšků, jsou softwarové (SW) tokeny.

Jedná se typicky o aplikaci na chytrém telefonu (OS Android, iPhone, Windows Phone aj.). Použití je shodné. Software v telefonu se spáruje s autentizačním serverem a od té doby generuje klíče, kterým autentizační protějšek rozumí.

Příklady: Google Authenticator, Authy, Amazon AWS MFA.

Princip spárování SW tokenů

Výhody

Tento přístup umožňuje kombinovat autentizační tokeny pro více služeb v jednom zařízení. Není tedy nutné pro každý server mít vlastní hardwarový token, vše obstará aplikace, která generuje kódy pro všechny zaregistrované služby najednou.

Nevýhody

Rizika řešení jsou podobná jako u HW tokenu. Dopady ztráty zařízení však může být vyšší, což je spojeno s tím, že SW tokeny se častěji používají online (na rozdíl od korporátní sféry u HW tokenů), kde je složitější reautorizace. Přístup k tomuto riziku je různý:

• Některá řešení vyžadují mít záložní jednorázově vygenerované kódy (Google Authenticator). V takovém případě je možné se po ztrátě/reinstalaci zařízení znovu autorizovat vůči cílové aplikaci, kterou je třeba následně znovu propojit s generátorem autentizačních kódů (reautorizace).
• Jiná řešení si poradí i s reinstalací chytrého telefonu, neboť jim pro reautorizaci stačí SIM karta (Authy). Zde při ztrátě mobilního telefonu stačí získat zpět své původní mobilní číslo.
• Poslední možností je kontaktování poskytovatele služby. Ten po ověření uživatele jiným způsobem (PIN, sken dokumentů) provede vypnutí vícefaktorové autentizace a umožní její reinicializaci uživatelem (Amazon AWS MFA).

Ukázka softwarových tokenů – Authy a Google Authenticator

Rizika

Velkým rizikem tohoto faktoru je existence zařízení, na němž aplikace SW tokenu běží. Bezpečnost faktoru je tak závislá na zabezpečení celého zařízení. Jaké nebezpečí může hrozit, je známé z autorizačních SMSek – pokud má škodlivá aplikace právo ke čtení těchto zpráv, může se útočník, ovládající aplikaci, vydávat za uživatele.

Dvoufaktorová, nebo dvoukroková autentizace?

V souvislosti s MFA se často mluví o dvoufaktorové, respektive dvoukrokové autentizaci. Jaká je vlastně mezi nimi rozdíl?

Začneme tím, co mají společného: Obě dvě používají na sobě nezávislé informace k ověření identity uživatele. Teprve po ověření obou je možné prohlásit identitu uživatele za potvrzenou.

Rozdíl je v to, jak se obě informace vyberou. V případě dvoufaktorové autentizace je ověření provedeno dvěma faktory, tedy informacemi z různých oblastí (znalost + vlastnictví, znalost + biometrie, vlastnictví + biometrie), zatímco v případě dvoukrokové autentizace je požadavkem pouze nezávislost informací v obou krocích (mohou však být oba například z faktoru „znalost“: heslo + poslední 4 znaky z rodného čísla).

Z praxe

Příkladem dvoufaktorová autentizace je například použití platební karty + PINu (bankomat), či mobilního telefonu + PINu, nebo přihlášení do webových obchodů jménem + SMS (t-zones).

U dvoukrokové autentizace lze jako příklad uvést například ověření při zpětných hovorech operátorů pomocí jména a posledních 4 číslicích z rodného čísla (oboje znalostní faktory).

Dvoufaktorová autentizace od Google Accounts

MFA v prostředí internetu

„Klasické online služby“

Hojně využívané internetové služby podporují ve velké míře SMS jako druhý faktor. Google Accounts a Dropbox podporují navíc softwarové tokeny. AWS (Amazon WS, framework pro aplikace) je pak příkladem rozšířené autentizační služby, která pro ověření uživatele nabízí jak softwarový, tak hardwarový token.

Přehled použití:

Bitcoinová ekonomika

Velkého rozšíření mezi uživatele se MFA dostalo v oblasti bitcoinové ekonomiky. Obchody, převody, nákupy – prakticky vše v této oblasti probíhá online. S ohledem na princip fungování virtuálních měn odvozených od bitcoinu (tj. decentralizovaná správa a anonymita) se vyrojilo spoustu webů, fungujících jako těžební platforma, virtuální peněženka, burza měn, či brána mezi virtuálními a papírovými měnami.

Je proto logické, že tam, kde jde o peníze (jakkoli v tomto případě virtuální), jen jednokrokové ověření jménem a heslem již nepostačuje. Oblíbené je proto používání dvoufaktorové autentizace, a to většinou s řešeními Google Authenticator, či Authy. A zatímco u výše zmíněných klasických online služeb je druhý faktor jakýsi bonus navíc, v případě této kategorie webů je brán jako záruka solidnosti. Případů, kdy byly různé burzy, těžební pooly, virtuální peněženky vyloupeny a prostředky anonymně převedeny.

Praxe však zde předběhla teorii, nebo přesněji edukaci. Projevuje se to v krátkozrakosti uživatelů, kteří například správně použití druhý faktor v podobě softwarového tokenu, avšak nedomyslí již dopady ztráty nosiče tokenu. Po ztrátě mobilního přístroje to pak může vypadat podobně, jako kdyby své prostředky uživatel nechránil vůbec – prostě se k nim nedostane. S určitou nadsázkou tak můžeme bitcoinovou ekonomiku přirovnat k Divokému západu vícefaktorové autentizace.

Rizika

Nedávný případ úniku soukromých fotek nejen hollywoodských celebrit ukazuje slabé místo jednofaktorové autentizace. Na vině zde byla slabá aplikace Find My iPhone, která umožňovala neomezené množství pokusů o přihlášení pomocí jména a hesla, bez časové prodlevy mezi pokusy. V návaznosti na tuto událost Apple zapnul dvoufázové ověření na službě iCloud pomocí SMS nebo pomocí zmíněné vlastní aplikace.

Že však ani dvoufaktorové zabezpečení nemusí být samospasitelné, dokazuje případ novináře Mata Honana, o kterém se psalo v roce 2012. Dobře ilustruje, že rozdílné stupně zabezpečení služeb od různých poskytovatelů můžou zmařit i dobrý záměr. V případě pana Honana stačilo, aby útočník získal přístup na novinářův účet na Amazonu, odkud získal poslední 4 číslice kreditní karty, a následně se si pomocí tohoto údaje, a známé poštovní adresy oběti nechal zresetovat heslo nebožáka. Šlo o demonstraci slabiny systému, na jehož konci byl kompletní výmaz dat Mata Honana ze služby iCloud a převzetí účtu Google a Twitter.

Je tedy vidět, že i s použitím vícefaktorové autentizace tak lze s dostatečným časem a/nebo nešťastnou kombinací různě zabezpečených přístupů dosáhnout falešně pozitivní autentizace identity uživatele.

Zlepšení lze dosáhnout přidáváním dalších autentizačních faktorů, které však snižují komfort uživatele. Další variantou je použití správy přístupu se začleněním rizikového profilu žádosti o autentizaci. Tato myšlenka je zpracována v konceptu zvané Risk-Adaptable Access Control (RAdAC).

RAdAC – Risk-Adaptable Access Control

Myšlenka za konceptem RAdAC je následující: Nechme uživatele přihlašovat za standardních podmínek komfortně, a teprve, když se zvedne úroveň rizika, vyzveme jej k přihlášení dalším faktorem.

Vstupy pro posouzení stupně rizika jsou možné definovat poměrně košatě. Mezi základní patří: kdo se hlásí (oprávnění uživatele, pozice ve firmě, historie uživatele), jak se hlásí (zabezpečení přístupu jako je VPN, důvěryhodnost zařízení – osobní počítač či kavárna) a za jakých podmínek se hlásí (v práci, doma, v zahraničí, přes den, o svátcích).

Výsledkem tohoto posouzení v reálném čase je rizikový profil (navázaný například na podnikové politiky přístupu), který může předepsat další autentizační modul, nebo případně autentizační pokus ukončit. Hlásí se uživatel nečekaně z ciziny? Dostane autentizační kód do SMS. Jezdí do ciziny dle historie pravidelně? Pak je to nejspíš v pořádku, pakliže použije VPN. Hlásí se administrátor v noci k finančnímu softwaru? Pak bude takové spojení rovnou odmítnuto. A podobně.

Koncept řízení přístupu ke službě podle rizikového profilu

Koncept se pomalu dostává do implementací balíkových nástrojů typu Access Manager a Security Analytics (Forgerock OpenAM, Oracle Adaptive Access Manager). Ty tak doplňují SIEM nástroje o aktivní uživatelskou složku. U online služeb můžeme zárodky konceptu vidět v upozorňování uživatele na předchozí přihlášení z jiné lokace (Gmail). Ani mobilní operační systémy nezůstávají pozadu, poslední verze Androidu (5.0, Lollipop) umožňuje například vynucovat silnější zámek obrazovky podle geolokace, případně podle připojeného Bluetooth zařízení (například možnost mít vždy odemknutý telefon s handsfree sadou v autě). Dalším příkladem, tentokrát z reálného života, jsou bezkontaktní platební karty, kde se PIN zadává pouze v případě nákupu nad stanovenou hranici, nebo kontrolně v náhodných intervalech.

Závěr

Vícefaktorová autentizace dokáže dobře chránit uživatelskou identitu, díky čemuž je dobře zakořeněná v korporátní sféře podnikových aplikací. Nyní se jí dostává pomalu, ale jistě široké podpory i mezi poskytovateli online služeb, čímž se dostává i do povědomí uživatelů. Toto rozšíření s sebou však nese nejen početnou fragmentaci autentizačních řešení, ale i nevyvážené zabezpečení různých služeb, které uživatelé používají. To s sebou nese rizika, která představují nejen hackeři, ale i uživatelé sami sobě. Efektivní metodu boje s těmito riziky představuje například koncept rizikových profilů RAdAC.

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 ICT Services, Česká pošta, či UniCredit Bank Czech Republic and Slovakia.

Článek byl pubikován v časopise SecurityWorld 4/2014.