Přeskočit na hlavní obsah

Vícefaktorové ověření (MFA)

  • Také známé jako dvoufaktorová autentizace (2FA)
  • Situace, kdy je uživatel povinen předložit více než jeden faktor, aby se mohl přihlásit
  • Existují 4 typy faktorů
    1. Něco, co zná (heslo, PIN, bezpečnostní otázka)
    2. Něco, co vlastní (hardware nebo software token, certifikát, email, SMS a volání)
    3. Něco, kým je (otisk prstů, rozpoznávání obličejů)
    4. Poloha (rozsah zdrojových IP adres, geolokace)

Výhody

  • Nejčastějším ohrožením uživatelských účtů jsou slabá, opakovaně používaná nebo ukradená hesla
  1. Vždy předpokládejte, že hesla uživatelů budou někdy prozrazena
    1. Navrhněte systém tak, aby se proti tomu uměl bránit

Nevýhody

  • Zvýšení složitosti správy pro správce i uživatele
  • Pro mnoho uživatelů může být obtížné MFA nakonfigurovat
  • Hardwarová MFA zařízení přinášejí značné náklady a administrativní režii
  • Pokud uživatel ztratí své faktory, může dojít k zablokování účtu
  • Vnáší do aplikace složitost
  • Mnoho řešení přidává do systémů externí závislosti - může přinést bezpečnostní zranitelnosti
  • Procesy související s resetováním MFA mohou být zneužity útočníky
  • Vyžadování MFA může uživatelům znemožnit přístup k aplikaci

Rychlá doporučení

  1. Zvažte všechny faktory, na kterých implementace závisí (model ohrožení, technická úroveň uživatelů, atd.)
  2. Poskytněte uživatelům možnost povolit MFA (TOTP)
  3. Vyžadujte MFA u administrátorských nebo jiných vysoce privilegovaných účtů
  4. Povolte podnikový IP rozsah, aby nebylo vyžadováno MFA
  5. Umožněte uživateli zapamatovat si MFA v prohlížeči, aby ho nemusel používat při každém přihlášení
  6. Implementujte bezpečný proces pro resetování MFA

Implementace MFA

Kdy MFA vyžadovat

  • Kromě přihlašování je vhodné i při provádění citlivých akcí
    • Změna hesla nebo bezpečnostních otázek
    • Změna emailové adresy
    • Zakázání MFA
    • Přepnutí účtu z uživatelského na administrátorský
  1. Implementujte MFA také pro API

Zlepšení použitelnosti

  • MFA představuje pro uživatele zátěž
  1. Posuďte riziko a najděte rovnováhu mezi bezpečností a použitelností před implementací vylepšení popsaných níže
  2. Umožněte uživatelům zapamatovat si prohlížeč, aby nemuseli pokaždé používat MFA
    • Trvalé nebo na několik dní
    1. Použijte více než jen soubor cookie (může být ukraden)
      • Např. cookie odpovídá IP adrese, pro kterou byl vydán
  3. Povolte rozsah firemních IP adres
    • Nechrání před zákeřnými osobami nebo napadením pracovní stanice
  4. Vyžadujte MFA pouze pro citlivé akce (závisí na funkcionalitě aplikace)

Neúspěšné pokusy o přihlášení

  • Pokud uživatel zadá své heslo a nepodaří se mu přihlásit pomocí druhého faktoru, může to znamenat, že
    • uživatel ztratil / nemá k dispozici svůj druhý faktor
    • uživatelské heslo bylo ukradeno
  1. Vyzvěte uživatele k vyzkoušení jiné formy MFA (SMS namísto OTP tokenu)
  2. Umožněte uživateli resetovat MFA
  3. Upozorněte uživatele na neúspěšný pokus o přihlášení a vyzvěte ho, aby si změnil heslo, pokud ho nezná
    • Oznámení by mělo obsahovat čas, prohlížeč a zeměpisnou polohu pokusu o přihlášení
    1. Zobrazte tuto informaci při příštím přihlášení a zašlete ji emailem

Reset MFA

  • Uživatel může svůj druhý faktor ztratit několika způsoby
    • Reinstalace PC bez backupu
    • Ztráta telefonu nebo zařízení bez backupu tokenů
    • Změna telefonního čísla
  • Důležité je, aby reset mechanismus neumožňoval útočníkovi zmocnit se účtu uživatelů
  • Neexistuje žádný “nejlepší způsob” implementace - vše závisí na aplikaci (implementaci posuzujte vždy v kontextu aplikace)
  1. Poskytněte uživateli několik jednorázových kódů pro obnovení MFA při prvním nastavení
  2. Požadujte, aby si uživatel nastavil více MFA (digitální certifikát + telefonní číslo)
  3. Umožněte zaslání jednorázového kódu pro obnovení
  4. Požadujte, aby uživatel kontaktoval podporu a ověřil svou totožnost
  5. Požadujte, aby se za uživatele zaručil jiný důvěryhodný uživatel

