Dvojfaktorové overenie
Všetko, čo čítate súvisiace s identifikáciou na základe skutočnosti, že žiadateľ vie. Pozná svoju e-mailovú adresu, vie, ako sa k nej dostať (t. j. pozná svoje e-mailové heslo) a pozná odpovede na bezpečnostné otázky.
"Znalosti" sa považujú za jeden autentifikačný faktor; sú ďalšie dva spoločné faktory čo máš, napríklad fyzické zariadenie a kto siako sú odtlačky prstov alebo sietnica oka.
Vo väčšine prípadov je vykonávanie biologickej identifikácie nerealizovateľné, najmä ak hovoríme o bezpečnosti webových aplikácií, takže pri dvojfaktorovej autentifikácii (dvojfaktorová autentifikácia, 2FA) sa zvyčajne používa druhý atribút - „to, čo máte“. Jednou z populárnych variácií na tento druhý faktor je fyzický token, napr. :
Fyzický token sa často používa na autentifikáciu v podnikových sieťach VPN a finančných službách. Na autentifikáciu do služby je potrebné použiť heslo aj kód na tokene (ktorý sa často mení) v kombinácii s PIN. Teoreticky na identifikáciu útočníka musí poznať heslo, mať token a poznať aj PIN tokenu. V scenári obnovenia hesla je samotné heslo zjavne neznáme, ale vlastníctvo tokenu možno použiť na preukázanie vlastníctva účtu. Samozrejme, ako pri každej implementácii zabezpečenia, , ale rozhodne zvyšuje bariéru vstupu.
Jedným z hlavných problémov tohto prístupu sú náklady a logistika implementácie; hovoríme o odovzdávaní fyzických zariadení každému klientovi a učení ich novému procesu. Používatelia navyše musia mať pri sebe zariadenie, čo nie je vždy prípad fyzického tokenu. Ďalšou možnosťou je implementácia druhého faktora autentifikácie pomocou SMS, ktorá v prípade 2FA môže slúžiť ako potvrdenie, že osoba vykonávajúca proces resetovania má mobilný telefón majiteľa účtu. Google to robí takto:
Musíte tiež povoliť , ale to znamená, že pri ďalšom obnovení hesla by sa váš mobilný telefón mohol stať druhým overovacím faktorom. Dovoľte mi to demonštrovať na mojom príklade. iPhone z dôvodov, ktoré budú čoskoro jasné:
Po identifikácii e-mailovej adresy účtu Google určí, že 2FA bola povolená a účet môžeme resetovať pomocou overenia, ktoré sa odošle prostredníctvom SMS na mobilný telefón majiteľa účtu:
Teraz musíme vybrať začiatok procesu resetovania:
Táto akcia odošle e-mail na registrovanú adresu:
Tento e-mail obsahuje adresu URL na obnovenie:
Pri prístupe na resetovaciu adresu URL sa odošle SMS a webová lokalita si ju vyžiada:
Tu je SMS:
Po jeho zadaní do prehliadača sme späť v klasickej oblasti obnovenia hesla:
Pravdepodobne to znie trochu podrobne a je to tak, ale formulár potvrdzuje, že osoba vykonávajúca reset má prístup k e-mailovej adrese a mobilnému telefónu majiteľa účtu. Môže to však byť deväťkrát bezpečnejšie ako resetovanie hesla iba prostredníctvom e-mailu. Existujú však problémy...
Problém sa týka smartfónov. Zariadenie zobrazené nižšie môže certifikovať iba jeden faktor autentifikácie – môže prijímať SMS, ale nie e-maily:
Toto zariadenie však môže prijímať SMS и prijímať e-maily na obnovenie hesla:
Problém je v tom, že za prvý faktor autentifikácie považujeme email a za druhý SMS (alebo aj aplikáciu na generovanie tokenov), no dnes sú kombinované v jednom zariadení. To, samozrejme, znamená, že ak sa niekto dostane k vášmu smartfónu, všetko toto pohodlie spočíva v tom, že sme opäť späť na tom istom kanáli; tento druhý faktor „to, čo máte“ znamená, že máte aj prvý faktor. A to všetko je chránené jediným štvormiestnym PINom...ak ten telefón vôbec má. и bol zablokovaný.
Áno, funkcia 2FA od Google určite poskytuje dodatočnú ochranu, ale nie je spoľahlivá a určite nezávisí od dvoch úplne autonómnych kanálov.
Obnoviť podľa používateľského mena vs. Obnoviť podľa e-mailovej adresy
Mám povoliť resetovanie iba prostredníctvom e-mailovej adresy? Alebo by mal mať používateľ možnosť resetovať aj podľa mena? Problém s resetovaním podľa používateľského mena je, že neexistuje spôsob, ako upozorniť používateľa na neplatné používateľské meno, bez zverejnenia že niekto iný môže mať účet s týmto menom. V predchádzajúcej časti obnovenie e-mailu zaistilo, že právoplatný vlastník tohto e-mailu vždy dostane spätnú väzbu bez toho, aby verejne zverejnil svoju existenciu v systéme. To sa nedá urobiť len s používateľským menom.
Takže krátka odpoveď je: iba e-mail. Ak sa pokúsite resetovať iba pomocou používateľského mena, nastanú prípady, keď sa používateľ bude čudovať, čo sa stalo, alebo zverejníte existenciu účtov. Áno, je to len používateľské meno, nie e-mailová adresa a áno, ktokoľvek si môže vybrať akékoľvek (dostupné) používateľské meno, ale stále existuje veľká šanca, že nepriamo odhalíte vlastníkov účtu kvôli tendencii používateľov opakovane používať meno.
Čo sa teda stane, keď niekto zabudne svoje používateľské meno? Za predpokladu, že používateľské meno nie je okamžite e-mailovou adresou (čo je často prípad), potom je proces podobný tomu, ako začína obnovenie hesla - zadajte e-mailovú adresu a potom na túto adresu odošlite správu bez zverejnenia jej existencie. Jediný rozdiel je v tom, že tentoraz správa obsahuje iba používateľské meno a nie adresu URL na obnovenie hesla. Buď to, alebo e-mail povie, že pre túto adresu neexistuje žiadny účet.
Overenie identity a presnosť e-mailových adries
Kľúčový aspekt resetovania hesiel a možno dokonca najviac kľúčovým aspektom je overenie identity osoby, ktorá sa pokúša resetovať. Je toto naozaj právoplatný vlastník účtu, alebo sa doň niekto snaží nabúrať alebo spôsobiť majiteľovi nepríjemnosti?
Je zrejmé, že e-mail je najpohodlnejší a najbežnejší kanál na overenie identity. Nie je spoľahlivá a existuje veľa prípadov, keď jednoducho možnosť prijímať poštu na adrese majiteľa účtu nestačí, ak sa vyžaduje vysoký stupeň dôvery v identifikáciu (preto sa používa 2FA), ale takmer vždy je východiskový bod. proces resetovania.
Ak e-mail bude zohrávať úlohu pri poskytovaní dôvery, potom prvým krokom je uistiť sa, že e-mailová adresa je skutočne správna. Ak sa niekto pomýlil so symbolom, potom sa reset samozrejme nespustí. Proces overenia e-mailu v čase registrácie je spoľahlivým spôsobom, ako overiť správnosť adresy. Všetci sme to videli v akcii: keď sa zaregistrujete, dostanete e-mail s jedinečnou adresou URL, na ktorú musíte kliknúť, čo potvrdzuje, že ste skutočným vlastníkom daného e-mailového účtu. Neschopnosť prihlásiť sa, kým sa tento proces nedokončí, zaisťuje motiváciu overiť adresu.
Ako je to v prípade mnohých iných aspektov bezpečnosti, tento model znižuje použiteľnosť výmenou za poskytnutie zvýšeného stupňa bezpečnosti v porovnaní s dôverou v identitu používateľa. To môže byť prijateľné pre stránky, kde si používateľ veľmi váži registráciu a rád pridá ďalší krok v procese (platené služby, bankovníctvo atď.), ale takéto veci môžu používateľa odpudzovať, ak účet vníma ako „jedno- čas“ a používa sa napríklad len ako prostriedok na komentovanie príspevku.
Identifikácia toho, kto inicioval proces resetovania
Je zrejmé, že existujú dôvody na zlomyseľné používanie funkcie resetovania a útočníci ju môžu použiť mnohými rôznymi spôsobmi. Jeden jednoduchý trik, ktorý môžeme použiť na overenie pôvodu požiadavky (tento trik zvyčajne funguje) je dodatok k listu s návrhom na resetovanie IP adresy žiadateľa. Dodáva príjemcovi niektoré informácie na identifikáciu zdroja žiadosti.
Tu je príklad z funkcie resetovania, ktorú momentálne staviam do ASafaWeb:
Odkaz „zistiť viac“ prevedie používateľa na stránku s uvedením informácií, ako je miesto a organizácia žiadateľa o obnovenie:
Samozrejme, každý, kto chce skryť svoju identitu, má mnoho spôsobov, ako zakryť svoju skutočnú IP adresu, ale toto je pohodlný spôsob, ako pridať čiastočnú identifikáciu žiadateľa a väčšina V niektorých prípadoch vám to poskytne reálnu predstavu o tom, kto dokončí žiadosť o obnovenie hesla.
Upozornenie na zmenu e-mailu
Tento príspevok je preniknutý jednou témou - komunikácia; povedzte vlastníkovi účtu čo najviac o tom, čo sa deje v každom kroku procesu, bez toho, aby ste odhalili čokoľvek, čo by sa mohlo použiť so zlým úmyslom. To isté platí pre situáciu, keď sa heslo skutočne zmenilo − upozornite majiteľa!
Dôvody na zmenu hesla môžu byť dva:
- Zmena hesla po prihlásení, pretože používateľ chce nové heslo
- Obnoviť heslo bez prihlásenia, pretože ho používateľ zabudol
Aj keď je tento príspevok väčšinou o resetovaní, upozornením prvého znižuje riziko, že si niekto zmení heslo bez vedomia právoplatného vlastníka. Ako sa to môže stať? Veľmi častým scenárom je získanie hesla právoplatného vlastníka (opakovane použité heslo uniknuté z iného zdroja, heslo získané keyloggingom, ľahko uhádnuteľné heslo atď.), po čom sa útočník rozhodne zmeniť, čím zablokuje vlastníka. Bez upozornenia e-mailom sa skutočný vlastník o zmene hesla nedozvie.
Samozrejme, v prípade resetovania hesla by už vlastník mal iniciovať proces sám (alebo obísť vyššie popísané nástroje na overenie identifikácie), takže zmena by nemali bude pre neho prekvapením, avšak potvrdenie e-mailom bude pozitívnou spätnou väzbou a dodatočným overením. Okrem toho poskytuje jednotu s vyššie opísaným scenárom.
Oh, a v prípade, že to ešte nie je zrejmé - neposielajte nové heslo poštou! Niektorých to možno rozosmeje, ale :
Protokoly, protokoly, protokoly a niektoré ďalšie protokoly
Funkcia obnovenia hesla je pre útočníkov atraktívna: útočník chce buď získať prístup k účtu inej osoby, alebo jednoducho spôsobiť nepríjemnosti vlastníkovi účtu/systému. Mnohé z vyššie popísaných praktík znižujú možnosť zneužitia, no nezabránia mu a určite nezabránia ľuďom v pokusoch o používanie funkcie neúmyselným spôsobom.
Na odhaľovanie škodlivého správania je protokolovanie absolútne neoceniteľnou praxou veľmi podrobné protokolovanie. Zaznamenajte neúspešné pokusy o prihlásenie, resetovanie hesiel, zmenu hesiel (t. j. keď je používateľ už prihlásený) a takmer všetko, čo vám môže pomôcť pochopiť, čo sa deje; to bude v budúcnosti veľmi užitočné. Opravte v protokoloch aj individuálne diely dobrá funkcia resetovania by napríklad mala zahŕňať spustenie resetovania cez webovú stránku (zaznamenanie žiadosti o reset a pokusy o prihlásenie s nesprávnym používateľským menom alebo e-mailom), zaznamenanie návštevy webovej stránky na resetovacej adrese URL (vrátane pokusov použiť nesprávnu token) a potom zapíšte úspech alebo zlyhanie odpovede na bezpečnostnú otázku.
Keď hovorím o protokolovaní, mám na mysli nielen zaznamenávanie skutočnosti, že sa stránka načítala, ale aj zhromažďovanie čo najväčšieho množstva informácií, ak to nie je dôverné. chlapci, prosím neprihlasujte heslá! V protokoloch je potrebné zaregistrovať identitu oprávneného používateľa (bude autorizovaný, ak on zmena existujúce heslo alebo pokus o obnovenie heslo niekoho iného po prihlásení), všetky používateľské mená alebo e-mailové adresy, ktoré skúša, plus všetky resetovacie tokeny, ktoré sa pokúša použiť. Ale tiež stojí za to zaznamenávať veci, ako sú adresy IP, a ak je to možné, dokonca aj hlavičky žiadostí. To vám umožní nielen obnoviť že používateľ (alebo útočník) sa snaží urobiť, ale aj kto on je taký a.
Delegovanie zodpovednosti na iných účinkujúcich
Ak si myslíte, že to všetko predstavuje obrovské množstvo práce, tak nie ste sami. Vybudovanie spoľahlivého systému na prácu s účtami v skutočnosti nie je ľahká úloha. Nejde o to, že by bol technicky náročný, ale len o to, že má veľa funkcií. Nie je to len o resetovaní, ide o celý proces prihlasovania, bezpečného ukladania hesiel, vybavovania viacerých chybných pokusov o prihlásenie a tak ďalej a tak ďalej. Hoci okrem toho je potrebné urobiť oveľa viac.
Dnes existuje veľa dodávateľov tretích strán, ktorí sú radi, že sa z toho zbavia bolesti a abstrahujú to všetko do jednej spravovanej služby. Tieto služby zahŕňajú OpenID, OAuth a dokonca aj Facebook. Nejakí ľudia (OpenID bolo skutočne veľmi úspešné na Stack Overflow), ale iné .
Služba ako OpenID nepochybne rieši množstvo vývojárskych problémov, no isté je aj to, že pridáva nové. Majú nejakú úlohu? Áno, ale je jasné, že nezaznamenávame masívne využívanie služieb poskytovateľov autentifikačných služieb. Banky, letecké spoločnosti a dokonca aj obchody všetky implementujú svoj vlastný autentifikačný mechanizmus a samozrejme na to existujú veľmi dobré dôvody.
Škodlivý reset
Dôležitým aspektom každého z vyššie uvedených príkladov je, že staré heslo sa považuje iba za zbytočné po potvrdení totožnosti majiteľa účtu. Je to dôležité, pretože ak by sa účet mohol obnoviť na kontroly identity, to by poskytlo príležitosť na všetky druhy škodlivých aktivít.
Tu je príklad: niekto ponúka ponuku na aukčnej stránke a na konci procesu ponúkania zablokuje konkurentov spustením procesu resetovania, čím ich odstráni z ponuky. Je zrejmé, že ak môže byť nesprávne navrhnutá funkcia resetovania zneužitá, môže to viesť k vážnym negatívnym výsledkom. Stojí za zmienku, že blokovanie účtov s neplatnými pokusmi o prihlásenie je podobná situácia, ale toto je téma na iný príspevok.
Ako som povedal vyššie, ak anonymným používateľom dáte možnosť obnoviť heslo akéhokoľvek účtu len tým, že poznáte ich e-mailovú adresu, potom je to hotová situácia pre útok odmietnutia služby. Možno to nebude ten pravý , o ktorom sme hovorili, no neexistuje rýchlejší spôsob, ako zablokovať prístup k účtu, než pomocou zle premyslenej funkcie resetovania hesla.
Najslabší článok
Z pohľadu ochrany jedného účtu je všetko napísané vyššie skvelé, no vždy treba mať na pamäti ekosystém, ktorý obklopuje účet, ktorý chránite. Uvediem príklad:
ASafaWeb je hosťovaný na úžasnej službe poskytovanej spoločnosťou AppHarbor. Proces resetovania hostingového účtu je nasledovný:
1. fáza:
2. fáza:
3. fáza:
4. fáza:
Po prečítaní všetkých predchádzajúcich informácií je už ľahké pochopiť, ktoré aspekty v ideálnom svete by sme implementovali trochu inak. Chcem tu však povedať, že ak zverejním stránku ako ASafaWeb na AppHarbor a potom prídem so skvelými bezpečnostnými otázkami a odpoveďami, pridám druhý autentifikačný faktor a všetko ostatné urobím podľa pravidiel, nič sa nezmení. fakt, že najslabší článok v celom procese to všetko dokáže prelomiť. Ak sa niekto úspešne overí v AppHarbor pomocou mojich informácií, bude si môcť zmeniť heslo pre akýkoľvek ASafaWeb účet na to, ktoré potrebuje!
Ide o to, že sila implementácie bezpečnosti by sa mala posudzovať holisticky: hrozby by sa mali modelovať v každom vstupnom bode v systéme, aj keď ide o povrchný proces, akým je prihlásenie do AppHarbor. To by mi malo poskytnúť dobrú predstavu o tom, koľko úsilia musím vynaložiť na proces obnovenia hesla ASafaWeb.
Dávať to všetko dokopy
Tento príspevok obsahuje veľa informácií, preto ho chcem sústrediť do jednoduchej vizuálnej schémy:
Nezabudnite, že by ste mali vykonať čo najpodrobnejšie protokolovanie každej z týchto položiek. To je všetko, je to jednoduché!
Výsledky
Zdá sa, že môj príspevok je obsiahly, existuje však veľa ďalšieho materiálu, ktorý som mohol zahrnúť doň, ale rozhodli ste sa proti nemu z dôvodu stručnosti: úloha záchrannej e-mailovej adresy, situácia, v ktorej stratíte prístup k e-mailu spojenému s vaším účtom (napríklad odídete zo zamestnania) atď. Ako som už povedal, funkcia reset nie je až taká zložitá, len na ňu existuje veľa rôznych pohľadov.
Aj keď reset nie je taký zložitý, často je implementovaný nesprávne. Vyššie sme videli niekoľko príkladov implementácie plechovka viesť k problémom a existuje oveľa viac prípadov, keď nesprávny reset naozaj spôsobili problémy. Nedávno sa to ukázalo . Toto je vážny negatívny výsledok!
Takže buďte opatrní s funkciami resetovania, v rôznych bodoch a pri navrhovaní prvku si nedávajte dole čierny klobúk, pretože je veľká šanca, že ho bude nosiť niekto iný!
O právach reklamy
VDSina ponúka lacné s dennou platbou je každý server pripojený k internetovému kanálu 500 Mbps a je chránený pred DDoS útokmi zadarmo!
Zdroj: hab.com
