Přeskočit na hlavní obsah

Co je to MFA, jak hacknout OAuth a další

Víte, co je to MFA (multifactor authentication) nebo 2FA? Přečtěte si nejčastější dotazy ohledně 2FA. Pojďte zjistit, jak hacknout OAuth 2.0.

🏆 Téma: Multifactor authentication (MFA / 2FA)

  • Přihlašování pomocí hesla je známé jako jeden faktor - jediné, co potřebuje k přihlášení znát / mít, je heslo.
  • Tento způsob přihlašování je však považován za nedostatečný.
  • Nejčastějším ohrožením uživatelských účtů jsou právě slabá, opakovaně používaná nebo ukradená hesla.
  • Pokud vyvíjíme nějakou aplikaci, měla by podporovat multifaktorové přihlašování, abychom zajistili dostatečnou bezpečnost.
    • V opačném případě můžeme předpokládat, že hesla uživatelů budou někdy prozrazena / ukradena.
  • Při MFA přihlašování je uživatel povinen zadat víc než jeden faktor, aby se mohl přihlásit.
  • Existují 4 typy faktorů:
    • Co známe = heslo, PIN, bezpečnostní otázka.
    • Co vlastníme = HW / SW token, certifikát, e-mail, SMS, volání.
    • Kdo jsme = otisk prstů, sken rohovky, rozpoznávání obličeje.
    • Kde jsme = poloha, rozsah zdrojových IP adres, geolokace.
  • Přidáním dalšího faktoru do procesu přihlášení přidáváme další komplexitu a ztěžujeme hackerovi získat identitu uživatele.
  • MFA je nejlepší obranou proti útokům souvisejícím s hesly, jako je brute force, credential stuffing, password spraying atd.

Kdy MFA vyžadovat?​

  • Vyžadujte MFA nejen na webu, ale i při přihlašování přes API.
  • Kromě přihlašování vyžadujte MFA i při provádění citlivých operací a akcí:
    • změna hesla nebo bezpečnostních otázek,
    • změna e-mailové adresy,
    • zakázání MFA,
    • přepnutí účtu z uživatelského do administrátorského,
    • atd.

Jak na reset MFA?​

  • Pozor na to, aby reset mechanismus neumožňoval útočníkovi zmocnit se uživatelského účtu.
  • Implementaci mechanismu vždy posuzujte podle 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.

FAQ​

  • Stačí k heslu přidat bezpečnostní otázky?
    • Obecně ne. Heslo a bezpečnostní otázka je stejný faktor (něco, co známe) a bezpečnostní otázky jsou považovány za slabší než hesla. Odpovědi jsou často předvídatelné a snadno zjistitelné.
  • Mám použít SMS kódy nebo implementovat aplikace jako je Google authenticator?
    • Pokud to jde, SMS nepoužívejte, protože jde o nešifrovaný kanál. Podporujte v aplikaci TOTP (Time-based One Time Password), které vyžadují aplikace jako je Google authenticator. Z uživatelského hlediska je dobrá aplikace Authy, která má lepší zabezpečení a TOTP je šifrovaný.
  • Co passwordless login?
    • Obecně aplikace bez hesel je dobrá aplikace. Osobně se rád přihlašuju pomocí Facebooku, Googlu nebo jiných providerů. Přihlášení pomocí kliknutí na odkaz v e-mailu taky nemusí být špatná volba, vyžaduje to ale bezchybnou implementaci. Zvažte tedy nějakou formu FIDO přihlášení.
    • Passwordless login ale nevylučuje přidání dalšího faktoru do přihlašovacího procesu. Záleží na tom, jak riziková vaše aplikace je. Jak jsem psal na začátku, MFA je v dnešní době standard, nebo by aplikace měla alespoň nabízet možnost si MFA zapnout.
  • Co když moji uživatelé neumí TOTP aplikace používat?
    • Při zavádění bezpečnostních opatření děláme kompromis mezi bezpečnostní a použitelností aplikace. Zajistěte tedy tak bezpečné přihlášení, aby to zvládli vaši uživatelé. Nicméně berte v potaz rizikový profil vaší aplikace.

🎓 Učíme se společně

Co jsem se dozvěděl z přednášek, školení, čtení knih a dalších aktivit?

Hacking OAuth 2.0​

  • Speaker: Philippe De Ryck
  • XSS je stále velký problém i v dnešní době React aplikací.
  • OAuth je způsob přihlášení uživatele, o kterém jsem psal v jednom z předešlých newsletterů.
  • Řešíme situaci, kdy a za jakých podmínek může dojít k odcizení OAuth tokenu, pomocí kterého se uživatel autorizuje - to se může stát vlivem XSS.
  • Tokeny jsou uložené někde v prohlížeči - local storage nebo session storage - toto úložiště si útočník pomocí XSS přečte a obsah si pošle na svůj server.
  • Řešení není použití short-lived access tokenu, protože stále existuje long-lived refresh token.
  • Live hacking refresh token rotation mechanismu - ani refresh token rotation mechanismus nás nezachrání.
  • Nepomůže nám ani schování tokenu do workeru atp., protože OAuth knihovny podporují tiché přihlášení v případě, že má uživatel vytvořenou session s autorizačním serverem (tím dostane nové tokeny) - live demo.
  • Neexistuje způsob, jak tento typ útoku zastavit z frontend pohledu.
  • Řešením je přidání backend komponenty, která zmírní zodpovědnost frontendu za OAuth (komponenta se stane “klientskou” OAuth aplikací).
    • Frontend aplikace už nemá přístup k tokenům, žádné tu nejsou, o všechno se stará backend komponenta.
    • Backend komponenta je jen taková proxy, neobsahuje žádnou byznys logiku, jde o jednoduchou službu.
  • Implementace:
    • Odstranit OAuth z frontend aplikace.
    • Přidat backend komponentu, která bude zajišťovat OAuth, proxovat požadavky frontendu a cookies bude nahrazovat tokenem.
    • API a autorizační server se nemění.

📰 Co je nového

  1. Před pár týdny proběhlo brněnské setkání CyberSecurityPlatform. Součástí byla i přednáška o SSDLC, kterou si můžete poslechnout na YouTube.
  2. Na webu Bezpečný kód najdete nově vyhledávač, který by vám měl zpříjemnit vyhledávání informací na webu a tím zefektivnit a zrychlit vaši práci.

😂 Závěrečný ftípek: What's a secret agent's go-to fashion? Spyware.