Něco, co zná

  • Nejběžnější typ ověření
  • Velmi nízké nároky na uživatele a vývojáře
  • Nevyžaduje speciální hardware a integraci s jinými službami

Hesla a PINy

  • Nejběžnější forma ověřování
  • Jednoduchá implementace
  • Většina systémů využívá heslo a alespoň jeden další faktor
  • PIN, tajná slova a další jsou stejná jako hesla
  • Více informací najdete v cheat sheetu autentizace a správa hesel

Výhody

  • Jednoduché a srozumitelné
  • Nativní podpora ve většině frameworků
  • Jednoduchá implementace

Nevýhody

  • Uživatelé mají tendenci volit slabá hesla
  • Hesla se běžně používají opakovaně
  • Náchylnost k phishingu

Bezpečnostní otázky

  • Vyžadují výběr nebo vytvoření otázek, na které bude znát odpověď jen sám uživatel
  • Považovány za slabší než hesla
  • Více informací naleznete v OWASP cheat sheetu o bezpečnostních otázkách

Výhody

  • Jednoduché a srozumitelné

Nevýhody

  • Často mají snadno uhádnutelné odpovědi
  • Odpovědi mohou být získatelné ze sociálních sítí nebo jiných zdrojů
  • Otázky musí být pečlivě zvoleny, aby si uživatel pamatoval odpověď i za několik let
  • Náchylné na phishing

Něco, co vlastní

  • Fyzický nebo digitální předmět, vlastnictví telefonu nebo emailové adresy
  • Administrativní zátěž pro uživatele - musí mít daný faktor u sebe
  • Obtížnější kompromitace pro útočníka
  • Může omezit přístup některých uživatelů ke službě

Hardwarové OTP tokeny

  • Neustále se měnící číselné kódy
  • Nejznámější je RSA SecureID - generuje šestimístné číslo každých 60 sekund

Výhody

  • Téměř nemožné vzdáleně kompromitovat
  • Tokeny lze používat, aniž by uživatel musel mít telefon nebo jiné zařízení u sebe

Nevýhody

  • Nákladné a komplikované
  • Při ztrátě tokenu trvá dlouho zakoupení a zaslání nového
  • Některé implementace vyžadují backendový server - nové potenciální zranitelnosti a bod selhání
  • Ukradené tokeny lze použít bez PINu nebo kódu pro odemknutí zařízení
  • Náchylné na phishing (krátkodobě)

Softwarové TOTP tokeny

  • TOTP = Time-based One Time Password
  • Levnější a jednodušší alternativa HW tokenů
  • Vyžaduje instalaci aplikace do telefonu a naskenování QR kódu
  • Generuje šestimístné heslo každých 60 sekund
  • Většina webů používá standardizované tokeny - umožňují instalaci libovolné aplikace
    1. Implementujte standardizované řešení - vyhněte se vlastnímu / jinému řešení

Výhody

  • Snížení nákladů a administrativy oproti HW tokenům
  • Snadná konfigurace v případě ztráty přístupu k TOTP aplikaci
  • TOTP aplikace jsou široce používané
  • Nemožnost krádeže kódu v případě existence zámku obrazovky na telefonu

Nevýhody

  • TOTP aplikace se instalují do mobilů, které jsou náchylné ke kompromitaci
  • Aplikace může být nainstalována na stejném zařízení, které se používá pro přihlášení
  • Uživatelé mohou záložní seedy ukládat nezabezpečeně
  • Nemožnost přihlášení při ztrátě nebo vybití telefonu
  • Ne všichni uživatelé mají možnost používat TOTP
  • Náchylné na phishing (krátkodobě)

Hardwarové U2F tokeny

  • Komunikují s pracovní stanicí uživatele (USB, NFC)
  • Provádějí ověření na základě výzvy, místo ručního zadání kódu
    • Uživatel stiskne tlačítko na tokenu nebo se dotkne NFC čtečky

Výhody

  • Lze použít delší kódy - vyšší úroveň zabezpečení
  • Uživatelé mohou místo zadání kódu stisknout tlačítko
  • Odolné vůči phishingu

Nevýhody

  • Vyšší náklady a administrace
  • Ukradené tokeny lze použít bez PINu nebo kódu pro odemknutí zařízení
  • Pravděpodobnost zapomenutí USB a následná ztráta nebo odcizení

Certifikáty

  • Soubory uložené v zařízení uživatele
  • Při ověřování se automatický zadávají spolu s heslem
  • Nejběžnější certifikát je X.509 (viz zabezpečení transportní vrstvy)
  • Podporovány hlavními prohlížeči
  • Po instalaci nevyžadují žádnou interakci ze strany uživatele
  • Měly by být spojeny s uživatelským účtem jednotlivce

