Nedávno jsem měl čas znovu přemýšlet o tom, jak by měla fungovat funkce bezpečného resetování hesla, nejprve když jsem tuto funkčnost integroval do , a pak když jsem pomáhal udělat něco podobného jinému člověku. Ve druhém případě jsem chtěl poskytnout odkaz na kanonický zdroj se všemi podrobnostmi o bezpečné implementaci funkce resetování. Problém je, že takový zdroj neexistuje, alespoň ne takový, který by popisoval vše, co považuji za důležité. Proto jsem se rozhodl napsat jej sám.
Vidíte, svět zapomenutých hesel je ve skutečnosti docela záhadný. Existuje mnoho různých, zcela přijatelných názorů a spousta docela nebezpečných. Je pravděpodobné, že se s každým z nich setkáváte jako koncový uživatel mnohokrát; proto se pokusím využít těchto příkladů, abych ukázal, kdo to dělá správně a kdo ne, a na co je třeba se soustředit pro správnou implementaci funkce ve své aplikaci.
Ukládání hesel: hashování, šifrování a (och!) prostý text
Nemůžeme diskutovat o tom, co dělat se zapomenutými hesly, dokud neprobereme způsob jejich ukládání. V databázi jsou hesla ukládána v jednom ze tří hlavních způsobů:
- Prostý text. Existuje sloupec s heslem, které je uloženo v běžném textovém formátu.
- Šifrované. Obvykle pomocí symetrického šifrování (jeden klíč se používá jak pro šifrování, tak pro dešifrování), a šifrovaná hesla jsou také uložena v jednom sloupci.
- Hashované. Jednosměrný proces (heslo lze hashnout, ale nelze dehasherovat); heslo, doufejme,je doplněno solí, a každé z nich se nachází v samostatném sloupci.
Pojďme se hned zabývat tím nejjednodušším dotazem: nikdy neukládejte hesla v prostém textu! Nikdy. Jediná zranitelnost vůči , jedna neopatrně vytvořená záloha nebo jedna z desítek dalších jednoduchých chyb — a je konec, game over, všechna vaše hesla — tedy, promiňte, hesla všech vašich klientů se stanou veřejným majetkem. Samozřejmě to bude znamenat obrovskou pravděpodobnost, že veřejným majetkem se stanou ze všech jejich účtů v jiných systémech. A to bude vaše chyba.
Šifrování je lepší, ale má své slabiny. Problém šifrování spočívá v dešifrování; můžete vzít tyto šíleně vypadající šifry a převést je zpět do jednoduchého textu, a když k tomu dojde, vrátíme se do situace s čitelnými hesly. Jak se to stane? Malá chyba pronikne do kódu, který se zabývá dešifrováním hesla, a udělá ho veřejně dostupným — to je jeden způsob. Hackeři získají přístup k počítači, na kterém jsou uložena šifrovaná data — to je druhý způsob. Další způsob je, že ukradnou zálohu databáze a někdo také získá šifrovací klíč, který se často uchovává velmi nespolehlivě.
A to nás přivádí k hashování. Myšlenka hashování spočívá v tom, že funguje jednosměrně; jediný způsob, jak porovnat uživatelem zadané heslo s jeho hashovanou verzí, je hashování zadaného hesla a jejich porovnání. Abychom zabránili útokům pomocí nástrojů jako 'duhové tabulky', přidáváme do procesu pomocí soli náhodnost (pro úplnost si přečtěte můj o kryptografickém úložišti). V konečném důsledku, při správné implementaci můžeme s velkou mírou jistoty tvrdit, že hashovaná hesla se už nikdy nestanou jasným textem (o výhodách různých hashovacích algoritmů budu mluvit v jiném příspěvku).
Krátký argument o hashování a šifrování: jediný důvod, proč byste někdy potřebovali zašifrovat, místo hashování hesla — je to, když potřebujete vidět heslo v jasném textu, a to byste nikdy neměli chtít, alespoň pokud jde o standardní webovou stránku. Pokud to potřebujete, je velmi pravděpodobné, že děláte něco špatně!
Pozor!
Kousek níže v textu příspěvku je část screenshotu pornografické webové stránky AlotPorn. Je pečlivě oříznuta, takže není nic takového, co byste nemohli vidět na pláži, ale pokud to stejně může způsobit nějaké problémy, neprocházejte stránku dolů.
Vždy resetujte heslo, nikdy nepřipomínejte ho
Byli jste někdy požádáni, abyste vytvořili funkci připomínání Hesla? Udělejte krok zpět a zamyslete se nad touto žádostí obráceně: proč potřebujeme toto „připomenutí“? Protože uživatel zapomněl heslo. Co vlastně chceme udělat? Pomoci mu znovu se přihlásit do systému.
Chápu, že slovo „připomenutí“ se používá (často) v hovorovém smyslu, ale ve skutečnosti se snažíme bezpečně pomoci uživateli opět být online. Protože potřebujeme bezpečnost, existují dva důvody, proč připomenutí (tj. zaslat uživateli jeho heslo) není vhodné:
- E-mail je nes bezpečný kanál. Stejně jako bychom nepřenášeli nic důvěrného po HTTP (použili bychom HTTPS), neměli bychom přenášet nic prostřednictvím e-mailu, protože jeho transportní vrstva není bezpečná. Ve skutečnosti je to mnohem horší než prostý přenos informací po nezabezpečeném transportním protokolu, protože e-mail je často ukládán na disk, dostupný systémovým administrátorům, přeposílán a šířen, přístupný škodlivému softwaru, atd. Nezašifrovaný e-mail je extrémně nezabezpečený kanál.
- V každém případě byste neměli mít přístup k heslu. Přečtěte si předchozí sekci o ukládání – měli byste mít hash hesla (s dobrou silnou solí), to znamená, že za žádných okolností byste neměli mít možnost vyjmout heslo a zaslat ho e-mailem.
Dovolte mi ukázat problém na příkladu : Tady je typická přihlašovací stránka:
Je zřejmé, že první problém spočívá v tom, že přihlašovací stránka se nenahrává přes HTTPS, ale navíc stránka nabízí zaslat heslo („Send Password“). Možná je to příklad výše zmíněného hovorového použití tohoto termínu, proto udělejme ještě jeden krok a podívejme se, co se stane:
Bohužel to nevypadá o moc lépe; a e-mail potvrzuje existenci problému:
To nám říká dvě důležité skutečnosti o usoutdoor.com:
- Stránka nehashuje hesla. V nejlepším případě jsou šifrována, ale velmi pravděpodobně jsou uložena v čistém textu; žádné důkazy o opaku nevidíme.
- Stránka posílá trvalé heslo (můžeme se k němu vracet a používat ho znovu a znovu) po nezabezpečeném kanálu.
Jakmile to vyřešíme, potřebujeme ověřit, zda došlo k resetování bezpečným způsobem. Nejprve se musíme ujistit, že osoba žádající má právo provést reset. Jinými slovy, před tímto potřebujeme ověření identity; podívejme se, co se stane, když je identita potvrzena bez předchozího ověření, že žadatel skutečně vlastní účet.
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 se zadanou e-mailovou adresou není registrován“). Problém očividně nastává, pokud takový web potvrdí existenci uživatele registrovaného s touto e-mailovou adresou. Bingo – právě jste odhalili porno-fetiš vašeho manžela/šéfa/sousedky!
Samozřejmě, porno je docela typickým příkladem důležitosti soukromí, nicméně nebezpečí spojení identity s konkrétním webem je mnohem širší, než jakákoliv výše uvedená potenciálně trapná situace. Jedním z nebezpečí je 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 s danou osobou spojit, předstíraje, že je zástupcem webu a požádat o další informace ve snaze provést .
Takové praktiky také vedou k nebezpečí „enumerace uživatelských jmen“, kdy lze zkontrolovat existenci celé sbírky uživatelských jmen nebo e-mailových adres na webu jednoduchými hromadnými dotazy a zkoumáním jejich odpovědí. Máte seznam e-mailových adres všech zaměstnanců a pár minut na sepsání skriptu? Potom vidíte, v čem je problém!
Jaká je tedy alternativa? Ve skutečnosti je velmi jednoduchá a je skvěle realizována na :
Tady Entropay zcela nezveřejňuje nic o existenci e-mailové adresy v jejich systému tomu, kdo tuto adresu nevlastní. Pokud vy vlastníte tato adresa neexistuje v systému, obdržíte podobný e-mail:
Samozřejmě existují přijatelné situace, kdy si někdo myslí, že se registroval na webu, ale to není pravda, nebo to udělal z jiné e-mailové adresy. Uvedený příklad dobře pokrývá obě situace. Je zřejmé, že pokud adresa odpovídá, obdržíte e-mail, který usnadňuje resetování hesla.
Nástraha vybraného řešení Entropay spočívá v tom, že ověření identity se provádí přes e-mail před jakýmkoli online ověřením. Některé weby se ptají uživatelů na odpověď na tajnou otázku (více o tom níže) do o tom, jak bude proces resetování zahájen; problém spočívá v tom, že je nutné odpovědět na otázku, přičemž je třeba poskytnout nějaký prvek identifikace (e-mail nebo uživatelské jméno), což následně znesnadňuje intuitivní odpověď, aniž by se odhalil jakýkoli účet anonymního uživatele.
Při tomto přístupu je malé snížení použitelnosti, protože v případě pokusu o reset neexistujícího účtu není okamžitá zpětná vazba. Samozřejmě, to je celé smysl zaslání e-mailu, ale z pohledu skutečného konečného uživatele, pokud zadá špatnou adresu, dozví se to poprvé až při obdržení e-mailu. To může vyvolat určité napětí z jeho strany, ale je to malá cena za tak vzácný proces.
Další poznámka, která se lehce odchyluje od tématu: funkce pomoci při přihlašování, které odhalují správnost uživatelského jména nebo e-mailové adresy, mají stejný problém. Vždy odpovídejte uživateli zprávou „Kombinace uživatelského jména a hesla je neplatná“, a to místo toho, aby jste explicitně potvrdili existenci identifikačních údajů (např. „uživatelské jméno je správné, ale heslo bylo zadáno chybně“).
Odesílání hesla pro resetování versus odesílání URL pro resetování
Další koncept, který musíme probrat, se týká způsobu resetování hesla. Existují dvě oblíbená řešení:
- Generování nového hesla na serveru a jeho odeslání e-mailem
- Odeslání e-mailu s unikátním URL, které usnadňuje proces resetování
Navzdory , první možnost by se nikdy neměla používat. Její problém spočívá v tom, že to znamená existenci uloženého hesla, ke kterému se lze vrátit a znovu jej použít kdykoli; bylo předáno nechráněným kanálem a zůstává ve vaší doručené poště. Existuje pravděpodobnost, že se doručená pošta synchronizuje s mobilními zařízeními a e-mailovými klienty, a navíc může být dlouho uložena online ve webové službě e-mailu. Pointa je v tom, že e-mailovou schránku nelze považovat za spolehlivý prostředek pro dlouhodobé uchovávání.
Ale kromě toho první možnost má ještě jeden vážný problém — maximalizuje blokování účtu se zlým úmyslem. Pokud znám e-mailovou adresu toho, kdo vlastní účet na webové stránce, mohu jej kdykoli zablokovat jednoduchým resetováním jeho hesla; je to útok typu „odmítnutí služby“, servírovaný na stříbrném podnosu! Proto by měl být reset proveden pouze po úspěšném ověření práv požadujícího jej. Když hovoříme o URL pro resetování, máme na mysli adresu webové stránky, která je
unikátní pro tento konkrétní případ procesu resetování . Samozřejmě musí být náhodné, nemělo by být snadné je uhodnout a nemělo by obsahovat žádné externí odkazy na účet, které by usnadnily reset. Například URL pro resetování by nemělo být jen něco jako „Reset/?username=JohnSmith“.Chceme vytvořit jedinečný token, který lze poslat e-mailem jako URL pro resetování, a poté jej porovnat s záznamem na serveru o účtu uživatele, čímž potvrdíme, že vlastník účtu je skutečně stejná osoba, která se snaží resetovat heslo. Například token může mít tvar „3ce7854015cd38c862cb9e14a1ae552b“ a bude uložen v tabulce spolu s ID uživatele, který provádí reset, a časem vygenerování tokenu (více o tomto níže). Při posílání e-mailu obsahuje URL něco jako „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, a když si jej uživatel otevře, stránka zkontroluje existenci tokenu, poté potvrdí informace o uživateli a dovolí změnit heslo.
Мы хотим создать уникальный токен, который можно будет отправить по почте как URL сброса, а затем сверить его с записью на сервере с учётной записью пользователя, подтвердив таким образом, что владелец учётной записи и в самом деле тот же самый человек, который пытается сбросить пароль. Например, токен может иметь вид «3ce7854015cd38c862cb9e14a1ae552b» и храниться в таблице вместе с ID пользователя, выполняющего сброс, и временем генерации токена (подробнее об этом чуть ниже). При отправке письма оно содержит URL наподобие «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», а когда пользователь загружает его, страница запрашивает существование токена, после чего подтверждает информацию пользователя и разрешает изменить пароль.
Samozřejmě, jelikož výše popsaný proces (doufejme) umožňuje uživateli vytvořit nové heslo, je třeba zajistit načítání URL přes HTTPS. Ne, , tento URL s tokenem by měl používat zabezpečení transportní vrstvy, aby na formulář pro zadání nového hesla nebylo možné provést útok a uživatelské heslo bylo přenášeno přes zabezpečené spojení.
Také pro URL pro resetování je třeba přidat časový limit tokenu, aby bylo možné provést proces resetování v určitém intervalu, například během hodiny. To zaručí, že časové okno pro resetování bude minimální, aby ten, kdo získal tento URL pro reset, mohl jednat pouze v rámci tohoto velmi malého okna. Samozřejmě, útočník může znovu zahájit proces resetování, ale bude potřebovat získat další unikátní URL pro reset.
Nakonec musíme zajistit jednorázovost tohoto procesu. Po dokončení procesu resetování je nutné token odstranit, aby URL pro reset již nebylo funkční. Předchozí bod je potřebný k tomu, aby měl útočník velmi malou dobu, během které může manipulovat s URL pro reset. A samozřejmě, po úspěšném dokončení resetu token už není potřebný.
Některé z těchto kroků se mohou jevit jako příliš nadměrné, ale vůbec nezasahují do uživatelské přívětivosti a ve skutečnosti zvýšují bezpečnost, i když v situacích, které, doufáme, budou vzácné. V 99 % případů uživatel provede reset během velmi krátkého časového období a nebude znovu resetovat heslo v blízké budoucnosti.
Role CAPTCHA
Ó, CAPTCHA, ochranný prostředek, který všichni tak milujeme nenávidět! Ve skutečnosti je CAPTCHA nástroj spíše pro identifikaci než pro ochranu — zda jste člověk nebo robot (nebo automatizovaný skript). Jejím smyslem je zabránit automatickému odesílání formulářů, které, samozřejmě, může může být pokusem o prolomení ochrany. V kontextu resetování hesel CAPTCHA znamená, že funkci resetování nebude možné prolomit hrubým vyčerpáním, aby se buď spammovalo uživateli, nebo se pokusilo zjistit existenci účtů (což, samozřejmě, bude nemožné, pokud jste následovali rady ze sekce o ověřování identity).
Samozřejmě, CAPTCHA sama o sobě není ideální; existuje mnoho případů jejího programového "vniknutí" a dosažení uspokojivých výsledků (60-70%). Kromě toho existuje řešení, jak jsem ukázal ve svém příspěvku o , kde lze platit lidem malé částky za vyřešení každé CAPTCHA a získání úspěšnosti 94%. To znamená, že je zranitelná, avšak (trochu) zvyšuje vstupní bariéru.
Podívejme se na příklad PayPal:
V tomto případě proces resetování nemůže začít, dokud není CAPTCHA vyřešena, takže teoreticky je automatizace procesu nemožná. Teoreticky.
Ale pro většinu webových aplikací by to bylo příliš a rozhodně představuje snížení použitelnosti – lidé prostě nemají rádi CAPTCHA! Kromě toho, CAPTCHA je něco, k čemu se v případě potřeby snadno vrátíte. Pokud bude služba napadána (zde se hodí logování, ale o tom podrobněji později), je snadné přidat CAPTCHA.
Tajné otázky a odpovědi
Při všech modelech, které jsme zvažovali, jsme měli možnost resetovat heslo, přičemž jsme měli přístup pouze k e-mailovému účtu. Říkám "pouze", ale samozřejmě ilegální získání přístupu k cizímu e-mailovému účtu by mělo být složitým procesem. Nicméně .
Ve skutečnosti výše uvedený odkaz o hacksování účtu Sary Paleyové na Yahoo! slouží dvojím účelům; za prvé, ilustruje, jak snadné je hacknout (některé) e-mailové účty, za druhé, ukazuje, jak lze zlovolně využívat špatné tajné otázky. Ale k tomu se vrátíme později.
Problém s resetováním hesel, které zcela závisí na e-mailu, spočívá v tom, že integrita účtu na webu, jehož heslo se pokoušíte resetovat, se stává zcela na integritě e-mailového účtu. Kdokoli, kdo má přístup k vaší e-mailové schránce, má přístup k jakémukoli účtu, jehož resetování je možné jednoduše tím, že obdržíte e-mail. Pro takové účty je e-mail "klíčem k všem dveřím" vašeho online života.
Jedním ze způsobů, jak snížit toto riziko, je implementace vzoru tajné otázky a odpovědi. Bezpochyby jste je již viděli: vybíráte otázku, na kterou znáte pouze vy musí odpověď, po níž se vám při resetování hesla ptají. To zvyšuje jistotu, že osoba, která se pokouší resetovat heslo, skutečně je vlastníkem účtu.
Vraťme se k Sarah Palin: chyba spočívala v tom, že odpovědi na její tajnou otázku/otázky bylo snadné najít. Zvláště když jste tak významná veřejná osobnost, informace o dívčím jménu matky, vzdělání nebo o tom, kde mohl někdo v minulosti žít, nejsou tak tajné. Ve skutečnosti většina z nich může být prakticky nalezena kýmkoliv. Tak se to stalo i u Sarah:
Hacker David Kernell získal přístup k Palinově účtu tím, že našel podrobnosti o jejím životopise, jako je její univerzita a datum narození, a poté využil funkci obnovení zapomenutého hesla k účtům Yahoo!.
Je to především chyba designu ze strany Yahoo! — tím, že uvedli tak jednoduché otázky, vlastně sabotovali hodnotu tajné otázky, a tedy i ochranu svého systému. Očividně je resetování hesla k e-mailovému účtu vždy složitější, protože nemůžete potvrdit jeho vlastnictví, když vlastníku pošlete e-mail (neboť nemáte druhou adresu), ale naštěstí dnes pro vytvoření takového systému není mnoho možností.
Vraťme se k tajným otázkám — existuje možnost umožnit uživateli vytvořit si vlastní otázky. Problém však je, že výsledek budou velmi očividné otázky:
Jaká je barva nebe?
Otázky, při nichž se lidé dostávají do nepříjemné situace, když pro identifikaci používá tajná otázka člověk (například v call centru):
S kým jsem se vyspal na Vánoce?
Nebo zcela hloupé otázky:
Jak se píše "heslo"?
Když jde o tajné otázky, uživatele je třeba zachránit před nimi samými! Jinými slovy, tajná otázka by měla být nastavena samotným webem, a ještě lépe, měla by se pokládat série tajných otázek, z nichž může uživatel vybírat. A ne pouze vybrat jednu; ideálně by si uživatel měl vybrat dvě nebo více tajných otázek při registraci účtu, které budou použity jako druhý kanál identifikace. Více otázek zvyšuje míru důvěry v ověřovací proces a navíc umožňuje přidání náhody (neukazovat vždy stejnou otázku), a také poskytuje určitou redundanci pro případ, že skutečný uživatel zapomene heslo.
Jaký by měl být dobrý tajný dotaz? Ovlivňuje to několik faktorů:
- Měl by být stručný — otázka by měla být jasná a jednoznačná.
- Odpověď by měla být konkrétní — nepotřebujeme otázku, na kterou by mohl jeden člověk odpovědět různě.
- Možné odpovědi by měly být rozmanité — otázka na něčí oblíbenou barvu poskytuje velmi malou podmnožinu možných odpovědí.
- Hledání odpovědi by mělo být složité — pokud je odpověď snadno nalezitelná kýmkoliv (pamatujme na lidi ve vysokých pozicích), je to špatně.
- Odpověď by měla být stálé v čase — pokud se ptáme na něčí oblíbený film, za rok může být odpověď jiná.
Jak to bývá, existuje webová stránka věnovaná dobrým otázkám, která se nazývá . Některé otázky se zdají být docela dobré, jiné neprocházejí některými z výše uvedených testů, zejména testem „snadnosti vyhledávání“.
Dovolte mi ukázat, jak jsou tajné otázky implementovány na PayPal a konkrétně jaké úsilí web vyvíjí při identifikaci. Výše jsme viděli stránku zahajovacího procesu (s CAPTCHA), a nyní ukážeme, co se děje poté, co zadáte svou e-mailovou adresu a vyřešíte CAPTCHA:
Výsledkem je, že uživatel dostává takový e-mail:
Zatím to vypadá docela běžně, ale zde je, co skrývá tento obnovený URL:
Takže přicházejí do hry tajné otázky. Ve skutečnosti PayPal také umožňuje resetovat heslo potvrzením čísla kreditní karty, takže existuje další kanál, ke kterému nemá přístup mnoho webů. Nemohu prostě změnit heslo, aniž bych odpověděl na oba tajné otázky (nebo neznal číslo karty). I když někdo ovládne můj e-mail, nebude moci resetovat heslo svého PayPal účtu, pokud neví o mně trochu více osobních informací. Jaké informace? Zde jsou možnosti tajných otázek nabízených PayPal:
Otázka ohledně školy a nemocnice může být mírně problematická z pohledu jednoduchosti hledání, ale ostatní nejsou tak špatné. Nicméně pro zvýšení bezpečnosti PayPal vyžaduje dodatečnou identifikaci pro změny odpovědi na tajné otázky:
PayPal je poměrně utopickým příkladem bezpečného resetování hesla: realizuje CAPTCHA pro snížení nebezpečí brutálního útoku, vyžaduje dva tajné otázky a poté požaduje ještě jeden druh zcela jiné identifikace pouze pro změnu odpovědí — a to pouhá chvíle poté, co se uživatel přihlásil. Samozřejmě, to je přesně to, co jsme a očekávali od PayPal; je to finanční instituce, která pracuje s velkými částkami peněz. To neznamená, že každý reset hesla by měl následovat tyto kroky – ve většině případů je to přehnané – nicméně je to dobrý příklad pro případy, kdy je bezpečnost skutečně důležitá.
Pohodlí systému tajných otázek spočívá v tom, že pokud jste jej neimplementovali okamžitě, lze jej přidat později, pokud to vyžaduje úroveň zabezpečení zdroje. Dobrou ukázkou toho je Apple, který tento mechanismus nedávno zavedl [článek napsán v roce 2012]. Když jsem jednou začal aktualizovat aplikaci na iPadu, viděl jsem následující výzvu:
Poté jsem viděl obrazovku, na které bylo možné vybrat několik párů tajných otázek a odpovědí, stejně jako záchrannou e-mailovou adresu:
Pokud jde o PayPal, otázky jsou vybírány předem a některé z nich jsou ve skutečnosti docela dobré:
Každý z těchto tří párů otázek a odpovědí představuje samostatnou sadu možných otázek, takže existuje dostatek způsobů, jak konfigurovat účet.
Dalším aspektem, který je třeba vzít v úvahu ohledně odpovědi na tajnou otázku, je uchovávání. Uložení v databázi jako prostého textu představuje skoro stejné hrozby jako u hesla, totiž — odhalení databáze okamžitě odhaluje hodnotu a vystavuje tak riziku nejen aplikaci, ale potenciálně zcela jiné aplikace, které používají stejné tajné otázky (to je opět ). Jednou z možností je bezpečné hashování (odolný algoritmus a kryptograficky náhodná sůl), nicméně na rozdíl od většiny případů ukládání hesel zde může být důvod k 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ěď uvedenou klientem), 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 je jen symetrické šifrování. Shrňme to: zacházejte 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 vynucovat heslo k cizímu účtu je jedna věc, ale začít konverzaci o jeho vzdělání (populární tajná otázka) je úplně něco jiného. Ve skutečnosti můžete opravdu komunikovat s někým o mnoha aspektech jeho života, které mohou představovat tajnou otázku, aniž byste vyvolávali podezření. Samozřejmě, podstatou tajné otázky je, že je spojena s něčím osobním životním zkušeností, takže si ji pamatujete, a právě 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 nedá dělat, kromě výběru takových možností tajných otázek, aby je s menší pravděpodobností bylo možné vynutit pomocí sociálního inženýrství.
[Pokračování následuje.]
Na základě 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
