Nedávno som mal čas znovu premýšľať o tom, ako by mala fungovať funkcia bezpečného resetovania hesla, najprv keď som ju implementoval do , a potom keď som pomáhal vytvoriť niečo podobné inej osobe. V druhom prípade som chcel dať odkaz na kanonický zdroj so všetkými podrobnosťami o bezpečnej implementácii funkcie resetovania. Problém je, že takýto zdroj neexistuje, aspoň nie taký, ktorý by popisoval všetko, čo považujem za dôležité. Preto som sa rozhodol napísať ho sám.
Vidíte, svet zabudnutých hesiel je naozaj celkom záhadný. Existuje množstvo rôznych, celkom prijateľných pohľadov a kopu skutočne nebezpečných. Je pravdepodobné, že s každým z nich ste sa mnohokrát stretli ako koncový používateľ; preto sa pokúsim využiť tieto príklady, aby som ukázal, kto to robí správne a kto nie, a na čom sa treba zamerať na správnu implementáciu funkcie vo vašej aplikácii.
Ukladanie hesiel: hashovanie, šifrovanie a (och!) obyčajný text
Nemôžeme diskutovať o tom, čo robiť so zabudnutými heslami, kým neprediskutujeme spôsob ich ukladania. V databáze sú heslá uložené v jednom z troch základných typov:
- Obyčajný text. Existuje stĺpec s heslom, ktorý je uložený v obyčajnom textovom formáte.
- Šifrovaný. Zvyčajne pomocou symetrického šifrovania (jeden kľúč sa používa na šifrovanie aj dešifrovanie), a šifrované heslá sú tiež uložené v jednom stĺpci.
- Hashovaný. Jednosmerný proces (heslo sa dá hashovať, ale nemožno ho dehashovať); heslo, dúfajme, je sprevádzané soľou a každý z nich sa nachádza v vlastnom stĺpci.
Poďme si hneď objasniť tú najjednoduchšiu otázku: nikdy neukladajte heslá v obyčajnom texte! Nikdy. Iba jedna jediná zraniteľnosť na , jedna neopatrne vytvorená záloha alebo jeden z desiatok ďalších jednoduchých chýb — a je to, game over, všetky vaše heslá — teda, prepáčte, heslá všetkých vašich klientov sa stanú verejným majetkom. Samozrejme, to bude znamenať obrovskú pravdepodobnosť, že verejným majetkom sa stanú zo všetkých ich účtov v iných systémoch. A to bude vaša chyba.
Šifrovanie je lepšie, ale má svoje slabé stránky. Problém šifrovania spočíva v dešifrovaní; môžete vziať tieto šialene vyzerajúce šifry a pretransformovať ich späť na jednoduchý text, a keď sa to stane, vrátíme sa k situácii s čitateľnými heslami. Ako sa to deje? Malá chyba sa dostane do kódu, ktorý sa zaoberá dešifrovaním hesla, čím ho sprístupňuje verejnosti — to je jeden spôsob. Hackeri získavajú prístup k stroju, na ktorom sú uložené zašifrované údaje — to je druhý spôsob. Ďalší spôsob opäť spočíva v tom, že ukradnú zálohu databázy a niekto taktiež získava šifrovací kľúč, ktorý sa často uchováva veľmi nespoľahlivo.
A to nás privádza k hashovaniu. Myšlienka hashovania spočíva v tom, že sa vykonáva jednosmerne; jediný spôsob, ako porovnať heslo zadané používateľom s jeho hashovanou verziou — je hashovanie zadaného a ich porovnanie. Aby sme predišli útokom pomocou nástrojov ako „dúhovóe tabuľky“, pridávame do procesu náhodnosť pomocou soli (pre kompletnosť si prečítajte môj o kryptografickom ukladaní). V konečnom dôsledku, pri správnej implementácii môžeme s veľkou dôverou tvrdiť, že hashované heslá sa už nikdy nestanú jednoduchým textom (o výhodách rôznych hashovacích algoritmov poviem v inom príspevku).
Krátka argumentácia o hashovaní a šifrovaní: jediný dôvod, prečo by ste niekedy mali zašifrovať, a nie hashovať heslo — je, keď chcete vidieť heslo v jednoduchom texte, a to by ste nikdy nemali chcieť, aspoň v situácii so štandardnou webovou stránkou. Ak to potrebujete, je veľmi pravdepodobné, že robíte niečo zle!
Pozor!
Trochu nižšie v texte príspevku je časť screenshotu pornografickej webovej stránky AlotPorn. Je starostlivo orezaná, a tak nie je nič také, čo by ste nemohli vidieť na pláži, ale ak to aj tak môže spôsobiť nejaké problémy, tak neprejdite nižšie na stránku.
Vždy obnovte heslo, nikdy ho nepripomínajte.
Boli vás niekedy požiadaní, aby ste vytvorili funkciu pripomienky? hesla? Urobte krok späť a zamyslite sa nad touto požiadavkou naopak: prečo je potrebné toto „pripomenutie“? Pretože používateľ zabudol heslo. Čo sa naozaj snažíme urobiť? Pomôcť mu znovu sa prihlásiť do systému.
Chápem, že slovo „pripomenutie“ sa používa (často) v hovorovom zmysle, ale v skutočnosti sa snažíme bezpečne pomôcť používateľovi znovu byť online. Keďže potrebujeme bezpečnosť, existujú dva dôvody, prečo pripomenutie (t. j. zaslanie používateľovho hesla) nie je vhodné:
- E-mail je nebezpečný kanál. Rovnako ako by sme neprenášali nič dôverné cez HTTP (použili by sme HTTPS), nemali by sme posielať nič cez e-mail, pretože jeho prenosová vrstva nie je bezpečná. V skutočnosti je to omnoho horšie ako jednoduchý prenos informácií cez nezabezpečený prenosový protokol, pretože e-maily sa často ukladajú na úložisko, sú dostupné systémovým administrátorom, posielajú sa ďalej a šíria sa, sú dostupné malvéru a tak ďalej. Nešifrovaný e-mail je mimoriadne nezabezpečený kanál.
- Nemali by ste mať prístup k heslu za žiadnych okolností. Prečítajte si predchádzajúcu časť o ukladaní – mali by ste mať hashed heslo (s dobrou odolnou soľou), to znamená, že by ste nijakým spôsobom nemali mať možnosť vytiahnuť heslo a poslať ho e-mailom.
Dovoľte mi demonštrovať problém na príklade : Tu je typická prihlasovacia stránka:
Je zrejmé, že prvým problémom je, že prihlasovacia stránka sa nenačítava cez HTTPS, ale stránka navyše ponúka zaslať heslo („Send Password“). Možno ide o príklad spomínaného hovorového použitia tohto termínu, takže urobme ešte jeden krok a pozrime sa, čo sa stane:
Bohužiaľ, to nevyzerá omnoho lepšie; a e-mail potvrdzuje existenciu problému:
Hovorí nám to o dvoch dôležitých aspektoch usoutdoor.com:
- Stránka nehashuje heslá. Najlepšie, čo sa s nimi deje, je, že sa šifrujú, ale je veľmi pravdepodobné, že sú uložené v textovej podobe; svedectvo o opaku nevidíme.
- Stránka posiela trvalé heslo (môžeme sa k nemu vracať a používať ho znova a znova) cez nezabezpečený kanál.
Abychom to shrnuli, nejprve musíme ověřit, zda se proces resetování provádí bezpečným způsobem. Začneme tím, že se ujistíme, že žadatel má právo provést reset. Jinými slovy, před tím je nutné ověřit identitu; podívejme se, co se stane, když je identita potvrzena bez předchozího ověření, že žadatel je skutečně majitelem účtu.
Výčet uživatelských jmen a jeho vliv na anonymitu
Tento problém je lépe ilustrovat vizuálně. Problém:
Vidíte? Všimněte si zprávy „There is no user registered with this email address“ („Uživatel s touto e-mailovou adresou není registrován“). Problém samozřejmě nastává, pokud takový web potvrzuje existenci registrovaného uživatele s touto e-mailovou adresou. Bingo — právě jste odhalili porno-fetish vašeho manžela/šéfa/souseda!
Samozřejmě, že porno je poměrně klasickým příkladem důležitosti soukromí, avšak nebezpečí spojování identity s určitým webem je mnohem širší, než je zde popsaná potenciálně trapná situace. Jedno z nebezpečí zahrnuje sociální inženýrství; pokud útočník dokáže spojit osobu se službou, získá informace, které může začít využívat. Například se může spojit s osobou, vydávaje se za zástupce webu, a požádat o další informace, snažíc se provést .
Takové praktiky také vyžadují vznik nebezpečí „výčtu uživatelských jmen“, kdy je možné prověřit existenci celé sady uživatelských jmen nebo e-mailových adres na webu pomocí jednoduchých hromadných dotazů a studováním jejich odpovědí. Máte seznam e-mailových adres všech zaměstnanců a několik minut na napsání skriptu? Pak vidíte, v čem je problém!
Jaká je tedy alternativa? Odpověď je poměrně jednoduchá a skvěle je implementována na :
Zde Entropay vůbec nic neodhaluje o existenci e-mailové adresy ve svém systému komu nemá tento e-mailový adresář. Pokud ovládáte tento adresa neexistuje v systéme, dostanete podobný e-mail:
Samozrejme, existujú prípustné situácie, v ktorých niekto myslí, že sa zaregistroval na webovej stránke. ale nie, alebo to urobil z inej e-mailovej adresy. Ukázaný príklad efektívne zvláda obe situácie. Samozrejme, ak sa adresa zhoduje, dostanete e-mail, ktorý uľahčuje resetovanie hesla.
Mierou zvoleného riešenia Entropay je, že overenie identity sa vykonáva prostredníctvom e-mailu pred akýmkoľvek online overením. Niektoré stránky sa pýtajú používateľov na odpoveď na tajnú otázku (viac o tom nižšie) do predtým, než sa resetovanie môže začať; problém je v tom, že na otázku treba odpovedať s poskytovaním nejakej formy identity (e-mailu alebo username), čo potom takmer znemožňuje intuitívne odpovedať, bez odhalenia existencie účtu anonymného používateľa.
Pri takom prístupe existuje malé zníženie použiteľnosti, pretože v prípade pokusu o resetovanie neexistujúceho účtu nie je okamžitá spätná väzba. Samozrejme, v tom spočíva celej myšlienka odoslania e-mailu, ale z pohľadu skutočného koncového používateľa, ak vloží nesprávnu adresu, prvýkrát sa o tom dozvie iba po prijatí e-mailu. To môže vyvolať určité napätie z jeho strany, ale je to malá cena za tak zriedkavý proces.
Ďalšia poznámka, ktorá je trochu mimo tému: funkcie na pomoc pri prihlásení, ktoré odhaľujú správnosť používateľského mena alebo e-mailovej adresy, majú rovnaký problém. Vždy reagujte používateľovi správou „Neplatná kombinácia používateľského mena a hesla“ (Your username and password combination is invalid), a nie potvrďte explicitne existenciu identifikačných údajov (napríklad „používateľské meno je správne, ale heslo je zlé“).
Odosielanie hesla na resetovanie oproti odosielaniu URL na resetovanie
Nasledujúci koncept, ktorý musíme prediskutovať, sa týka spôsobu resetovania hesla. Existujú dve populárne riešenia:
- Generovanie nového hesla na serveri a jeho odoslanie e-mailom
- Odoslanie e-mailu s jedinečným URL, ktorý uľahčuje proces resetovania
Napriek tomu , prvý bod nikdy nepoužívajte. Jeho problém spočíva v tom, že to znamená existenciu uloženého hesla, ku ktorému sa môžete vrátiť a znova ho použiť kedykoľvek; bolo odoslané cez nezabezpečený kanál a zostáva vo vašich prichádzajúcich. Existuje pravdepodobnosť, že prichádzajúce správy sa synchronizujú s mobilnými zariadeniami a klientom elektronickej pošty, a navyše môžu byť uložené online vo webovom servise elektronickej pošty veľmi dlhý čas. Zmysel spočíva v tom, že poštová schránka nemôže byť považovaná za spoľahlivý prostriedok na dlhodobé uchovávanie.
Ale okrem toho má prvý bod ešte jeden vážny problém — maximálne zjednodušuje blokovanie účtu so zlým úmyslom. Ak poznám emailovú adresu toho, kto vlastní účet na webovej stránke, môžem ho kedykoľvek zablokovať jednoducho resetovaním jeho hesla; to je útok typu „odmietnutie služby“, ponúknutý na podnose s modrým okrajom! Preto by sa reset mal vykonávať iba po úspešnej overení oprávnenia osoby, ktorá o to žiada.
Keď hovoríme o URL resetovania, máme na mysli adresu webovej stránky, ktorá je unikátna pre tento konkrétny proces resetovania. Samozrejme, musí byť náhodná, nemala by byť ľahko uhádnuteľná a nemala by obsahovať žiadne externé odkazy na účet, ktoré by uľahčovali reset. Napríklad, URL resetovania by nemala byť jednoducho cestou ako „Reset/?username=JohnSmith“.
Chceme vytvoriť unikátny token, ktorý bude možné poslať emailom ako URL resetovania, a potom ho porovnať s údajmi na serveri s účtom používateľa, čím potvrdíme, že vlastník účtu je naozaj tá istá osoba, ktorá sa pokúša resetovať heslo. Napríklad, token môže mať podobu „3ce7854015cd38c862cb9e14a1ae552b“ a bude uložený v tabuľke spolu s ID používateľa, ktorý vykonáva reset, a časom generácie tokenu (viac o tom nižšie). Pri odosielaní emailu obsahuje URL ako „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, a keď používateľ načíta túto adresu, stránka overí existenciu tokenu, po čom potvrdí informácie používateľa a povolí zmenu hesla.
Samozrejme, keďže uvedený proces (dúfajme) umožňuje používateľovi vytvoriť nové heslo, je potrebné zabezpečiť, aby sa URL načítalo cez HTTPS. Nie, táto URL s tokenom by mala používať bezpečnosť transportnej vrstvy, aby na formulár na zadanie nového hesla nebolo možné útočiť, a heslo vytvorené používateľom sa prenášalo prostredníctvom zabezpečeného pripojenia.
Okrem toho je potrebné pridať časové obmedzenie tokenu na URL pre resetovanie, aby sa proces resetovania mohol uskutočniť v rámci určitého časového intervalu, napríklad do jednej hodiny. To zabezpečí, že doba resetovania bude minimálna, takže ten, kto dostane túto URL pre resetovanie, môže konať iba v tomto veľmi malom okne. Samozrejme, útočník môže znovu začať proces resetovania, ale bude musieť získať ďalšiu jedinečnú URL pre resetovanie.
Nakoniec musíme zabezpečiť jednorazovosť tohto procesu. Po dokončení procesu resetovania je potrebné token odstrániť, aby URL pre resetovanie už nefungovala. Predchádzajúci bod je potrebný na to, aby útočník mal veľmi malé okno, počas ktorého môže manipulovať s URL pre resetovanie. Plus, samozrejme, po úspešnom dokončení resetovania už token nie je potrebný.
Niektoré z týchto krokov sa môžu zdať príliš nadbytočné, ale vôbec neobmedzujú použiteľnosť a v skutočnosti zvyšujú bezpečnosť, hoci v situáciách, ktoré, dúfajme, budú zriedkavé. V 99% prípadoch používateľ uskutoční reset v veľmi krátkom časovom úseku a nebude resetovať heslo znova v blízkej budúcnosti.
Úloha CAPTCHA,
Ach, CAPTCHA, prostriedok ochrany, ktorý všetci tak radi nenávidíme! V skutočnosti je CAPTCHA prostriedkom nie len ochrany, ale skôr identifikácie – ste človek, alebo robot (alebo automatizovaný skript). Jej zmyslom je vyhnúť sa automatickému odoslávaniu formulárov, čo samozrejme, môže byť použitý ako pokus o prienik ochrany. V kontexte resetovania hesiel CAPTCHA znamená, že funkciu resetovania nebude možné hacknúť hrubou silou, aby ste buď spamovali používateľa, alebo sa pokúsili určiť existenciu účtov (čo, samozrejme, bude nemožné, ak ste dodržiavali rady z časti o overovaní identity).
Samozrejme, CAPTCHA sama o sebe nie je dokonalá; existuje množstvo prípadov jej programového „hackovania“ a dosahovania dostatočných úspešností (60-70%). Okrem toho existuje riešenie, ktoré je uvedené v mojom príspevku o , kde je možné platiť ľuďom centy za vyriešenie každej CAPTCHA a dosiahnutie úspešnosti 94%. To znamená, že je zraniteľná, avšak (trochu) zvyšuje vstupnú bariéru.
Pozrime sa na príklad PayPal:
V tomto prípade sa proces obnovenia hesla jednoducho nemôže začať pred vyriešením CAPTCHA, takže teoreticky je možné automatizovať proces. Teoreticky.
Avšak pre väčšinu webových aplikácií to bude cez čiaru a určite predstavuje zníženie použiteľnosti - ľudia jednoducho nemajú radi CAPTCHA! Okrem toho, CAPTCHA je taká vec, k ktorej sa v prípade potreby dá ľahko vrátiť. Ak služba začína čeliť útoku (tu prichádza vhod logovanie, ale o tom viac neskôr), tak pridať CAPTCHA je najjednoduchšie.
Tajné otázky a odpovede
Pri všetkých spôsoboch, ktoré jsme preskúmali, sme mali možnosť resetovať heslo len s prístupom k e-mailovému účtu. Hovorím "len", ale samozrejme, nezákonné získanie prístupu k cudziemu e-mailovému účtu musí môže byť zložitý proces. Avšak .
V skutočnosti, odkaz uvedený vyššie o hackovaní účtu Sary Palin na Yahoo! slúži dvom cieľom; po prvé, ilustruje, ako ľahko je možné hackovať (niektoré) e-mailové účty, po druhé, ukazuje, ako je možné s zlým úmyslom používať zlé tajné otázky. Ale k tomu sa vrátime neskôr.
Problém so resetovaním hesiel, ktoré sú 100% závislé od e-mailu, spočíva v tom, že integrita účtu webovej stránky, ktorej heslo sa snažíte resetovať, sa stáva 100% závislou od integrity e-mailového účtu. Kto má prístup k vašej e-mailovej schránke, má prístup ku každému účtu, ktorý je možné resetovať jednoduchým prijatím e-mailu. Pre takéto účty je e-mail "kľúčom ku všetkým dverám" vášho online života.
Jedným zo spôsobov, ako znížiť toto riziko, je implementácia vzoru tajnej otázky a odpovede. Bezpochyby ste ich už videli: vyberiate otázku, na ktorú len vy musíte poznať odpoveď, po čom vám pri obnove hesla položia. To pridáva istotu, že osoba, ktorá sa snaží obnoviť prístup, je skutočne vlastníkom účtu.
Vráťme sa k Sarah Palin: ch chyba spočívala v tom, že odpovede na jej tajné otázky sa dali ľahko nájsť. Konkrétne, keď ste tak významná verejná osobnosť, informácie o dievčenskom priezvisku matky, histórii vzdelávania alebo o tom, kde niekto mohol žiť v minulosti, nie sú až také tajné. V skutočnosti, veľká časť z toho môže byť nájdená takmer každým. Tak sa to stalo aj so Sarah:
Hackér David Kernell získal prístup k účtu Palinovej, keď našiel podrobnosti o jej biografii, ako sú jej vysoká škola a dátum narodenia, a potom využil funkciu na obnovenie zabudnutých hesiel k účtom Yahoo!.
Primárne ide o chybu dizajnu zo strany Yahoo! — uvedením takých jednoduchých otázok spoločnosť vlastne sabotovala hodnotu tajnej otázky, a teda aj ochranu svojho systému. Samozrejme, obnova hesiel k účtu e-mailu je vždy zložitejšia, pretože nemôžete potvrdiť jeho vlastníctvo zaslaním e-mailu vlastníkovi (bez druhého adresy), ale našťastie dnes pre vytvorenie takého systému nie je až tak veľa spôsobov aplikácie.
Vráťme sa k tajným otázkam — existuje možnosť poskytovať používateľom možnosť vytvárať vlastné otázky. Problém je v tom, že výsledkom budú hrozne očividné otázky:
Akú farbu má nebo?
Otázky, ktoré dávajú ľudí do nepríjemnej situácie, keď identifikáciu vykonáva tajná otázka, človek (napríklad v call centre):
S kým som spal na Vianoce?
Alebo otvorene hlúpe otázky:
Ako sa píše "heslo"?
Keď ide o tajné otázky, používateľov treba zachrániť pred sebou samými! Inými slovami, tajná otázka by mala určiť samotná stránka, a ešte lepšie, klásť sériu tajných otázok, z ktorých si môže používateľ vybrať. A nie len vybrať jednu; ideálne by si používateľ mal vybrať dve alebo viac tajných otázok pri registrácii účtu., ktoré sa následne použijú ako druhý kanál identifikácie. Prítomnosť viacerých otázok zvyšuje úroveň dôvery v procese overovania a tiež umožňuje pridanie náhodnosti (neukazovať stále rovnakú otázku), a navyše zabezpečuje určitú redundanciu v prípade, ak skutočný používateľ zabudol heslo.
Aký by mal byť dobrý tajný otázok? Na to vplýva niekoľko faktorov:
- Mal by byť stručný — otázka by mala byť jasná a jednoznačná.
- Odpoveď by mala byť konkrétna — nepotrebujeme otázku, na ktorú môže odpovedať rôzne jeden človek
- Možné odpovede by mali byť rozmanité — otázka o niečej obľúbenej farbe poskytuje veľmi malé podmnožstvo možných odpovedí.
- Hľadanie odpovede by malo byť zložité — ak môže odpoveď ľahko nájsť ktokoľvek (spomeňme na ľudí na vysokých pozíciách), taká odpoveď je zlá.
- Odpoveď by mala byť stála v čase — ak sa pýtaš na niečí obľúbený film, odpoveď sa môže po roku zmeniť.
Ako to býva, existuje webová stránka venovaná dobrým otázkam, ktorá sa volá . Niektoré otázky sa zdajú byť celkom dobré, iné neprejdú časťou uvedených testov, najmä testom „jednoduchosti hľadania“.
Dovoľte mi predviesť, ako sú tajné otázky implementované v PayPal a aké úsilie stránka vynakladá na identifikáciu. Vyššie sme videli stránku začatia procesu (s CAPTCHA), a tu ukážeme, čo sa deje po zadaní e-mailovej adresy a vyriešení CAPTCHA:
V dôsledku toho používateľ dostane takéto písmeno:
Zatiaľ je všetko celkom bežné, ale tu je to, čo sa skrýva za týmto URL na resetovanie:
Takže do hry vstupujú tajné otázky. V skutočnosti PayPal umožňuje aj resetovanie hesla, potvrdením čísla kreditnej karty, takže existuje ďalší kanál, ku ktorému nemá prístup mnoho stránok. Proste nemôžem zmeniť heslo, pokiaľ neodpoviem na obidve tajné otázky (alebo neviem číslo karty). Aj keď niekto získa mojich e-mail, nebude môcť resetovať heslo účtu PayPal, ak nevie o mne o niečo viac osobných informácií. Aké informácie? Tu sú možnosti tajných otázok, ktoré ponúka PayPal:
Otázka školy a nemocnice môže byť mierne pochybná z hľadiska jednoduchosti vyhľadávania, ale ostatné nie sú tak zlé. Napriek tomu, na zvýšenie bezpečnosti PayPal vyžaduje dodatočnú identifikáciu pre zmeny odpovede na tajné otázky:
PayPal je dosť utopickým príkladom bezpečného resetovania hesla: implementuje CAPTCHA na zníženie rizika hrubej sily, vyžaduje dve tajné otázky a potom si vyžaduje ďalší druh úplne inej identifikácie len na zmenu odpovedí — a to po tom, čo sa používateľ už prihlásil. Samozrejme, presne to sme očakávali od PayPal; je to finančná organizácia, ktorá pracuje s veľkými súmami peňazí. Neznamená to, že každý reset hesla by mal nasledovať tieto kroky — v mnohých prípadoch je to zbytočné — avšak je to dobrý príklad pre prípady, keď je bezpečnosť vážnym biznisom.
Pohodlie systému tajných otázok spočíva v tom, že ak ste ho neinštalovali hneď, môžete ho pridať neskôr, ak to úroveň ochrany zdroja vyžaduje. Dobrou ukážkou toho je Apple, ktorá tento mechanizmus nedávno implementovala [článok bol napísaný v roku 2012]. Keď som raz začal aktualizovať aplikáciu na iPade, videl som nasledujúcu žiadosť:
Potom som videl obrazovku, na ktorej sme mohli vybrať niekoľko párov tajných otázok a odpovedí, ako aj záchrannú e-mailovú adresu:
Pokiaľ ide o PayPal, otázky sú vybrané vopred a niektoré z nich sú naozaj dosť dobré:
Každý z troch párov otázok a odpovedí predstavuje samostatnú množinu možných otázok, takže existuje dostatočné množstvo spôsobov konfigurácie účtu.
Ešte jedným aspektom, ktorý treba zvážiť v súvislosti s odpoveďou na tajnú otázku, je uchovávanie. Uloženie v DB jednoduchého textu predstavuje takmer rovnaké hrozby ako v prípade hesla, konkrétne — odhalenie databázy okamžite odhalí hodnotu a vystaví riziku nielen aplikáciu, ale aj potenciálne úplne iné aplikácie, ktoré používajú rovnaké tajné otázky (to je opäť ). Jednou z možností je bezpečné hashování (odolný algoritmus a cryptograficky náhodná sůl), avšak na rozdíl od většiny případů uložených hesel může existovat oprávněný důvod viditelnosti odpovědi jako prostého textu. Typickým scénářem je ověření identity živým operátorem po telefonu. Samozřejmě, v tomto případě je hashování také použitelné (operátor může jednoduše zadat odpověď, kterou klient uvedl), ale v nejhorším případě by tajná odpověď měla být na nějaké úrovni kryptografického úložiště, i když to bude jen symetrické šifrování. Shrňme to: nakládejte s tajemstvími jako s tajemstvími!
A posledním aspektem tajných otázek a odpovědí je, že jsou více zranitelné vůči sociálnímu inženýrství. Snažit se přímo vymámit heslo někoho jiného je jedna věc, ale zahájit rozhovor o jeho vzdělání (populární tajná otázka) je úplně jiná. Ve skutečnosti můžete skutečně komunikovat s někým o mnoha aspektech jeho života, které mohou tvořit tajnou otázku, a aniž byste vyvolávali podezření. Samozřejmě, že podstatou tajné otázky je, že je spojena s někým životním zážitkem, takže si ji pamatuje, a v tom spočívá problém - lidé rádi vyprávějí o svých životních zkušenostech! S tím se toho moc dělat nedá, pokud si nevyberete takové možnosti tajných otázek, které by s menší
pravděpodobností mohl být odcizen pomocí sociálního inženýrství.
Na základe reklamy
VDSina nabízí spolehlivé , 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
