Přeskočit na hlavní obsah

Autentizace

  • Autentizace = proces ověřování, zda je subjekt (osoba) tím, za koho se vydává
  • Běžně se provádí zadáním uživatelského jména a jedné, nebo více soukromých informací, které by měl znát pouze daný subjekt
  • Session management = proces, při kterém server udržuje stav entity, která s ním komunikuje
    • Nutné k zapamatování, jak reagovat na jednotlivé požadavky
  • Session je na serveru udržována pomocí session ID, které může být předáváno mezi klientem a serverem během požadavků a odpovědí
  • Sessions by měly být pro každého uživatele jedinečné a nepředvídatelné

Autentizace obecně​

Uživatelská ID​

  1. Ujistěte se, že uživatelská jména / identifikátory nerozlišují velká a malá písmena
    • Uživatel “jan” a “Jan” by měl být jeden a ten samý
  2. Zajistěte jedinečnost uživatelských jmen
  3. Utajte uživatelská jména u aplikací s vysokým stupněm zabezpečení

Implementace autentizace a citlivých účtů​

  1. Nepovolujte přihlašování pomocí citlivých účtů (tj. účtů, které mohou být použity interně v rámci systému, např. k backendu, middleware, databázi)
  2. Nepoužívejte stejné autentizační řešení (IDP, AD), které se interně používá pro nezabezpečený přístup (veřejný přístup, DMZ)

Implementujte kontrolu síly hesel​

  • Politika síly hesel ztěžuje nebo dokonce znemožňuje uhodnutí hesla - manuálně i automatizovaně
  1. Vynuťte minimální délku hesla
  2. Nenastavujte maximální délku hesla příliš nízko, aby uživatelům nebránila v jejich vytváření
    1. Nastavte maximální délku hesla tak, aby se zabránilo DoS útoku zadáním příliš dlouhého hesla
    • Běžná maximální délka je 64 znaků, kvůli omezením některých hashovacích algoritmů
    • Více informací o správě hesel najdete v cheat sheetu
  3. Nezkracujte hesla (pokud pracujete s heslem delším než maximální délka, podívejte se do cheat sheetu)
  4. Povolte použití všech znaků včetně unicode a bílých znaků
  5. Neomezujte a nezavádějte pravidla pro znaky, ze kterých je heslo složeno
  6. Zajistěte rotaci credentials v případě úniku hesla nebo v okamžiku kompromitace
  7. Implementujte měřič síly hesla, který uživatelům pomůže heslo vytvořit a zablokovat běžná a dříve povolená hesla

Implementujte bezpečný postup pro obnovu hesla​

  1. Umožněte uživateli obnovit si heslo v případě, že ho zapomene

Ukládejte hesla bezpečně​

  1. Ukládejte hesla pomocí správné kryptografické techniky

