Dvoufázové ověřování
Vše, co jste si přečetli o se týkalo identifikace na základě toho, co zná požadující. Zná svou e-mailovou adresu, ví, jak získat k ní přístup (tj. zná své heslo k e-mailu) a zná odpovědi na bezpečnostní otázky.
"Znalost" se považuje za jeden faktor ověřování; dva další běžné faktory jsou to, co máte, například fyzické zařízení, a to, kým jste, například otisky prstů nebo duhovky.
Ve většině případů provedení biometrické identifikace není prakticky realizovatelné, zejména když mluvíme o zabezpečení webových aplikací, proto se při dvoufázovém ověřování (two factor authentication, 2FA) obvykle používá druhý atribut — "to, co máte". Jednou z populárních variant tohoto druhého faktoru je fyzický token, například :
Fyzický token se často používá k autentizaci v podnikových VPN a finančních službách. Pro autentizaci v službě je třeba použít jak heslo, tak kód na tokenu (který se často mění) v kombinaci s PIN. Teoreticky, pro identifikaci útočníka musí znát heslo, mít token a také znát PIN tokenu. V scénáři resetování hesla je samozřejmě heslo neznámé, nicméně mít token lze použít k potvrzení vlastnictví účtu. Jak je samozřejmé, jako u všech realizací zabezpečení, , ale určitě zvyšuje bariéru vstupu.
Jedním z hlavních problémů tohoto přístupu jsou náklady a logistika implementace; hovoříme o distribuci fyzických zařízení každému klientovi a o školení v novém procesu. Kromě toho musí mít uživatelé zařízení u sebe, což v případě fyzického tokenu není vždy možné. Další možností je zavést druhý faktor ověřování prostřednictvím SMS, které v případě 2FA může sloužit jako potvrzení, že osoba provádějící proces resetování má mobilní telefon vlastníka účtu. Takto to dělá Google:
Také je nutné zahrnout , ale to znamená, že při dalším resetování hesla může váš mobilní telefon sloužit jako druhý faktor ověřování. Dovolte mi to démonstrovat na příkladu svého iPhonu z důvodů, které se brzy stanou jasnými:
Po identifikaci e-mailové adresy účtu Google zjistí, že byla zapnuta 2FA, a my můžeme resetovat účet pomocí ověření, které je zasláno prostřednictvím SMS na mobilní telefon majitele účtu:
Nyní potřebujeme vybrat začátek procesu resetování:
Tato akce vede k odeslání e-mailu na registrovanou adresu:
Tento e-mail obsahuje URL pro resetování:
Při přístupu k URL pro resetování se odešle SMS a webová stránka žádá o její zadání:
Toto je SMS:
Po jejím zadání do prohlížeče se vrátíme na území klasického resetování hesla:
Pravděpodobně to vypadá trochu obšírně, a také to je, ale formulář potvrzuje, že osoba provádějící reset má přístup k e-mailové adrese a mobilnímu telefonu majitele účtu. To však může být až devětkrát bezpečnější než reset hesla pouze prostřednictvím e-mailu. Existují však problémy…
Problém je ve smartphonech. Níže uvedené zařízení může ověřit pouze jeden faktor ověřování — dokáže přijímat SMS, ale ne e-maily:
Toto zařízení však může přijímat SMS a přijímat e-maily o resetování hesla:
Problém spočívá v tom, že považujeme e-mail za první faktor ověřování a SMS (nebo dokonce aplikaci generující tokeny) za druhý, ale dnes jsou tyto prvky sloučeny v jednom zařízení. To samozřejmě znamená, že pokud se někdo dostane k vašemu smartphonu, veškeré toto pohodlí se vrátí zpět k jednomu kanálu; tento druhý faktor „to, co máte“ znamená, že máte také první faktor. A to vše je chráněno jedním čtyřmístným PINem… pokud má telefon vůbec nějaký PIN. a byl zablokován.
Ano, implementovaná funkce 2FA od Google rozhodně poskytuje další ochranu, ale není chráněna „před hlupáky“ a rozhodně nezávisí na dvou zcela autonomních kanálech.
Resetování podle uživatelského jména vs. resetování podle e-mailové adresy
Je nutné povolit reset pouze podle e-mailové adresy? Nebo by měl mít uživatel možnost resetovat také podle jména? Problém s resetem pomocí uživatelského jména spočívá v tom, že není žádný způsob, jak upozornit uživatele na chybný uživatelský název, aniž bychom odhalili to, že někdo jiný může mít účet s tímto jménem. V předchozí části poskytoval reset podle e-mailu záruku, že skutečný majitel této e-mailové adresy vždy obdrží zpětnou vazbu bez veřejného odhalení své existence v systému. To je sám o sobě uživatelským jménem nemožné.
Proto je odpověď stručná: pouze e-mailem. Pokud se pokusíte provést reset pouze s pomocí uživatelského jména, dojde k situacím, kdy si uživatel nebude jistý, co se děje, nebo a odhalíte existenci účtů. Ano, je to pouze uživatelské jméno, nikoli e-mailová adresa, a ano, kdokoli si může zvolit jakékoli (dostupné) uživatelské jméno, ale přesto existuje vysoká pravděpodobnost, že nepřímo odhalíte vlastníky účtů kvůli tendenci uživatelů opakovaně používat stejná jména.
Co se tedy stane, když někdo zapomene své uživatelské jméno? Pokud vezmeme v úvahu, že uživatelské jméno není hned e-mailovou adresou (což se často stává), pak je proces podobný tomu, jak začíná reset hesla — zadáme e-mailovou adresu a pak odesíláme zprávu na tuto adresu, aniž bychom odhalovali její existenci. Jediný rozdíl je v tom, že tentokrát zpráva obsahuje pouze uživatelské jméno, nikoli URL pro reset hesla. Buď to, nebo bude v e-mailu uvedeno, že pro tuto adresu neexistuje účet.
Ověření identity a přesnost e-mailových adres
Klíčovým aspektem resetování hesel, a možná i nejdůležitějším aspektem je ověření identity osoby, která se snaží provést reset. Oprávněný majitel účtu, nebo někdo, kdo se ho snaží hacknout nebo způsobit mu nepříjemnosti?
Je zřejmé, že e-mail je nejpohodlnějším a nejrozšířenějším kanálem pro ověřování identity. Není chráněn před nezkušeným používáním ("od blbce"), a existuje mnoho případů, kdy prostě možnost přijímat e-maily na adresu majitele účtu nestačí, pokud je zapotřebí vysoké míry jistoty v identifikaci (proto se také používá 2FA), ale téměř vždy je to výchozí bod procesu resetování.
Pokud bude e-mail hrát roli v zajištění důvěry, je třeba se nejprve ujistit, že e-mailová adresa je skutečně správná. Pokud udělal někdo chybu v symbolu, evidentně resetování nezačne. Proces ověření e-mailu při registraci je spolehlivý způsob, jak potvrdit správnost adresy. Všichni jsme to zažili: registrujete se, dostáváte e-mail s jedinečnou URL, na kterou musíte kliknout, čímž potvrzujete, že jste skutečně vlastníkem této e-mailové adresy. Neschopnost přihlásit se do systému před dokončením tohoto procesu zajišťuje motivaci k potvrzení adresy.
Stejně jako u mnoha jiných aspektů bezpečnosti, tento model snižuje použitelnost výměnou za zajištění vyšší míry bezpečnosti ohledně důvěry v identitu uživatele. To může být přijatelné pro web, jehož registraci si uživatel vysoce cení a rád přidá ještě jeden krok do procesu (placené služby, bankovnictví atd.), ale takové věci mohou uživatele odradit, pokud vnímá účet jako "jednorázový" a používá ho například pouze jako prostředek ke komentování příspěvků.
Identifikace osoby, která iniciovala proces resetování
Je zřejmé, že existují důvody pro zneužití funkce resetování, a útočníci ji mohou využít mnoha různými způsoby. Jeden jednoduchý trik, který můžeme použít na podporu potvrzení zdroje žádosti (tento trik obvykle funguje) — je přidání IP adresy žádajícího do e-mailu s nabídkou resetování. To poskytne příjemci některé informace k identifikaci zdroje žádosti.
Zde je příklad z funkce resetování, kterou právě vkládám do ASafaWeb:
Odkaz „find out more“ („Zjistit více“) přenáší uživatele na webovou stránku , který poskytuje informace, jako je umístění a organizace žadatele o reset:
Samozřejmě, že každý, kdo chce skrýt svoji identitu, má spoustu způsobů, jak zakrýt svou skutečnou IP adresu, nicméně je to pohodlný způsob, jak přidat částečnou identifikaci žadatele, a ve většině případů to poskytne dostatečný přehled o tom, kdo provedl žádost o resetování hesla.
Oznámení o změnách na e-mail
Tento příspěvek je prostoupen jedním tématem — komunikací; informujte vlastníka účtu co nejvíce o tom, co se děje v každém kroku procesu, aniž byste odhalili cokoli, co by mohlo být zneužito. To samé platí i pro situaci, kdy došlo ke změně hesla — informujte o tom vlastníka!
Důvody pro změnu hesla mohou být dva zdroje:
- Změna hesla po přihlášení, protože uživatel chce nové heslo
- Resetování hesla bez přihlášení, protože uživatel zapomněl
Ačkoliv se tento příspěvek převážně zaměřuje na resetování, oznámení v prvním případě snižuje riziko, že někdo změní heslo bez vědomí oprávněného vlastníka. Jak se to může stát? Velmi běžným scénářem je získání hesla oprávněného vlastníka (opětovně použité heslo, uniklé z jiného zdroje; heslo získané keyloggingem; snadno uhodnuté heslo atd.), po čemž útočník rozhodne ho změnit, a tím zablokuje majitele. Bez e-mailového oznámení by skutečný vlastník o změně hesla nevěděl.
Samozřejmě, v případě resetování hesla by si vlastník měl proces již iniciovat sám (nebo obcházet výše uvedené metody ověření identity), takže změna by neměla být pro něj překvapením, nicméně potvrzení e-mailem bude pozitivní zpětná vazba a dodatečné ověření. Kromě toho to zajišťuje jednotnost s výše uvedeným scénářem.
A, pro případ, že by to ještě nebylo jasné — neodesílejte nové heslo e-mailem! Někoho to může rozesmát, ale :
Logy, logy, logy a ještě více logů
Funkce resetování hesla je lákavá pro útočníky: útočník se snaží získat přístup k účtu jiné osoby nebo pouze způsobit potíže majiteli účtu/systému. Mnohé z výše popsaných praktik pomáhají snížit pravděpodobnost zneužití, ale nezabrání jim, a rozhodně neochrání před lidmi, kteří se pokusí využít funkci nezamýšleným způsobem.
Pro rozpoznání zlomyseľného chování je naprosto neocenitelnou praxí logování, a mám na mysli velmi podrobné logování. Zaznamenávejte neúspěšné pokusy o přihlášení, resetování hesel, změny hesel (tj. když je uživatel již přihlášen) a prakticky vše, co vám může pomoci pochopit, co se děje; to se vám v budoucnosti velmi hodí. Zaznamenávejte v logách i jednotlivé části procesu, například dobrá funkce resetování by měla zahrnovat iniciaci resetování přes webovou stránku (zaznamenávejte žádosti a pokusy o přihlášení pro resetování s nesprávným uživatelským jménem nebo e-mailem), zaznamenávejte návštěvu webové stránky pomocí URL resetování (včetně pokusů o použití neplatného tokenu), a poté zaznamenávejte úspěšnost nebo selhání odpovědi na tajnou otázku.
Když mluvím o logování, nemyslím tím jen zaznamenávání faktu načtení stránky, ale i sběr co nejvíce informací, pokud nejsou důvěrné. Kluci, prosím, nezaznamenávejte hesla do logů! V logách je třeba registrovat totožnost oprávněného uživatele (bude oprávněn, pokud mění existující heslo nebo se pokouší resetovat cizí heslo po přihlášení do systému), jakákoliv zkoušená uživatelská jména či e-mailové adresy, plus jakékoliv tokeny resetování, které se pokouší použít. Ale také byste měli zaznamenávat aspekty jako IP adresy a pokud to je možné, dokonce i hlavičky požadavků. To vám umožní rekonstrukci nejen co uživatel (nebo útočník) se snaží udělat, ale také kdo kdo je.
Delegování odpovědnosti na jiné dodavatele.
Pokud máte pocit, že to všechno představuje obrovské množství práce, nejste sami. Ve skutečnosti je vybudování spolehlivého systému pro správu účtů složitý úkol. Není to jen technicky obtížné, ale obsahuje také mnoho specifik. Nejde jen o resetování, existuje celý proces registrace, bezpečné uchovávání hesel, zpracování více neúspěšných pokusů o přihlášení atd. ale kromě toho je potřeba udělat ještě mnoho.
Dnes existuje mnoho externích poskytovatelů, kteří se ochotně ujímají všech těchto starostí a abstrahují vše do jedné spravované služby. Mezi takové služby patří OpenID, OAuth a dokonce i Facebook. Někteří lidé (OpenID se skutečně osvědčilo na Stack Overflow), zatímco jiní .
Není pochyb o tom, že služba jako OpenID řeší mnoho problémů vývojářů, zároveň však nepochybně přidává nové. Mají nějakou roli? Ano, ale je zřejmé, že nezažíváme masové využívání služeb poskytovatelů autentifikace. Banky, letecké společnosti a dokonce i obchody – všichni implementují své vlastní mechanismy autentifikace a je jasné, že pro to existují velmi závažné důvody.
Malicious reset
Důležitým aspektem každého z výše uvedených příkladů je, že staré heslo je považováno za neplatné až po ověření identity držitele účtu.Je to důležité, protože kdyby bylo možné resetovat účet do bez ověření identity, umožnilo by to širokou škálu zlovolných činů.
Příklad: někdo se účastní aukce na webu a blíže ke konci procesu ve vyvolávací nabídce zablokuje konkurenty tím, že zahájí proces resetování, a tím je vyloučí z aukce. Je zřejmé, že pokud by byla funkce resetování špatně navržena a mohla být zneužita, mohlo by to vést k vážným negativním následkům. Je také třeba poznamenat, že blokace účtů pomocí neúspěšných přihlášení představuje podobnou situaci, ale to je už téma pro jiný příspěvek.
Jak jsem již řekl, pokud dáte anonymním uživatelům možnost resetovat heslo jakéhokoli účtu pouze na základě jeho e-mailové adresy, je to situace připravená pro útok typu "útok na odmítnutí služby". Možná to není ten, o kterém jsme zvyklí mluvit, ale neexistuje rychlejší způsob, jak zablokovat přístup k účtu, než pomocí špatně navržené funkce pro resetování hesla. , o kterém jsme zvyklí mluvit, ale neexistuje rychlejší způsob, jak zablokovat přístup k účtu, než pomocí špatně navržené funkce resetování hesla.
Nejslabší článek
Z pohledu ochrany jednoho účtu je vše výše uvedené skvělé, ale vždy si musíte pamatovat ekosystém, který obklopuje váš chráněný účet. Dovolte mi uvést příklad:
ASafaWeb je hostován na úžasné službě poskytované AppHarbor. Proces resetování účtu hostingu probíhá takto:
Krok 1:
Krok 2:
Krok 3:
Krok 4:
Po přečtení všech předchozích informací je již snadné pochopit, jaké aspekty bychom v ideálním světě realizovali trochu jinak. Nicméně zde chci říct, že pokud zveřejním web jako ASafaWeb na službě AppHarbor a poté vymyslím skvělé tajné otázky a odpovědi, přidám druhý faktor autentizace a udělám všechno ostatní podle pravidel, neznamená to, že nejslabší článek celého procesu nebude schopen to všechno zničit. Pokud se někdo úspěšně autentizuje na AppHarbor a použije mé informace, bude moci změnit heslo jakéhokoli účtu ASafaWeb na požadované!
Smyslem je, že odolnost implementace ochrany by se měla posuzovat celkově: je třeba modelovat hrozby každého vstupního bodu systému, i když jde o povrchní proces, například přihlášení do AppHarbor. To by mi mělo poskytnout dobrý přehled o tom, kolik úsilí musím vložit do procesu resetování hesla ASafaWeb.
Spojujeme vše dohromady
Tento příspěvek obsahuje velké množství informací, takže ho chci shrnout do jednoduché vizuální schémy:
Pamatujte, že byste měli provádět co nejpodrobnější logování každého z těchto bodů. A to je vše, je to jednoduché!
Závěry
Můj příspěvek se zdá být komplexní, nicméně existuje spousta dalších materiálů, které bych mohl zahrnout, ale rozhodl jsem se to vynechat kvůli stručnosti: role adresy záchranného e-mailu, situace, kdy ztrácíte přístup k e-mailu přidruženému k účtu (například když vás vyhodí z práce) atd. Jak jsem již řekl, funkce resetování není příliš složitá, ale existuje mnoho názorů na ni.
I když resetování není tak složité, často je implementováno nesprávně. Viděli jsme pár příkladů, kdy implementace může vedla k problémům, a existuje mnohem více precedensů, kdy nesprávný reset opravdu způsobil problémy. Nedávno se ukázalo, že To je vážný negativní výsledek!
Buďte proto opatrní se svými funkcemi resetování, na různých úrovních a při navrhování funkce si nechávejte černý klobouk, protože je velmi pravděpodobné, že si ho někdo jiný také nasadí!
Na základě reklamy
VDSina nabízí cenově dostupné s denní platbou, každý server je připojen k internetovému kanálu o rychlosti 500 megabitů a zdarma chráněn proti DDoS útokům!
Zdroj: habr.com
