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.
Poskytněte uživateli několik jednorázových kódů pro obnovení MFA při prvním nastavení.
Požadujte, aby si uživatel nastavil více MFA (digitální certifikát + telefonní číslo).
Umožněte zaslání jednorázového kódu pro obnovení.
Požadujte, aby uživatel kontaktoval podporu a ověřil svou totožnost.
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
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.
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.