Používejte bezpečené hashovací funkce​

  1. Porovnávejte uživatelská hesla pomocí bezpečné hashovací funkce (např. PHP [password_verify()](https://www.php.net/manual/en/function.password-verify.php))
  2. Pokud to není možné, zajistěte
    1. maximální délku vstupu, aby byla služba chráněna před DoS útoky
    2. explicitní nastavení typu proměnných, aby byla služba chráněna proti útokům na záměnu typu (např. Magic Hashes v PHP)
    3. vrácení v konstantním čase, aby byla služba chráněná proti timing útokům

Funkce pro změnu hesla​

  1. Ověřte, že je uživatel přihlášen a má platnou session
  2. Ověřte aktuální heslo - zajistíte tím, že heslo mění oprávněný uživatel
    • Legitimní uživatel používá veřejný počítač a zapomene se odhlásit
    • Počítač po chvíli použije někdo jiný (předchozí uživatel je stále přihlášený), ale není schopen změnit heslo, protože nezná to původní

Hesla přenášejte pouze prostřednictvím TLS​

  1. Zpřístupněte přihlašovací stránku a stránky po přihlášení pouze prostřednictvím TLS protokolu
    • Nepoužití TLS umožňuje útočníkovi upravit akci přihlašovacího formuláře a způsobit odeslání přihlašovacích údajů uživatele na libovolné místo
    • Nepoužití TLS na stránkách po přihlášení umožňuje útočníkovi zobrazení session ID, čímž je ohrožena session uživatele

Zvažte silnou transakční autentizaci a autorizaci​

  1. Použijte dvoufaktorové ověření, pokud uživatel přistupuje k citlivým datům nebo operacím

TLS client authentication

  • Spočívá v tom, že prohlížeč i server během TLS handshake odesílají své TLS certifikáty
  • Stejně jako lze ověřit pravost serveru pomocí certifikátu, je možné ověřit i pravost klienta
  • Server musí poskytnout uživateli certifikát vygenerovaný speciálně pro něj a přiřadit příslušné hodnoty, aby bylo možné určit, jakého uživatele má certifikát ověřit
  • Vhodné použít, když
    • je žádoucí, aby měl uživatel přístup na web pouze z jednoho počítače / prohlížeče
    • je uživatel technicky zdatnější (nevyděsí se instalace certifikátu do prohlížeče), případně je k dispozici IT podpora, která to za uživatele udělá
    • web vyžaduje další zabezpečení
    • se jedná o intranetové stránky organizace
  1. Nepoužívejte tuto metodu pro široce a veřejně dostupné stránky
    • Není dobrý nápad tuto metodu používat pro aplikace typu Facebook
    • Vyhnete se sice zadávání hesla, ale vždy tuto variantu zvažte
  • Pokud je klient za proxy serverem, který provádí SSL/TLS dešifrování, dojde k přerušení ověřování certifikátu, pokud není web na proxy serveru povolen

Přihlašování a error zprávy​

Odpověď na autentizaci

  1. Reagujte obecnou chybovou zprávou při přihlášení, resetu a obnovení hesla bez ohledu na to, zda
    • uživatelské jméno nebo heslo není správné
    • účet neexistuje
    • je účet zablokován
  2. Použijte stejný proces také u registrace pokud uživatel existuje
  • Cílem je zabránit útočníkovi v provedení enumerace uživatelů
  • Byznys logika v enumeraci také napomáhá tím, že je např. příliš pomalá, což útočníkovi naznačuje, že se “něco děje” a může tak provést útok, který je založený na čase
  • Příklad pseudo kódu pro login funkcionalitu:
IF USER_EXISTS(username) THEN
    password_hash=HASH(password)
    IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
    IF NOT IS_VALID THEN
        RETURN Error("Invalid Username or Password!")
    ENDIF
ELSE
   RETURN Error("Invalid Username or Password!")
ENDIF
  • Pokud uživatel neexistuje, aplikace rovnou vyhodí chybu
  • Pokud uživatel existuje, ale heslo je špatné, dojde k další chybě
    • Tím je doba odezvy odlišná, což útočníkovi umožňuje rozlišit špatné uživatelské jméno a heslo
password_hash=HASH(password)
IS_VALID=LOOKUP_CREDENTIALS_IN_STORE(username, password_hash)
IF NOT IS_VALID THEN
   RETURN Error("Invalid Username or Password!")
ENDIF
  • Tento kód umožňuje vrátit chybu přibližně ve stejný čas
  • Problém s vrácením obecné chyby je záležitostí UX
    • Uživatel by se mohl generickými zprávami cítit zmateně a ztížilo by mu to používání aplikace
    • Rozhodnutí o vrácení generických chyb by mělo být určeno na základě kritičnosti aplikace a dat
  • V enumeraci uživatelů může být účinná CAPTCHA, protože brání enumeraci ve velkém měřítku
    • Lze ji použít tam, kde nelze vrátit obecnou chybu kvůli zachování uživatelského komfortu

Přihlášení - příklad špatných hlášek

  • Přihlášení uživatele Foo se nezdařilo: špatné heslo
  • Přihlášení se nezdařilo: špatné uživatelské jméno
  • Přihlášení se nezdařilo: tento účet je zablokován
  • Přihlášení se nezdařilo: tento účet není aktivní

Přihlášení - příklad správných hlášek

  • Přihlášení se nezdařilo: špatné uživatelské jméno nebo heslo

Obnova hesla - příklad špatných hlášek

  • Poslali jsme vám odkaz pro obnovu vašeho hesla
  • Tento email v naší databázi neexistuje

Obnova hesla - příklad správných hlášek

  • Pokud je tato adresa v naší databázi, zašleme vám email s odkazem pro obnovu hesla

Vytvoření účtu - příklad špatných hlášek

  • Toto uživatelské jméno je již používané
  • Vítejte! Příhlášení proběhlo úspěšně

Vytvoření účtu - příklad správných hlášek

  • Na zadanou emailovou adresu vám byl zaslán odkaz pro aktivaci účtu

Chybové kódy a URL

  • Aplikace může vrátit jiný HTTP kód v závislosti na odpovědi k pokusu o přihlášení
  • V případě úspěchu může odpovědět 200 a v případě neúspěchu 403
  • I když se zobrazí obecná chybová stránka, chybový kód se může lišit, což může vést k úniku informací o tom, zda je účet platný, nebo ne
  • Přečtěte si cheat sheet o zpracování chyb

Chraňte se proti automatizovaným útokům​

Brute forceTestování více hesel ze slovníku nebo jiného zdroje proti jednomu účtu
Credential stuffingTestování dvojic uživatelských jmen - heslo získaných z narušení jiného webu
Password sprayingTestování jednoho slabého hesla na velkém počtu různých účtů
  • Na ochranu před těmito útoky je možné implementovat různé ochranné mechanismy
  • V mnoha případech však neposkytují úplnou ochranu
  • Při implementaci několika mechanismů najednou (in-depth přístup) se dosáhne přiměřené úrovně ochrany

Multifaktorová autentizace

  • MFA je nejlepší obranou proti většině útoků souvisejících s hesly
  • Měla by být zavedena všude, kde je to možné
  • V závislosti na cílové skupině nebo povaze aplikace však nemusí být praktická
  • Více informací najdete v MFA cheat sheetu

Zablokování účtu

  • Po určitém počtu neúspěšných pokusů o přihlášení se účet na nějakou dobu zablokuje a znemožňuje další pokusy o přihlášení
  • Počítadlo s neúspěšnými pokusy by mělo být spojeno s konkrétním účtem (nikoli s IP adresou atd.)
  1. Zvažte různé faktory, aby bylo možné najít rovnováhu mezi bezpečností a použitelností
    1. Počet neúspěšných pokusů před zablokováním účtu
    2. Časový úsek, ve kterém musí k těmto pokusům dojít
    3. Na jak dlouho je účet zablokován
  2. Zvažte použití exponenciálního zablokování namísto pevně stanovené doby zablokování (např. 10 minut)
    • Doba zablokování začíná jako krátká, ale po každém neúspěšném pokusu o přihlášení se zdvojnásobí
  3. Dbejte na to, aby útočník nezneužil DoS zablokováním účtů jiných uživatelů
    • Jedním ze způsobů je umožnit uživateli změnit si heslo (funkce zapomenutého hesla), i když je účet zablokován

CAPTCHA

  • Slabinou CAPTCHA je možnost jejího vyřešení pomocí automatizovaných technik
  1. Pohlížejte na CAPTCHU jako na jednu z možností in-depth obrany než jako na prevenci brute force útoků
  2. Vyžadujte CAPTCHU až po několika neúspěšných pokusech o přihlášení (uživatelsky přívětivější)

Bezpečnostní otázky a zapamatovatelná slova

  • Tato technika není považována za MFA, protože jde o stejný faktor jako heslo (něco, co uživatel zná)
  • Bezpečnostní otázky jsou často slabé a mají předvídatelné odpovědi, takže je potřeba je pečlivě vybírat

Logování a monitoring​

  • Umožňuje odhalení útoků v reálném čase
  1. Zalogujte a zkontrolujte všechny chyby
  2. Zalogujte a zkontrolujte všechna selhání spojená se zadáním hesla
  3. Zalogujte a zkontrolujte všechny blokace účtů

Používejte autentizační protokoly, které nevyžadují heslo​

  • Ověřování pomocí uživatelského jména a hesla a MFA je sice považováno za bezpečné, ale v některých případech není považováno za nejlepší nebo dokonce bezpečné
  • Příkladem může být propojení aplikací třetích stran, které se chtějí připojit k webové aplikaci
  • V takovém případě není považováno za bezpečné umožnit přihlašování pomocí uživatelského jména a hesla, protože se rozšiřuje plocha pro útok, kterou nemáme pod kontrolou

OAuth​

  • Protokol umožňující aplikaci ověření vůči serveru bez vyžadování hesla
  • Používá token vygenerovaný serverem a poskytuje způsob, jakým probíhají autorizační toky - klient tak může serveru sdělit, jaký uživatel službu používá atd.
  1. Používejte verze OAuth 1.0a nebo OAuth 2.0
    • OAuth 2.0 se spoléhá na HTTPS a pro své API služby ho využívá např. Facebook, Google nebo Twitter
    • Použití OAuth 1.0a vyžaduje použití kryptografických knihoven pro digitální podpisy
    • OAuth 1.0a nespoléhá na HTTPS, takže může být výhodnější pro transakce s vyšším rizikem

OpenId​

  • Protokol založený na HTTP, který využívá poskytovatele identit k ověření toho, že uživatel je tím, za koho se vydává
  • Jednoduchý protokol umožňující způsob jednotného přihlášení (SSO)
  • Uživatel může opakovaně používat jednu identitu na více webových stránkách, aniž by musel poskytovateli dávat jakékoli heslo
  • Díky jednoduchosti a ochraně hesel se dobře ujal
  • Mezi známé poskytovatele identit patří např. Google nebo Facebook
  • Pro nepodniková prostředí je OpenId považován za bezpečnou a často lepší volbu, pokud je poskytovatel identit důvěryhodný

SAML​

  • Sucurity Assertion Markup Language
  • Často považován za konkurenci OpenId
  • Nejvíce doporučovaná verze je 2.0, protože je funkčně úplná a poskytuje silné zabezpečení
  • Stejně jako OpenId používá poskytovatele identit
  • Je založen na XML, což poskytuje větší flexibilitu
  • Je založen na přesměrování prohlížeče
  • SAML není iniciován pouze poskytovatelem služeb, ale také poskytovatelem identit
  • To umožňuje uživateli procházet různými portály a přitom se nechat ověřit, aniž by musel cokoliv dělat
  • Proces je velmi transparentní
  • SAML je často volbou pro podnikové aplikace
  • Důvodem je, že existuje velmi málo OpenId poskytovatelů identit, kteří jsou považováni za poskytovatele podnikové třídy
    • Způsob, jakým ověřují identity, nesplňuje vysoké standardy pro podnikové identity
  • Často se používá uvnitř intranetových webů, někdy dokonce s využitím serveru z intranetu jako poksytovatelem identity
  • V posledních letech se aplikace jako SAP ERP a SharePoint rozhodly používat SAML 2.0 jako preferovanou metodu pro implementaci jednotného přihlášení

FIDO​

  • Dva protokoly pro usnadnění online ověřování
    • UAF = Universal Authentication Framework
    • U2F = Universal Second Factor
  • UAF se zaměřuje na ověřování bez hesla
  • U2F umožňuje přidat druhý faktor ke stávajícímu ověřování založeném na heslu
  • Oba protokoly jsou založeny na kryptografickém modelu challenge-response
  • UAF využívá stávající bezpečnostní technologie, které jsou v zařízeních k ověřování k dispozici - snímače otisků prstů, kamer (biometri obličeje), TEE
  • Protokol je navržen tak, aby tyto schopnosti zařízení zapojil do procesu ověřování
  • UAF funguje s nativními i webovými aplikacemi
  • U2F rozlišuje ověřování založené na heslu pomocí hardwarového tokenu (obvykle USB), který uchovává kryptografické klíče, které používá k podepisování
  • Stejný token může uživatel použít jako druhý faktor pro více aplikací
  • U2F funguje s webovými aplikacemi
  • Poskytuje ochranu proti phishingu tím, že k vyhledávání uloženého ověřovacího klíče využívá URL webové stránky

Správci hesel​

  • Programy, pluginy nebo webové služby, které automatizují správu velkého počtu credentials
  • Většina správců hesel má funkce, které umožňují uživatelům snadno je používat na webových stránkách
    • Vložením hesel do přihlašovacího formuláře
    • Simulací jejich zadání uživatelem
  1. Neztěžujte správcům hesel práci více, než je nutné
  2. Použijte standardní HTML formuláře pro zadávání uživatelského jména a hesla s příslušnými type atributy
    1. Vyhněte se přihlašovacím stránkám založených na pluginech (např. Flash nebo Silverlight)
  3. Implementujte přiměřenou maximální délku hesla (např. 64 znaků), jako je popsáno v cheat sheetu o práci s hesly
  4. Povolte použití libolných tisknutelných znaků v heslech
  5. Umožněte uživatelům vkládat uživatelská jména a hesla do polí (CTRL+V)
  6. Umožněte uživatelům přecházet mezi poli stistknutím klávesy Tab

Kam dál​

Cheat sheety​

Checklisty​

Další​