Výhody

  • Není potřeba kupovat a spravovat HW tokeny
  • Po instalaci jsou velmi jednoduché
  • Lze je centrálně spravovat a revokovat
  • Odolné vůči phishingu

Nevýhody

  • Vyžadují backend PKI systém
  • Obtížná instalace pro uživatele, zejména v prostředí s omezenými možnostmi
  • Proxy servery provádějící dešifrování SSL zabrání použití certifikátů
  • Jsou uloženy na pracovní stanici uživatele a jako takové mohou být odcizeny (pokud je systém kompromitován)

Čipové karty

  • Mají velikost kreditní karty
  • Obsahuje čip s digitálním certifikátem uživatele
  • Odemykání pomocí PINu
  • Běžné k ověřování v operačním systému (na webu jen zřídka)

Výhody

  • Ukradené karty nelze použít bez znalosti PINu
  • Lze je používat ve více aplikacích a systémech
  • Odolné vůči phishingu

Nevýhody

  • Nákladné s administrativní zátěží
  • Nejsou nativně podporovány prohlížeči (vyžadují software třetích stran)
  • Domácí systémy (narozdíl od podnikových) často nemají vestavěné čtečky karet
  • Vyžaduje backend PKI systém

SMS zprávy a volání

  • K poskytnutí jednorázového kódu

Výhody

  • Relativně jednoduchá implementace
  • Vyžaduje propojení telefonního čísla s účtem uživatele

Nevýhody

  • Vyžaduje vlastnictví mobilu
  • Vyžaduje dostatečný signál
  • Odeslání SMS nebo hovoru může stát peníze
    • Vyžaduje ochranu prostředků - zabezpečení proti nadměrnému počtu zaslaných zpráv
  • V minulosti byla zneužita řada útoků na tento faktor
  • Zprávy a hovory mohou být přijímány na stejném zařízení, ze kterého se uživatel přihlašuje
  • Náchylné k phishingu

Email

  • Vyžaduje zadání kódu nebo kliknutí na odkaz
  • Často se vedou diskuze o tom, zda je email MFA
    • Pokud uživatel nemá MFA na svém emailu, vyžaduje to pouze znalost hesla, které může být stejné jako pro přístup do aplikace

Výhody

  • Snadná implementace
  • Nevyžaduje vlastnictví HW zařízení

Nevýhody

  • Spoléhá se na zabezpečení emailového účtu
  • Heslo k emailu je často stejné jako do aplikace
  • Neposkytuje žádnou ochranu, pokud je email kompromitován
  • Email může být přijímat na stejném zařízení, ze kterého se uživatel přihlašuje
  • Náchylný na phishing

Něco, kým je

  • Fyzický atribut (biometrie)
  • Ve webových aplikacích se používá jen zřídka
  • Vyžaduje specifický HW

Biometrika

  • Otisk prstů, rozpoznávání obličejů, sken duhovky, otisk rukou

Výhody

  • Obtížné podvrhnutí - vyžaduje cílený útok

Nevýhody

  • Vyžaduje ruční zápis fyzických atributů uživatele
  • Ke čtení je zapotřebí vlastní HW (drahé)
  • Prohlížeče nemají nativní podporu (nutnost vlastního software na straně klienta)
  • Ukládání citlivých fyzických informací (obava o ochranu soukromí)
  • Obtížná změna biometrických údajů v případě kompromitace

Poloha

  • Není plně akceptováno jako MFA
  • Stále častěji se však používá
  • Často se používá jako rozhodovací faktor, zda MFA vyžadovat nebo ne

Rozsah zdrojových IP adres

  • Založen na statickém (firemní kancelář) nebo dynamickém (předchozí IP adresy přihlášení) seznamu adres

Výhody

  • Jednoduché pro uživatele
  • Minimální konfigurace a administrativa

Nevýhody

  • Neposkytuje ochranu v případě, že je systém uživatele napaden
  • Neposkytuje ochranu proti nepoctivým osobám
  • Důvěryhodné IP adresy musí být pečlivě omezeny
    • Např. pokud otevřená WiFi pro hosty používá hlavní firemní IP rozsah

Geolokace

  • Použití zeměpisné polohy, ke které je IP adresa registrována
  • Méně přesné, ale proveditelnější v prostředí, kde nejsou statické IP
  • Běžným použitím je vyžadování dalších faktorů, pokud je pokus o ověření proveden z jiné země, než je obvyklá země uživatele

Výhody

  • Jednoduché pro uživatele

Nevýhody

  • Neposkytuje ochranu v případě, že je systém uživatele napaden
  • Neposkytuje ochranu proti nepoctivým osobám
  • Snadné získání IP adresy v důvěryhodné zemi nebo lokalitě