Dvoufaktorová autentizace
Vše, co čtete identifikace na základě toho žadatel ví. Zná svou e-mailovou adresu, ví, jak se k ní dostat (tj. zná své e-mailové heslo) a zná odpovědi na své bezpečnostní otázky.
"Znalosti" jsou považovány za jeden autentizační faktor; jsou další dva společné faktory to, co máte, jako je fyzické zařízení a kdo jsi, například otisky prstů nebo sítnice.
Ve většině případů není provedení biologické identifikace proveditelné, zvláště pokud mluvíme o zabezpečení webových aplikací, proto dvoufaktorová autentizace (2FA) obvykle používá druhý atribut – „co máte“. Jednou z oblíbených variant tohoto druhého faktoru je fyzický token, např. :
Fyzický token se často používá k ověřování v podnikových sítích VPN a finančních službách. Pro autentizaci se službou je potřeba použít heslo i kód na tokenu (který se často mění) v kombinaci s PIN. Teoreticky pro identifikaci musí útočník znát heslo, mít token a také znát PIN tokenu. Ve scénáři resetování hesla je samotné heslo samozřejmě neznámé, ale vlastnictví tokenu lze použít k prokázání vlastnictví účtu. Samozřejmě, jako u každé bezpečnostní implementace, , ale rozhodně zvyšuje bariéru vstupu.
Jedním z hlavních problémů tohoto přístupu jsou náklady a logistika implementace; mluvíme o předání fyzických zařízení každému zákazníkovi a jeho naučení novému procesu. Uživatelé navíc potřebují mít zařízení u sebe, což u fyzického tokenu vždy neplatí. Další možností je implementace druhého faktoru autentizace pomocí SMS, která v případě 2FA může sloužit jako potvrzení, že osoba provádějící proces resetování má mobilní telefon majitele účtu. Google to dělá takto:
Musíte také povolit , ale to znamená, že při příštím resetování hesla se váš mobilní telefon může stát druhým ověřovacím faktorem. Dovolte mi demonstrovat to pomocí mého iPhone z důvodů, které budou brzy jasné:
Po identifikaci e-mailové adresy účtu Google určí, že 2FA byla povolena, a můžeme účet resetovat pomocí ověření, které je zasláno prostřednictvím SMS na mobilní telefon vlastníka účtu:
Nyní musíme zvolit zahájení procesu resetování:
Tato akce způsobí odeslání e-mailu na registrovanou adresu:
Tento e-mail obsahuje adresu URL pro resetování:
Když přistoupíte na resetovací adresu URL, odešle se SMS a web vás požádá o její zadání:
Toto je SMS:
Po zadání do prohlížeče jsme zpět v klasické oblasti pro resetování hesla:
Pravděpodobně se to zdá trochu zdlouhavé a je to tak, ale formulář potvrzuje, že osoba provádějící reset má přístup k e-mailové adrese a mobilnímu telefonu vlastníka účtu. Ale může to být devětkrát bezpečnější než resetování hesla pouze prostřednictvím e-mailu. Existují však problémy...
Problém se týká smartphonů. Níže zobrazené zařízení se může autentizovat pouze jedním faktorem autentizace – dokáže přijímat SMS, ale ne e-maily:
Toto zařízení však může přijímat SMS и přijímat e-maily pro obnovení hesla:
Problém je v tom, že e-mail vnímáme jako první faktor autentizace a SMS (nebo dokonce aplikaci generující token) jako druhý, ale dnes jsou spojeny do jednoho zařízení. To samozřejmě znamená, že pokud se někomu dostane do rukou váš smartphone, celá tato vymoženost se zredukuje na to, že jsme zase zpátky na jednom kanálu; tento druhý faktor „toto, že 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 telefon vůbec PIN má и byl zablokován.
Ano, funkce 2FA implementovaná Googlem jistě poskytuje další ochranu, ale není spolehlivá a rozhodně nezávisí na dvou zcela autonomních kanálech.
Resetovat podle uživatelského jména vs. Resetovat podle e-mailové adresy
Mám povolit resetování pouze pomocí e-mailové adresy? Nebo by měl mít uživatel možnost resetovat i podle jména? Problém s resetováním podle uživatelského jména je v tom, že neexistuje způsob, jak upozornit uživatele, že uživatelské jméno je nesprávné. bez odhalení že někdo jiný může mít účet s tímto jménem. V předchozí části resetování e-mailu zajistilo, že právoplatný vlastník tohoto e-mailu vždy obdrží zpětnou vazbu, aniž by veřejně odhalil jeho existenci v systému. To nelze provést pouze pomocí uživatelského jména.
Odpověď je tedy krátká: pouze e-mail. Pokud se pokusíte resetovat pouze pomocí uživatelského jména, nastanou případy, kdy se uživatel bude divit, co se stalo, nebo prozradíte existenci účtů. Ano, je to pouze uživatelské jméno, nikoli e-mailová adresa, a ano, každý si může vybrat libovolné (dostupné) uživatelské jméno, ale stále existuje velká šance, že nepřímo odhalíte vlastníky účtu kvůli tendenci uživatelů znovu používat jméno.
Co se tedy stane, když někdo zapomene své uživatelské jméno? Za předpokladu, že uživatelské jméno není okamžitě e-mailová adresa (což je často případ), je proces podobný tomu, jak začíná resetování hesla – zadáním e-mailové adresy a odesláním zprávy na tuto adresu, aniž by byla odhalena její existence. Jediný rozdíl je v tom, že tentokrát zpráva obsahuje pouze uživatelské jméno a nikoli adresu URL pro resetování hesla. Buď to, nebo e-mail bude říkat, že pro tuto adresu neexistuje žádný účet.
Ověření identity a přesnost e-mailové adresy
Klíčový aspekt resetování hesla, a možná dokonce nejvíce klíčovým aspektem je ověření identity osoby pokoušející se o reset. Je to skutečně legitimní vlastník účtu, nebo se ho někdo snaží hacknout nebo obtěžovat majitele?
E-mail je samozřejmě nejpohodlnější a nejběžnější kanál pro ověření identity. Není spolehlivá a existuje mnoho případů, kdy pouhá možnost přijímat e-maily na adresu majitele účtu nestačí, pokud je vyžadována vysoká míra důvěry v identifikaci (proto se používá 2FA), ale téměř vždy je proces resetování výchozího bodu.
Pokud e-mail bude hrát roli při poskytování záruky, prvním krokem je zajistit, aby e-mailová adresa byla ve skutečnosti správná. Pokud někdo udělal špatný symbol, pak se reset samozřejmě nespustí. Proces ověření e-mailu v době registrace je spolehlivý způsob, jak ověřit správnost adresy. Všichni jsme to viděli v praxi: zaregistrujete se, pošlou vám e-mail s unikátní adresou URL, na kterou kliknete, což potvrzuje, že jste ve skutečnosti vlastníkem daného e-mailového účtu. To, že se nebudete moci přihlásit, dokud nebude tento proces dokončen, zajistí, že budete motivováni ověřit svou adresu.
Stejně jako u mnoha dalších aspektů zabezpečení tento model omezuje použitelnost výměnou za poskytování zvýšené bezpečnosti ve vztahu k důvěře v identitu uživatele. To může být přijatelné pro web, kde si uživatel velmi cení registrace a rád by přidal další krok v procesu (placené služby, bankovnictví atd.), ale takové věci mohou uživatele vyřadit, pokud bude účet vnímat jako „na jedno použití“. “ a používá , například, jednoduše jako prostředek k okomentování příspěvku.
Identifikace, kdo inicioval proces resetování
Je zřejmé, že existují důvody pro škodlivé použ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 k ověření původu požadavku (tento trik obvykle funguje) - toto je přidáno k dopisu nabízejícímu resetování IP adresy žadatele. Zásobuje příjemce nějaký informace k identifikaci zdroje požadavku.
Zde je příklad z funkce reset, kterou právě zabudovávám do ASafaWeb:
Odkaz „zjistit více“ přenese uživatele na web , hlášení informací, jako je umístění a organizace žadatele o reset:
Každý, kdo chce skrýt svou identitu, má samozřejmě mnoho způsobů, jak zatemnit svou skutečnou IP adresu, ale toto je pohodlný způsob, jak přidat částečnou identifikaci žadatele a nejvíce v těchto případech vám to dá dobrou představu o tom, kdo dokončí žádost o resetování hesla.
Upozornění na změny emailem
Tento příspěvek je prodchnut jedním tématem - komunikace; Řekněte vlastníkovi účtu co nejvíce o tom, co se děje v každé fázi procesu, aniž byste odhalili cokoli, co by mohlo být zneužito. Totéž platí pro situaci, kdy se heslo skutečně změnilo - nahlaste to majiteli!
Pro změnu hesla mohou být dva důvody:
- Změna hesla po přihlášení, protože uživatel chce nové heslo
- Resetování hesla bez přihlášení, protože jej uživatel zapomněl
I když je tento příspěvek primárně o resetování, upozornění prvního 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 častým scénářem je, že je získáno heslo právoplatného vlastníka (opakovaně použité heslo uniklé z jiného zdroje, heslo zachycené klíčem, snadno uhodnutelné heslo atd.) a poté se útočník rozhodne je změnit, čímž vlastníka uzamkne. . Bez upozornění emailem se skutečný vlastník o změně hesla nedozví.
Samozřejmě v případě resetu hesla by vlastník již proces zahájil sám (nebo obešel výše popsané kontroly identifikace), takže změna by neměl může být pro něj překvapením, ale potvrzení e-mailem bude pozitivní zpětnou vazbou a dalším ověřením. Poskytuje také konzistenci s výše uvedeným scénářem.
Oh, a pro případ, že by to již nebylo zřejmé - Neposílejte nové heslo poštou! Někoho to možná rozesměje, ale :
Protokoly, protokoly, protokoly a některé další protokoly
Funkce resetování hesla je pro útočníky atraktivní: útočník chce buď získat přístup k účtu jiné osoby, nebo jednoduše způsobit nepříjemnosti vlastníkovi účtu/systému. Mnoho z výše popsaných praktik snižuje pravděpodobnost zneužití, ale nezabrání mu a rozhodně nezabrání lidem ve snaze využít funkci nezamýšleným způsobem.
Pro rozpoznání škodlivého chování je protokolování naprosto neocenitelným postupem, a to myslím velmi podrobné protokolování. Zaznamenávejte neúspěšné pokusy o přihlášení, resetování hesla, změny hesla (tj. když je uživatel již přihlášen) a téměř vše, co vám může pomoci pochopit, co se děje; to bude v budoucnu velmi užitečné. Log i individuální části části proces, například dobrá funkce resetování by měla zahrnovat zahájení resetování prostřednictvím webové stránky (zaznamenat požadavek na reset a pokusy o přihlášení s nesprávným uživatelským jménem nebo e-mailem), zaznamenat návštěvy webových stránek na resetovací URL (včetně pokusů o použití nesprávného tokenu), a poté zaznamenejte úspěch nebo neúspěch odpovědi na bezpečnostní otázku.
Když mluvím o protokolování, mám na mysli nejen zaznamenávání skutečnosti, že je stránka načtena, ale také shromažďování co největšího množství informací, pokud to není důvěrné. kluci, prosím nepište hesla do logů! Protokoly musí zaznamenávat identitu oprávněného uživatele (bude autorizován, pokud on změní stávající heslo nebo pokus o reset heslo někoho jiného po přihlášení), všechna uživatelská jména nebo e-mailové adresy, které zkouší, plus všechny pokusy o resetování tokenů. Ale také stojí za to protokolovat věci, jako jsou IP adresy, a pokud je to možné, dokonce i hlavičky požadavků. To vám umožní nejen znovu vytvořit že se uživatel (nebo útočník) pokouší udělat, ale také kdo on je takový.
Delegování odpovědnosti na jiné výkonné umělce
Pokud si myslíte, že to všechno představuje obrovské množství práce, nejste sami. Vybudování spolehlivého systému správy účtů ve skutečnosti není snadný úkol. Nejde o to, že by byl technicky náročný, jen má spoustu funkcí. Není to jen o resetování, je tu celý registrační proces, bezpečné ukládání hesel, řešení více neúspěšných pokusů o přihlášení atd. atd. Ačkoli , kromě toho je třeba udělat mnohem víc.
Dnes existuje mnoho poskytovatelů třetích stran, kteří rádi převezmou veškerou bolest a abstrahují vše do jedné spravované služby. Mezi takové služby patří OpenID, OAuth a dokonce i Facebook. Někteří lidé (OpenID bylo skutečně velmi úspěšné na Stack Overflow), ale další .
Není pochyb o tom, že služba jako OpenID řeší mnoho problémů pro vývojáře, ale také nepochybně přidává nové. Mají nějakou roli? Ano, ale zjevně nezaznamenáváme masové přijetí poskytovatelů autentizačních služeb. Banky, letecké společnosti a dokonce i obchody všechny implementují svůj vlastní ověřovací mechanismus a zjevně pro to existují velmi dobré důvody.
Škodlivý reset
Důležitým aspektem každého z výše uvedených příkladů je, že staré heslo je považováno pouze za zbytečné po potvrzení totožnosti majitele účtu. To je důležité, protože pokud by bylo možné účet resetovat na ověření identifikace, to by poskytlo příležitost pro nejrůznější škodlivé akce.
Zde je příklad: někdo podává nabídku na aukčním webu a na konci nabídkového procesu zablokuje konkurenty zahájením procesu resetování, čímž je vyřadí z nabídkového řízení. Je zřejmé, že pokud lze špatně navrženou funkci resetování zneužít, může to vést k vážným negativním výsledkům. Stojí za zmínku, že uzamčení účtu kvůli neplatným pokusům o přihlášení je podobná situace, ale to je téma pro jiný příspěvek.
Jak jsem řekl výše, pokud dáte anonymním uživatelům možnost resetovat heslo jakéhokoli účtu jednoduše tím, že znáte jejich e-mailovou adresu, pak je to zralá situace pro útok odmítnutí služby. To nemusí být ten pravý , o kterém jsme mluvili, ale neexistuje rychlejší způsob, jak uzamknout přístup k účtu, než pomocí špatně navržené funkce resetování hesla.
Nejslabší článek
Z hlediska ochrany jednoho účtu je vše výše napsané skvělé, ale vždy je potřeba si uvědomit ekosystém obklopující účet, který chráníte. Uvedu příklad:
ASafaWeb je hostován na úžasné službě poskytované AppHarbor. Proces resetování hostingového účtu probíhá takto:
Fáze 1:
Fáze 2:
Fáze 3:
Fáze 4:
Po přečtení všech předchozích informací je již snadné pochopit, které aspekty v ideálním světě bychom implementovali trochu jinak. Nicméně zde říkám, že pokud zveřejním web jako ASafaWeb na AppHarbor, a pak přijdu se skvělými bezpečnostními otázkami a odpověďmi, přidám druhý autentizační faktor a vše ostatní udělám podle pravidel, pak se to nemění skutečnost, že nejslabší článek v celém procesu bude schopen to všechno rozbít. Pokud se někdo úspěšně autentizuje v AppHarbor pomocí mých informací, bude si moci změnit heslo pro jakýkoli ASafaWeb účet na to, které potřebuje!
Jde o to, že síla implementace zabezpečení by měla být zvažována holisticky: hrozbu každého vstupního bodu v systému je třeba modelovat, i když jde o povrchní proces, jako je přihlašování do systému AppHarbor. To by mi mělo dát dobrou představu o tom, kolik úsilí musím vynaložit na proces resetování hesla ASafaWeb.
Dát to všechno dohromady
Tento příspěvek obsahuje spoustu informací, takže je chci zhustit do jednoduchého vizuálního obrysu:
Nezapomeňte se pro každou z těchto položek přihlásit co nejpodrobněji. To je ono, je to jednoduché!
Výsledky
Zdá se, že můj příspěvek je obsáhlý, nicméně existuje mnoho dalšího materiálu, který jsem mohl zahrnout, ale z důvodu stručnosti se rozhodlo ne: roli záchranné e-mailové adresy, situaci, kdy ztratíte přístup k e-mailu spojenému s vaším účtem (například odejdete ze zaměstnání) a tak dále. Jak jsem řekl dříve, funkce reset není tak složitá, ale existuje mnoho způsobů, jak se na to dívat.
I když reset není tak složitý, často je implementován nesprávně. Výše jsme viděli několik příkladů implementace moci vést k problémům a existuje mnoho dalších precedentů, kdy nesprávný reset doopravdy způsobil problémy. Nedávno se to ukázalo . To je vážně negativní výsledek!
Buďte tedy opatrní s funkcemi resetování, v různých bodech a při navrhování funkce si nesundávejte černý klobouk, protože je velká šance, že si ho nasadí někdo jiný!
Jako reklama
VDSina nabízí levné s denní platbou je každý server připojen k internetovému kanálu 500 megabitů a je zdarma chráněn před útoky DDoS!
Zdroj: www.habr.com
