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
  • MFA je nejlepší obranou proti útokům souvisejícími s hesly (brute force, credential stuffing, password spraying)

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ě