Nedávno som mal čas znova premýšľať o tom, ako by mala fungovať funkcia bezpečného obnovenia hesla, najskôr keď som túto funkciu zabudoval , a potom, keď pomohol inej osobe urobiť niečo podobné. V druhom prípade som mu chcel dať odkaz na kanonický zdroj so všetkými podrobnosťami o tom, ako bezpečne implementovať funkciu reset. Problém je však v tom, že takýto zdroj neexistuje, aspoň nie taký, ktorý by popisoval všetko, čo sa mi zdá dôležité. Rozhodol som sa ho teda napísať sám.
Vidíte, svet zabudnutých hesiel je v skutočnosti dosť tajomný. Existuje mnoho rôznych, úplne prijateľných uhlov pohľadu a mnoho dosť nebezpečných. Je pravdepodobné, že ste sa s každým z nich ako koncový používateľ stretli mnohokrát; takže sa pokúsim použiť tieto príklady, aby som ukázal, kto to robí správne, kto nie a na čo sa musíte zamerať, aby ste túto funkciu dostali do svojej aplikácie.
Ukladanie hesiel: hashovanie, šifrovanie a (vzdych!) obyčajný text
Nemôžeme diskutovať o tom, čo robiť so zabudnutými heslami, kým sa nezaoberáme tým, ako ich uložiť. Heslá sú v databáze uložené v jednom z troch hlavných typov:
- Jednoduchý text. Nachádza sa tu stĺpec s heslom, ktorý je uložený vo forme obyčajného textu.
- Zašifrované. Zvyčajne sa používa symetrické šifrovanie (jeden kľúč sa používa na šifrovanie aj dešifrovanie) a šifrované heslá sú tiež uložené v rovnakom stĺpci.
- Hašované. Jednosmerný proces (heslo môže byť hašované, ale nemôže byť dehašované); heslo, Chcel by som dúfať, nasleduje soľ a každá je vo vlastnom stĺpci.
Poďme rovno k najjednoduchšej otázke: Nikdy neukladajte heslá ako obyčajný text! Nikdy. Jedna jediná zraniteľnosť voči , jedna neopatrná záloha alebo jedna z desiatok ďalších jednoduchých chýb – a to je všetko, koniec hry, všetky vaše heslá – to znamená, prepáčte, heslá všetkých vašich klientov sa stane verejnou doménou. To by samozrejme znamenalo veľkú pravdepodobnosť, že zo všetkých svojich účtov v iných systémoch. A bude to vaša chyba.
Šifrovanie je lepšie, ale má svoje slabiny. Problém so šifrovaním je dešifrovanie; môžeme vziať tieto šialene vyzerajúce šifry a previesť ich späť na obyčajný text, a keď sa to stane, vrátime sa do situácie hesiel čitateľných pre ľudí. Ako sa to stane? Do kódu, ktorý dešifruje heslo, sa dostane malá chybička, ktorá ho sprístupní verejnosti – toto je jeden zo spôsobov. Hackeri získajú prístup k stroju, na ktorom sú uložené zašifrované dáta – ide o druhý spôsob. Ďalším spôsobom je opäť ukradnutie zálohy databázy a niekto získa aj šifrovací kľúč, ktorý je často uložený veľmi neisto.
A to nás privádza k hashovaniu. Myšlienka hašovania je, že je jednosmerný; jediný spôsob, ako porovnať heslo zadané používateľom s jeho hašovanou verziou, je hashovať vstup a porovnať ich. Aby sme zabránili útokom z nástrojov, ako sú dúhové tabuľky, osolíme proces náhodnosťou (prečítajte si môj o kryptografickom ukladaní). Nakoniec, ak sú implementované správne, môžeme si byť istí, že hashované heslá sa už nikdy nestanú obyčajným textom (o výhodách rôznych hashovacích algoritmov budem hovoriť v inom príspevku).
Rýchly argument o hašovaní vs. šifrovanie: jediný dôvod, prečo by ste niekedy potrebovali heslo radšej zašifrovať ako hašovať, je, keď potrebujete heslo vidieť ako obyčajný text a toto by si nikdy nemal chcieť, aspoň v štandardnej situácii na webe. Ak to potrebujete, potom s najväčšou pravdepodobnosťou robíte niečo zle!
Varovanie!
Nižšie v texte príspevku je časť screenshotu pornografickej stránky AlotPorn. Je úhľadne zostrihaný, takže na pláži nie je nič, čo by ste nevideli, no ak je stále pravdepodobné, že spôsobí nejaké problémy, neskrolujte nižšie.
Vždy obnovte svoje heslo nikdy nepripomínaj mu to
Boli ste niekedy požiadaní o vytvorenie funkcie? upomienky heslo? Urobte krok späť a zamyslite sa nad touto požiadavkou naopak: prečo je toto „pripomenutie“ potrebné? Pretože používateľ zabudol heslo. Čo vlastne chceme robiť? Pomôžte mu prihlásiť sa znova.
Uvedomujem si, že slovo „pripomenutie“ sa používa (často) v hovorovom zmysle, ale v skutočnosti sa o to snažíme bezpečne pomôcť používateľovi byť opäť online. Keďže potrebujeme bezpečnosť, existujú dva dôvody, prečo nie je vhodné pripomenutie (t. j. zaslanie hesla používateľovi):
- E-mail je nezabezpečený kanál. Rovnako ako by sme neposielali nič citlivé cez HTTP (použili by sme HTTPS), nemali by sme posielať nič citlivé cez e-mail, pretože jeho transportná vrstva je nezabezpečená. V skutočnosti je to oveľa horšie ako jednoduché odosielanie informácií cez nezabezpečený transportný protokol, pretože pošta je často uložená na úložnom zariadení, prístupná správcom systému, posielaná ďalej a distribuovaná, prístupná malvéru atď. Nešifrovaný e-mail je extrémne nezabezpečený kanál.
- Aj tak by ste nemali mať prístup k heslu. Znovu si prečítajte predchádzajúcu časť o ukladaní – mali by ste mať heslo hash (s dobrou silnou soľou), čo znamená, že by ste nemali byť schopní žiadnym spôsobom získať heslo a poslať ho poštou.
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 vás tiež vyzve na zaslanie hesla („Odoslať heslo“). Toto môže byť príklad hovorového používania výrazu uvedeného vyššie, takže poďme o krok ďalej a uvidíme, čo sa stane:
Nanešťastie to nevyzerá oveľa lepšie; a e-mail s potvrdením, že sa vyskytol problém:
To nám hovorí o dvoch dôležitých aspektoch stránky usoutdoor.com:
- Stránka nehašuje heslá. V najlepšom prípade sú zašifrované, ale je pravdepodobné, že sú uložené ako obyčajný text; Nevidíme žiadne dôkazy o opaku.
- Stránka posiela dlhodobé heslo (môžeme sa vrátiť a použiť ho znova a znova) cez nezabezpečený kanál.
Keď to prekáža, musíme skontrolovať, či je proces resetovania vykonaný bezpečným spôsobom. Prvým krokom k tomu je uistiť sa, že žiadateľ má právo vykonať reset. Inými slovami, predtým potrebujeme kontrolu identity; pozrime sa, čo sa stane, keď sa overí identita bez toho, aby sme najprv overili, že žiadateľ je skutočne vlastníkom účtu.
Výpis používateľských mien a jeho vplyv na anonymitu
Tento problém je najlepšie ilustrovať vizuálne. problém:
Vidíš? Venujte pozornosť správe „S touto e-mailovou adresou nie je zaregistrovaný žiadny používateľ“. Problém očividne nastáva, ak takáto stránka potvrdí dostupnosť používateľ zaregistrovaný s takouto e-mailovou adresou. Bingo – práve ste objavili pornofetiš svojho manžela/šéfa/suseda!
Samozrejme, porno je pomerne ikonickým príkladom dôležitosti súkromia, ale nebezpečenstvo spájania jednotlivca s konkrétnou webovou stránkou je oveľa širšie ako potenciálne nepríjemná situácia opísaná vyššie. Jedným nebezpečenstvom je sociálne inžinierstvo; Ak útočník dokáže priradiť osobu k službe, bude mať informácie, ktoré môže začať používať. Môže napríklad kontaktovať osobu, ktorá sa vydáva za zástupcu webovej stránky, a vyžiadať si dodatočné informácie v snahe o spáchanie .
Takéto praktiky tiež zvyšujú nebezpečenstvo „vyčíslenia používateľských mien“, pričom je možné overiť existenciu celej zbierky používateľských mien alebo e-mailových adries na webovej stránke jednoduchým vykonaním skupinových dotazov a skúmaním odpovedí na ne. Máte zoznam e-mailových adries všetkých zamestnancov a pár minút na napísanie skriptu? Potom uvidíte, v čom je problém!
Aká je alternatíva? V skutočnosti je to celkom jednoduché a úžasne implementované :
Tu Entropay nezverejňuje absolútne nič o existencii e-mailovej adresy vo svojom systéme niekomu, kto túto adresu nevlastní... Ak ty vlastné túto adresu a neexistuje v systéme, potom dostanete e-mail, ako je tento:
Samozrejme, môžu nastať prijateľné situácie, v ktorých niekto myslí siže ste sa zaregistrovali na webovej stránke. ale nie je to tak, alebo som to urobil z inej e-mailovej adresy. Vyššie uvedený príklad dobre zvláda obe situácie. Je zrejmé, že ak sa adresa zhoduje, dostanete e-mail, ktorý vám uľahčí obnovenie hesla.
Jemnosť riešenia zvoleného spoločnosťou Entropay spočíva v tom, že overenie identifikácie sa vykonáva podľa e-mailom pred akýmkoľvek online overením. Niektoré stránky žiadajú používateľov o odpoveď na bezpečnostnú otázku (viac o tom nižšie) na ako môže začať reset; problém je však v tom, že na otázku musíte odpovedať a zároveň poskytnúť určitú formu identifikácie (e-mail alebo používateľské meno), čo potom takmer znemožňuje intuitívne odpovedať bez odhalenia existencie účtu anonymného používateľa.
S týmto prístupom existuje malý znížená použiteľnosť, pretože ak sa pokúsite resetovať neexistujúci účet, nedostanete okamžitú spätnú väzbu. Samozrejme, to je celý zmysel odosielania e-mailu, ale z pohľadu skutočného koncového používateľa, ak zadá nesprávnu adresu, prvýkrát sa to dozvie, až keď e-mail dostane. To môže spôsobiť určité napätie z jeho strany, ale je to malá cena za taký zriedkavý proces.
Ďalšia poznámka, mierne mimo témy: rovnaký problém majú funkcie pomoci pri prihlásení, ktoré odhalia, či je používateľské meno alebo e-mailová adresa správne. Vždy odpovedzte používateľovi správou „Kombinácia vášho používateľského mena a hesla je neplatná“, namiesto toho, aby ste výslovne potvrdili existenciu poverení (napríklad „používateľské meno je správne, ale heslo je nesprávne“).
Odoslanie hesla na obnovenie vs odoslanie adresy URL na obnovenie
Ďalším konceptom, ktorý musíme prediskutovať, je spôsob obnovenia hesla. Existujú dve populárne riešenia:
- Vygenerovanie nového hesla na serveri a jeho odoslanie e-mailom
- Pošlite e-mail s jedinečnou adresou URL, aby ste uľahčili proces resetovania
Cez , prvý bod by sa nikdy nemal používať. Problém je v tom, že to znamená, že existuje uložené heslo, ku ktorému sa môžete kedykoľvek vrátiť a znova ho použiť; bol odoslaný cez nezabezpečený kanál a zostáva vo vašej doručenej pošte. Je pravdepodobné, že priečinky doručenej pošty sú synchronizované medzi mobilnými zariadeniami a e-mailovým klientom a navyše môžu byť uložené online vo webovej e-mailovej službe na veľmi dlhú dobu. Ide o to, že poštovú schránku nemožno považovať za spoľahlivý prostriedok dlhodobého uloženia.
Ale okrem toho má prvý bod ešte jeden vážny problém – to čo najviac zjednodušiť zablokovanie účtu so zlým úmyslom. Ak poznám e-mailovú adresu niekoho, kto vlastní účet na webovej stránke, môžem ho kedykoľvek zablokovať jednoduchým obnovením hesla; Toto je útok odmietnutia služby naservírovaný na striebornom podnose! Z tohto dôvodu by sa mal reset vykonať až po úspešnom overení práv žiadateľa naň.
Keď hovoríme o resetovanej adrese URL, máme na mysli adresu webovej stránky, ktorá je jedinečné pre tento konkrétny prípad procesu resetovania. Samozrejme, mal by byť náhodný, nemal by sa dať ľahko uhádnuť a nemal by obsahovať žiadne externé odkazy na účet, ktoré uľahčujú jeho resetovanie. Napríklad adresa URL na obnovenie by nemala byť jednoducho cestou ako „Reset/?username=JohnSmith“.
Chceme vytvoriť jedinečný token, ktorý možno poslať poštou ako adresu URL na obnovenie a potom ho porovnať so záznamom účtu používateľa na serveri, čím sa potvrdí, že vlastník účtu je v skutočnosti tá istá osoba, ktorá sa pokúša obnoviť heslo . Napríklad token by mohol byť „3ce7854015cd38c862cb9e14a1ae552b“ a uložený v tabuľke spolu s ID používateľa, ktorý vykonal reset, a časom vygenerovania tokenu (viac o tom nižšie). Keď je e-mail odoslaný, obsahuje URL ako „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, a keď si ho používateľ stiahne, stránka vyzve na existenciu tokenu, potom potvrdí informácie používateľa a umožní mu zmeniť heslo.
Samozrejme, keďže vyššie uvedený proces (dúfajme) umožňuje používateľovi vytvoriť si nové heslo, musíme zabezpečiť, aby sa adresa URL načítala cez HTTPS. nie, , táto adresa URL tokenu musí používať zabezpečenie transportnej vrstvy, aby nový formulár hesla nemohol byť napadnutý a heslo vytvorené používateľom bolo prenesené cez zabezpečené pripojenie.
Pre resetovaciu adresu URL musíte tiež pridať časový limit tokenu, aby sa proces resetovania mohol dokončiť v určitom intervale, povedzme do hodiny. To zaisťuje, že časové okno resetovania je obmedzené na minimum, takže príjemca adresy URL na resetovanie môže konať iba v rámci tohto veľmi malého okna. Útočník môže samozrejme spustiť proces resetovania znova, ale bude musieť získať inú jedinečnú adresu URL na resetovanie.
Nakoniec musíme zabezpečiť, aby bol tento proces jednorazový. Po dokončení procesu resetovania je potrebné odstrániť token, aby adresa URL na resetovanie už nebola funkčná. Predchádzajúci bod je potrebný na to, aby mal útočník k dispozícii veľmi malé okno, počas ktorého môže manipulovať s resetovanou URL. Navyše, keď je reset úspešný, token už nie je potrebný.
Niektoré z týchto krokov sa môžu zdať príliš nadbytočné, ale nezasahujú do použiteľnosti a v skutočnosti zlepšiť bezpečnosť, aj keď v situáciách, o ktorých dúfame, že budú zriedkavé. V 99 % prípadov používateľ povolí reset vo veľmi krátkom čase a v blízkej budúcnosti už heslo nebude resetovať.
Úloha CAPTCHA
Ach, CAPTCHA, bezpečnostná funkcia, ktorú všetci radi nenávidíme! V skutočnosti CAPTCHA nie je ani tak ochranný nástroj, ako skôr identifikačný nástroj – či už ste osoba alebo robot (alebo automatizovaný skript). Jeho účelom je vyhnúť sa automatickému odosielaniu formulárov, ktoré, samozrejme, plechovka použiť ako pokus o prelomenie zabezpečenia. V súvislosti s resetovaním hesla CAPTCHA znamená, že funkciu resetovania nie je možné hrubo vynútiť, aby spamovala používateľa alebo sa pokúsila zistiť existenciu účtov (čo, samozrejme, nebude možné, ak budete postupovať podľa rád v časti o overovanie totožnosti).
Samozrejme, samotná CAPTCHA nie je dokonalá; Existuje mnoho precedensov pre jeho softvérové „hackovanie“ a dosahovanie dostatočnej úspešnosti (60 – 70 %). Okrem toho existuje riešenie uvedené v mojom príspevku o , kde môžete ľuďom zaplatiť zlomky centov za vyriešenie každej CAPTCHA a dosiahnuť úspešnosť 94 %. To znamená, že je zraniteľný, ale (mierne) zvyšuje bariéru vstupu.
Pozrime sa na príklad PayPal:
V tomto prípade proces resetovania jednoducho nemôže začať, kým sa nevyrieši CAPTCHA, takže teoreticky nie je možné automatizovať proces. Teoreticky.
Pre väčšinu webových aplikácií to však bude prehnané a úplnú pravdu predstavuje zníženie použiteľnosti - ľudia jednoducho nemajú radi CAPTCHA! CAPTCHA je navyše niečo, ku ktorému sa v prípade potreby môžete jednoducho vrátiť. Ak služba začne byť napadnutá (to je miesto, kde sa logovanie hodí, ale o tom neskôr), potom pridanie CAPTCHA nemôže byť jednoduchšie.
Tajné otázky a odpovede
So všetkými metódami, ktoré sme zvážili, sa nám podarilo obnoviť heslo len tým, že sme mali prístup k e-mailovému účtu. Hovorím „len“, ale, samozrejme, je nezákonné získať prístup k e-mailovému účtu niekoho iného. mušt byť zložitý proces. Avšak .
V skutočnosti vyššie uvedený odkaz o hackovaní Yahoo! Sarah Palinovej! slúži na dva účely; po prvé, ukazuje, aké ľahké je hacknúť (niektoré) e-mailové účty, a po druhé, ukazuje, ako sa dajú zlé bezpečnostné otázky použiť so zlým úmyslom. Ale k tomu sa vrátime neskôr.
Problém so XNUMX% resetovaním hesla na základe e-mailu je v tom, že integrita účtu pre stránku, ktorú sa pokúšate obnoviť, sa stáva XNUMX% závislou od integrity e-mailového účtu. Každý, kto má prístup k vášmu e-mailu má prístup k akémukoľvek účtu, ktorý možno obnoviť 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 bezpečnostných otázok a odpovedí. Nepochybne ste ich už videli: vyberte si otázku, na ktorú môžete odpovedať len vy mušt poznať odpoveď a potom, keď si resetujete heslo, budete o to požiadaní. To zvyšuje istotu, že osoba, ktorá sa pokúša o reset, je skutočne vlastníkom účtu.
Späť k Sarah Palinovej: chyba bola v tom, že odpovede na jej bezpečnostnú otázku/otázky sa dali ľahko nájsť. Najmä ak ste taká významná verejná osobnosť, informácie o rodnom mene vašej matky, histórii vzdelania alebo tom, kde niekto mohol žiť v minulosti, nie sú až také tajné. V skutočnosti väčšinu z nich môže nájsť takmer každý. Toto sa stalo Sarah:
Hacker David Kernell získal prístup k Palinmu účtu tak, že zistil podrobnosti o jej pôvode, ako je jej univerzita a dátum narodenia, a potom použil funkciu obnovenia zabudnutého hesla od Yahoo!.
V prvom rade ide o konštrukčnú chybu zo strany Yahoo! — špecifikovaním takýchto jednoduchých otázok spoločnosť v podstate sabotovala hodnotu bezpečnostnej otázky, a tým aj ochranu svojho systému. Samozrejme, resetovanie hesiel k e-mailovému účtu je vždy náročnejšie, keďže vlastníctvo nemôžete preukázať odoslaním e-mailu majiteľovi (bez toho, aby ste mali druhú adresu), ale našťastie dnes už na vytvorenie takéhoto systému nie je veľa možností.
Vráťme sa k bezpečnostným otázkam – je tu možnosť umožniť užívateľovi vytvárať si vlastné otázky. Problém je v tom, že to bude mať za následok strašne jasné otázky:
Akú farbu má obloha?
Otázky, ktoré sú pre ľudí nepríjemné, keď sa na identifikáciu používa bezpečnostná otázka ľudia (napríklad v call centre):
S kým som spal na Vianoce?
Alebo úprimne hlúpe otázky:
Ako sa píše „heslo“?
Pokiaľ ide o bezpečnostné otázky, používatelia musia byť chránení pred sebou samými! Inými slovami, bezpečnostnú otázku by mala určiť samotná stránka, alebo ešte lepšie, položená série bezpečnostné otázky, z ktorých si používateľ môže vybrať. A nie je ľahké si vybrať jeden; v ideálnom prípade by mal používateľ vybrať dve alebo viac bezpečnostných otázok v čase registrácie účtu, ktorý sa potom použije ako druhý identifikačný kanál. Položenie viacerých otázok zvyšuje dôveru v proces overovania a tiež poskytuje možnosť pridať náhodnosť (nie vždy zobrazuje rovnakú otázku) a navyše poskytuje trochu redundancie v prípade, že skutočný používateľ zabudol heslo.
Čo je dobrá bezpečnostná otázka? To je ovplyvnené niekoľkými faktormi:
- To by malo byť stručný — otázka musí byť jasná a jednoznačná.
- Odpoveď musí byť špecifický – nepotrebujeme otázku, na ktorú môže jeden človek odpovedať inak
- Možné odpovede by mali byť rôznorodé - spýtať sa niekoho na obľúbenú farbu poskytuje veľmi malú podmnožinu možných odpovedí
- vyhľadávanie odpoveď musí byť zložitá – ak sa dá odpoveď ľahko nájsť každý (pamätajte na ľudí vo vysokých funkciách), vtedy je zlý
- Odpoveď musí byť DC v čase - ak sa spýtate niekoho na obľúbený film, o rok neskôr môže byť odpoveď iná
Ako sa to stáva, existuje webová stránka, ktorá sa venuje kladeniu dobrých otázok . Niektoré z otázok sa zdajú celkom dobré, iné nevyhovujú niektorým z vyššie popísaných testov, najmä testu „jednoduchosti vyhľadávania“.
Dovoľte mi ukázať, ako PayPal implementuje bezpečnostné otázky a najmä úsilie, ktoré stránka vynakladá na overenie. Vyššie sme videli stránku na spustenie procesu (s CAPTCHA) a tu ukážeme, čo sa stane, keď zadáte svoju e-mailovú adresu a vyriešite CAPTCHA:
Výsledkom je, že používateľ dostane nasledujúci list:
Zatiaľ je všetko celkom normálne, ale za touto resetovanou adresou URL sa skrýva toto:
Do hry teda vstupujú bezpečnostné otázky. Služba PayPal vám v skutočnosti umožňuje obnoviť heslo overením čísla vašej kreditnej karty, takže existuje ďalší kanál, ku ktorému mnohé stránky nemajú prístup. Bez odpovede si jednoducho nemôžem zmeniť heslo oba bezpečnostná otázka (alebo neznalosť čísla karty). Aj keby mi niekto uniesol e-mail, nedokázal by mi obnoviť heslo k účtu PayPal, pokiaľ by o mne nevedel trochu viac osobných údajov. aké informácie? Tu sú možnosti bezpečnostných otázok, ktoré PayPal ponúka:
Otázka týkajúca sa školy a nemocnice môže byť trochu problematická, pokiaľ ide o jednoduché vyhľadávanie, ale ostatné nie sú také zlé. Na zvýšenie bezpečnosti však PayPal vyžaduje dodatočnú identifikáciu zmeny odpovede na bezpečnostné otázky:
PayPal je dosť utopický príklad bezpečného resetovania hesla: implementuje CAPTCHA na zníženie nebezpečenstva útokov hrubou silou, vyžaduje dve bezpečnostné otázky a potom vyžaduje iný druh úplne inej identifikácie, len aby zmenil odpovede – a to po používateľovi sa už prihlásil. Samozrejme, presne toto sme my očakávané z PayPal; je finančná inštitúcia, ktorá obchoduje s veľkými sumami peňazí. Neznamená to, že pri každom resetovaní hesla sa musí postupovať podľa týchto krokov – väčšinou je to prehnané – ale je to dobrý príklad pre prípady, keď je bezpečnosť vážna záležitosť.
Výhodou systému bezpečnostných otázok je, že ak ste ho neimplementovali hneď, môžete ho pridať neskôr, ak si to vyžaduje úroveň ochrany zdrojov. Dobrým príkladom toho je Apple, ktorý tento mechanizmus implementoval len nedávno [článok napísaný v roku 2012]. Keď som začal aktualizovať aplikáciu na svojom iPade, videl som nasledujúcu požiadavku:
Potom som videl obrazovku, kde som mohol vybrať niekoľko párov bezpečnostných otázok a odpovedí, ako aj záchrannú e-mailovú adresu:
Pokiaľ ide o PayPal, otázky sú vopred vybraté a niektoré z nich sú v skutočnosti celkom dobré:
Každá z troch párov otázok a odpovedí predstavuje inú skupinu možných otázok, takže existuje veľa spôsobov, ako konfigurovať účet.
Ďalším aspektom, ktorý je potrebné zvážiť pri odpovedi na vašu bezpečnostnú otázku, je úložisko. Mať databázu s obyčajným textom v databáze predstavuje takmer rovnakú hrozbu ako heslo, konkrétne, že odhalenie databázy okamžite odhalí hodnotu a ohrozí nielen aplikáciu, ale potenciálne úplne odlišné aplikácie používajúce rovnaké bezpečnostné otázky (opäť tu ). Jednou z možností je bezpečné hashovanie (silný algoritmus a kryptograficky náhodná soľ), ale na rozdiel od väčšiny prípadov ukladania hesiel môže existovať dobrý dôvod, prečo je odpoveď viditeľná ako obyčajný text. Typickým scenárom je overenie identity živým telefónnym operátorom. Hašovanie je samozrejme použiteľné aj v tomto prípade (operátor môže jednoducho zadať odpoveď pomenovanú klientom), ale v najhoršom prípade musí byť tajná odpoveď umiestnená na určitej úrovni kryptografického úložiska, aj keď ide len o symetrické šifrovanie. . zhrnúť: zaobchádzajte s tajomstvami ako s tajomstvami!
Posledným aspektom bezpečnostných otázok a odpovedí je, že sú zraniteľnejšie voči sociálnemu inžinierstvu. Pokúsiť sa priamo získať heslo na účet niekoho iného je jedna vec, ale začať konverzáciu o jeho vytvorení (obľúbená bezpečnostná otázka) je úplne iná. V skutočnosti môžete s niekým veľmi dobre komunikovať o mnohých aspektoch jeho života, ktoré môžu predstavovať tajnú otázku bez vzbudenia podozrenia. Samozrejme, podstatou bezpečnostnej otázky je, že súvisí s niečím životným zážitkom, takže je zapamätateľná a v tom je problém – ľudia radi hovoria o svojich životných skúsenostiach! S tým môžete urobiť len málo, iba ak zvolíte také možnosti bezpečnostnej otázky, aby boli menej by sa pravdepodobne dalo vytiahnuť sociálnym inžinierstvom.
[Pokračovanie nabudúce.]O právach reklamy
VDSina ponúka spoľahlivé , každý server je pripojený k internetovému kanálu 500 megabitov a je chránený pred DDoS útokmi zadarmo!
Zdroj: hab.com