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 funkci zabudoval a pak, když pomohl jinému člověku udělat něco podobného. V druhém případě jsem mu chtěl dát odkaz na kanonický zdroj se všemi detaily, jak bezpečně implementovat funkci reset. Problém je však v tom, že takový zdroj neexistuje, alespoň ne takový, který by popisoval vše, co se mi zdá důležité. Tak jsem se rozhodl to napsat sám.
Vidíte, svět zapomenutých hesel je vlastně docela záhadný. Existuje mnoho různých, zcela přijatelných úhlů pohledu a mnoho docela nebezpečných. Je pravděpodobné, že jste se s každým z nich jako koncoví uživatelé setkali mnohokrát; pokusím se tedy na těchto příkladech ukázat, kdo to dělá správně, kdo ne a na co se musíte zaměřit, abyste funkci dostali do své aplikace.
Ukládání hesel: hašování, šifrování a (vzdech!) prostý text
Nemůžeme diskutovat o tom, co dělat se zapomenutými hesly, dokud neprobereme, jak je uložit. Hesla jsou v databázi uložena v jednom ze tří hlavních typů:
- Jednoduchý text. K dispozici je sloupec hesla, který je uložen ve formě prostého textu.
- Zašifrováno. Obvykle se používá symetrické šifrování (jeden klíč se používá pro šifrování i dešifrování) a šifrovaná hesla jsou také uložena ve stejném sloupci.
- Hašované. Jednosměrný proces (heslo lze hašovat, ale nelze jej dehašovat); Heslo, chtěl bych doufat, následuje sůl a každá je ve svém vlastním sloupci.
Pojďme rovnou k nejjednodušší otázce: Nikdy neukládejte hesla jako prostý text! Nikdy. Jedna jediná zranitelnost vůči , jedna neopatrná záloha nebo jedna z desítek dalších jednoduchých chyb – a to je vše, gameover, všechna vaše hesla – to znamená, promiňte, hesla všech vašich klientů se stane veřejnou doménou. To by samozřejmě znamenalo velkou pravděpodobnost, že ze všech jejich účtů v jiných systémech. A bude to vaše chyba.
Šifrování je lepší, ale má své slabiny. Problémem šifrování je dešifrování; můžeme vzít tyto šíleně vyhlížející šifry a převést je zpět na prostý text, a když se to stane, vrátíme se do situace hesel čitelných člověkem. Jak se to stane? Malá chyba se dostane do kódu, který dešifruje heslo, a tím je zpřístupní veřejnosti – to je jedna cesta. Hackeři získají přístup ke stroji, na kterém jsou uložena šifrovaná data – to je druhý způsob. Dalším způsobem je opět ukrást zálohu databáze a někdo získá i šifrovací klíč, který je často velmi nezabezpečeně uložen.
A tím se dostáváme k hašování. Myšlenka za hašováním je, že je jednosměrný; jediný způsob, jak porovnat heslo zadané uživatelem s jeho hašovanou verzí, je hashovat vstup a porovnat je. Abychom zabránili útokům z nástrojů, jako jsou duhové tabulky, osolíme proces náhodností (přečtěte si můj o kryptografickém úložišti). Nakonec, pokud jsou správně implementovány, můžeme si být jisti, že hashovaná hesla se již nikdy nestanou prostým textem (o výhodách různých hashovacích algoritmů budu mluvit v jiném příspěvku).
Rychlý argument o hašování vs. šifrování: jediný důvod, proč byste někdy potřebovali heslo raději šifrovat než hašovat, je, když potřebujete heslo vidět v prostém textu a tohle bys nikdy neměl chtít, alespoň ve standardní situaci na webu. Pokud to potřebujete, pak s největší pravděpodobností děláte něco špatně!
Varování!
Níže v textu příspěvku je část screenshotu pornografického webu AlotPorn. Je úhledně zastřižená, takže na pláži není nic, co byste neviděli, ale pokud je stále pravděpodobné, že způsobí nějaké problémy, neposouvejte se dolů.
Vždy resetujte heslo nikdy nepřipomínej mu to
Byli jste někdy požádáni o vytvoření funkce? upomínky Heslo? Udělejte krok zpět a zamyslete se nad touto žádostí obráceně: proč je toto „připomenutí“ potřeba? Protože uživatel zapomněl heslo. Co vlastně chceme dělat? Pomozte mu znovu se přihlásit.
Uvědomuji si, že slovo „připomenutí“ se používá (často) v hovorovém smyslu, ale to, o co se ve skutečnosti snažíme, je bezpečně pomoci uživateli být znovu online. Protože potřebujeme zabezpečení, existují dva důvody, proč připomenutí (tj. zaslání hesla uživateli) není vhodné:
- E-mail je nezabezpečený kanál. Stejně jako bychom neposílali nic citlivého přes HTTP (použili bychom HTTPS), neměli bychom posílat nic citlivého přes e-mail, protože jeho transportní vrstva je nezabezpečená. Ve skutečnosti je to mnohem horší než pouhé odesílání informací přes nezabezpečený přenosový protokol, protože pošta je často uložena na úložném zařízení, přístupná správcům systému, přeposílána a distribuována, přístupná malwaru a tak dále. Nešifrovaný e-mail je extrémně nezabezpečený kanál.
- Stejně byste neměli mít přístup k heslu. Znovu si přečtěte předchozí část o úložišti – měli byste mít heslo hash (s dobrou silnou solí), což znamená, že byste neměli být schopni žádným způsobem získat heslo a poslat ho poštou.
Dovolte mi demonstrovat problém na příkladu : Zde je typická přihlašovací stránka:
Je zřejmé, že prvním problémem je, že se přihlašovací stránka nenačte přes HTTPS, ale stránka vás také vyzve k zaslání hesla („Send Password“). Toto může být příklad hovorového použití výrazu uvedeného výše, takže pojďme o krok dále a uvidíme, co se stane:
Nevypadá to o moc lépe, bohužel; a e-mail s potvrzením, že došlo k problému:
To nám říká dva důležité aspekty usoutdoor.com:
- Web nehašuje hesla. V nejlepším případě jsou zašifrovány, ale je pravděpodobné, že jsou uloženy v prostém textu; Nevidíme žádné důkazy o opaku.
- Stránka posílá dlouhodobé heslo (můžeme se vrátit a používat ho znovu a znovu) přes nezabezpečený kanál.
Když je to z cesty, musíme zkontrolovat, zda je proces resetování proveden bezpečným způsobem. Prvním krokem k tomu je ujistit se, že žadatel má právo provést reset. Jinými slovy, předtím potřebujeme kontrolu identity; pojďme se podívat na to, co se stane, když je identita ověřena, aniž bychom nejprve ověřili, že žadatel je skutečně vlastníkem účtu.
Výpis uživatelských jmen a jeho vliv na anonymitu
Tento problém lze nejlépe ilustrovat vizuálně. Problém:
Vidíš? Věnujte pozornost zprávě „S touto e-mailovou adresou není registrován žádný uživatel.“ Problém samozřejmě nastává, pokud takový web potvrdí dostupnost uživatel registrovaný s takovou e-mailovou adresou. Bingo – právě jste objevili pornofetiš svého manžela/šéfa/souseda!
Porno je samozřejmě poměrně ikonickým příkladem důležitosti soukromí, ale nebezpečí spojení jednotlivce s konkrétní webovou stránkou je mnohem širší než potenciálně nepříjemná situace popsaná výše. Jedním nebezpečím je sociální inženýrství; Pokud útočník dokáže spárovat osobu se službou, pak bude mít informace, které může začít používat. Může například kontaktovat osobu vydávající se za zástupce webové stránky a požádat o další informace ve snaze spáchat .
Takové praktiky také zvyšují nebezpečí „výčtu uživatelských jmen“, kdy je možné ověřit existenci celé sbírky uživatelských jmen nebo e-mailových adres na webových stránkách pouhým prováděním skupinových dotazů a zkoumáním odpovědí na ně. Máte seznam e-mailových adres všech zaměstnanců a pár minut na napsání skriptu? Pak uvidíte, v čem je problém!
Jaká je alternativa? Ve skutečnosti je to docela jednoduché a je úžasně implementováno :
Entropay zde nezveřejňuje absolutně nic o existenci e-mailové adresy ve svém systému někomu, kdo tuto adresu nevlastní... jestli ty vlastní tato adresa a v systému neexistuje, obdržíte e-mail takto:
Samozřejmě mohou nastat přijatelné situace, kdy někdo myslíže jste se zaregistrovali na webu. ale není tomu tak, nebo jsem to udělal z jiné e-mailové adresy. Výše uvedený příklad dobře zvládá obě situace. Je zřejmé, že pokud se adresa shoduje, obdržíte e-mail, který usnadní resetování hesla.
Jemnost řešení zvoleného Entropay spočívá v tom, že ověření identifikace se provádí podle e-mail před jakýmkoli online ověřením. Některé weby žádají uživatele o odpověď na bezpečnostní otázku (více o tom níže) na jak může začít reset; problém je však v tom, že na otázku musíte odpovědět a zároveň uvést nějakou formu identifikace (e-mail nebo uživatelské jméno), což pak téměř znemožňuje intuitivní odpověď bez odhalení existence účtu anonymního uživatele.
S tímto přístupem existuje malý snížená použitelnost, protože pokud se pokusíte resetovat neexistující účet, neexistuje žádná okamžitá zpětná vazba. Samozřejmě, to je celý smysl odeslání e-mailu, ale z pohledu skutečného koncového uživatele, pokud zadá špatnou adresu, poprvé se to dozví, až když e-mail obdrží. To může z jeho strany způsobit určité napětí, ale je to malá cena za tak vzácný proces.
Další poznámka, mírně mimo téma: stejný problém mají funkce pomoci s přihlášením, které odhalí, zda je uživatelské jméno nebo e-mailová adresa správné. Vždy uživateli odpovězte zprávou „Kombinace vašeho uživatelského jména a hesla je neplatná“, nikoli explicitně potvrzujte existenci přihlašovacích údajů (například „uživatelské jméno je správné, ale heslo je nesprávné“).
Odeslání resetovacího hesla vs odeslání resetovací adresy URL
Dalším konceptem, který musíme prodiskutovat, je způsob resetování hesla. Existují dvě populární řešení:
- Vygenerování nového hesla na serveru a jeho odeslání e-mailem
- Odešlete e-mail s jedinečnou adresou URL, abyste proces resetování usnadnili
Přes , první bod by se nikdy neměl používat. Problém je v tom, že to znamená, že existuje uložené heslo, ke kterému se můžete kdykoli vrátit a znovu použít; byl odeslán přes nezabezpečený kanál a zůstává ve vaší doručené poště. Je pravděpodobné, že doručené pošty jsou synchronizovány mezi mobilními zařízeními a e-mailovým klientem a navíc mohou být uloženy online ve webové e-mailové službě po velmi dlouhou dobu. Jde o to poštovní schránku nelze považovat za spolehlivý prostředek dlouhodobého uložení.
Ale kromě toho má první bod ještě jeden vážný problém – to co nejvíce zjednodušuje blokování účtu se zlými úmysly. Pokud znám e-mailovou adresu někoho, kdo vlastní účet na webové stránce, mohu jej kdykoli zablokovat jednoduchým resetováním hesla; Toto je útok odmítnutí služby naservírovaný na stříbrném podnose! Proto by měl být reset proveden až po úspěšném ověření práv žadatele k němu.
Když mluvíme o resetované adrese URL, máme na mysli adresu webové stránky, která je jedinečné pro tento konkrétní případ procesu resetování. Samozřejmě by měl být náhodný, neměl by být snadno uhodnutelný a neměl by obsahovat žádné externí odkazy na účet, které usnadňují jeho resetování. Například adresa URL pro resetování by neměla být pouze cestou jako "Reset/?username=JohnSmith".
Chceme vytvořit jedinečný token, který lze odeslat poštou jako adresu URL pro resetování a poté jej porovnat se záznamem účtu uživatele na serveru, čímž se potvrdí, že vlastník účtu je ve skutečnosti stejná osoba, která se pokouší resetovat heslo . Token může být například „3ce7854015cd38c862cb9e14a1ae552b“ a uložen v tabulce spolu s ID uživatele provádějícího reset a časem, kdy byl token vygenerován (více o tom níže). Když je e-mail odeslán, obsahuje URL jako „Reset/?id=3ce7854015cd38c862cb9e14a1ae552b“, a když si jej uživatel stáhne, stránka se zeptá na existenci tokenu, poté potvrdí informace o uživateli a umožní mu změnit Heslo.
Samozřejmě, protože výše uvedený proces (doufejme) umožňuje uživateli vytvořit nové heslo, musíme zajistit, aby byla adresa URL načtena přes HTTPS. Ne, , musí tato adresa URL tokenu používat zabezpečení transportní vrstvy, aby nový formulář hesla nemohl být napaden a heslo vytvořené uživatelem bylo přeneseno přes zabezpečené připojení.
Také pro resetovací adresu URL musíte přidat časový limit tokenu, aby proces resetování mohl být dokončen v určitém intervalu, řekněme do hodiny. Tím je zajištěno, že doba resetování je udržována na minimu, takže příjemce adresy URL pro resetování může jednat pouze v rámci tohoto velmi malého okna. Útočník může samozřejmě proces resetování spustit znovu, ale bude muset získat jinou jedinečnou adresu URL pro resetování.
Nakonec musíme zajistit, aby tento proces byl jednorázový. Po dokončení procesu resetování je nutné odstranit token, aby resetovaná adresa URL již nebyla funkční. Předchozí bod je nutný k tomu, aby měl útočník k dispozici velmi malé okno, během kterého může manipulovat s resetovanou URL. Navíc, jakmile je reset úspěšný, token už není potřeba.
Některé z těchto kroků se mohou zdát příliš nadbytečné, ale nenarušují použitelnost a ve skutečnosti zlepšit bezpečnost, i když v situacích, které, jak doufáme, budou vzácné. V 99 % případů uživatel povolí reset během velmi krátké doby a v blízké budoucnosti nebude heslo znovu resetovat.
Role CAPTCHA
Oh, CAPTCHA, bezpečnostní funkce, kterou všichni rádi nenávidíme! Ve skutečnosti CAPTCHA není ani tak ochranným nástrojem, jako spíše identifikačním nástrojem – ať už jste člověk nebo robot (nebo automatizovaný skript). Jeho účelem je vyhnout se automatickému odesílání formuláře, což samozřejmě moci být použit jako pokus o prolomení zabezpečení. V souvislosti s resetováním hesla znamená CAPTCHA, že funkci resetování nelze hrubě vynutit, aby buď spamovala uživatele, nebo se pokusila zjistit existenci účtů (což samozřejmě nebude možné, pokud budete postupovat podle rad v sekci o ověření identity).
Samozřejmě, CAPTCHA sama o sobě není dokonalá; Existuje mnoho precedentů pro jeho softwarové „hackování“ a dosažení dostatečné úspěšnosti (60-70 %). Kromě toho existuje řešení uvedené v mém příspěvku o , kde můžete lidem zaplatit zlomky centu za vyřešení každého CAPTCHA a dosáhnout úspěšnosti 94 %. To znamená, že je zranitelný, ale (nepatrně) zvyšuje bariéru vstupu.
Podívejme se na příklad PayPal:
V tomto případě proces resetování jednoduše nemůže začít, dokud není CAPTCHA vyřešen, takže teoreticky není možné automatizovat proces. Teoreticky.
Pro většinu webových aplikací to však bude přehnané a naprosto správně představuje pokles použitelnosti - lidé prostě nemají rádi CAPTCHA! CAPTCHA je navíc něco, k čemu se můžete v případě potřeby snadno vrátit. Pokud služba začne být napadena (to je místo, kde se logování hodí, ale o tom později), pak přidání CAPTCHA nemůže být jednodušší.
Tajné otázky a odpovědi
Se všemi metodami, které jsme zvažovali, jsme byli schopni obnovit heslo pouhým přístupem k e-mailovému účtu. Říkám „jen“, ale samozřejmě je nezákonné získat přístup k e-mailovému účtu někoho jiného. mošt být složitý proces. nicméně .
Ve skutečnosti výše uvedený odkaz o hacknutí Yahoo! Sarah Palinové! slouží dvěma účelům; za prvé ukazuje, jak snadné je hacknout (některé) e-mailové účty, a za druhé ukazuje, jak špatné bezpečnostní otázky lze použít se zlými úmysly. Ale k tomu se vrátíme později.
Problém se XNUMX% resetováním hesla na základě e-mailu spočívá v tom, že integrita účtu pro web, který se pokoušíte resetovat, se stává XNUMX% závislou na integritě e-mailového účtu. Každý, kdo má přístup k vašemu e-mailu má přístup k jakémukoli účtu, který lze resetovat pouhým obdržením e-mailu. Pro takové účty je e-mail „klíčem ke všem dveřím“ vašeho online života.
Jedním ze způsobů, jak toto riziko snížit, je implementace vzoru bezpečnostních otázek a odpovědí. Nepochybně jste je již viděli: vyberte si otázku, na kterou můžete odpovědět pouze vy mít znát odpověď a po obnovení hesla budete o to požádáni. To dodává jistotu, že osoba pokoušející se o reset je skutečně vlastníkem účtu.
Zpět k Sarah Palinové: chyba byla v tom, že odpovědi na její bezpečnostní otázku/otázky bylo možné snadno najít. Zvláště když jste tak významná veřejná osobnost, informace o dívčím příjmení vaší matky, historii vzdělání nebo o tom, kde někdo mohl bydlet v minulosti, nejsou tak tajné. Většinu z toho může najít vlastně skoro každý. Toto se stalo Sarah:
Hacker David Kernell získal přístup k účtu Palin zjištěním podrobností o jejím původu, jako je její univerzita a datum narození, a poté pomocí funkce Yahoo! pro obnovení zapomenutého hesla.
Za prvé, jde o konstrukční chybu na straně Yahoo! — specifikací těchto jednoduchých otázek společnost v podstatě sabotovala hodnotu bezpečnostní otázky, a tím i ochranu svého systému. Resetování hesel k e-mailovému účtu je samozřejmě vždy obtížnější, protože vlastnictví nelze prokázat zasláním e-mailu majiteli (aniž byste měli druhou adresu), ale naštěstí dnes není mnoho použití pro vytvoření takového systému.
Vraťme se k bezpečnostním otázkám – je zde možnost umožnit uživateli vytvářet vlastní otázky. Problém je v tom, že to povede k velmi zjevným otázkám:
Jakou barvu má obloha?
Otázky, které lidem znepříjemňují, když se k identifikaci používá bezpečnostní otázka osoba (například v call centru):
S kým jsem spal o Vánocích?
Nebo upřímně hloupé otázky:
Jak se píše "heslo"?
Pokud jde o bezpečnostní otázky, uživatelé musí být chráněni před sebou samými! Jinými slovy, bezpečnostní otázku by měl určit web sám, nebo ještě lépe, položit série bezpečnostní otázky, ze kterých si uživatel může vybrat. A není snadné si vybrat jeden; v ideálním případě by měl uživatel vybrat dvě nebo více bezpečnostních otázek v době registrace účtu, který bude poté použit jako druhý identifikační kanál. Více otázek zvyšuje důvěru v proces ověřování a také poskytuje možnost přidat náhodnost (ne vždy zobrazuje stejnou otázku) a navíc poskytuje trochu redundance v případě, že skutečný uživatel zapomene heslo.
Co je dobrá bezpečnostní otázka? To je ovlivněno několika faktory:
- To by mělo být stručný — otázka musí být jasná a jednoznačná.
- Odpověď musí být konkrétní – nepotřebujeme otázku, na kterou může jeden člověk odpovědět jinak
- Možné odpovědi by měly být rozmanité - dotaz na něčí oblíbenou barvu poskytuje velmi malou podmnožinu možných odpovědí
- Vyhledávání odpověď musí být komplexní – pokud lze odpověď snadno najít každý (pamatujte na lidi ve vysokých funkcích), pak je špatný
- Odpověď musí být trvalý v čase - pokud se zeptáte na něčí oblíbený film, pak o rok později může být odpověď jiná
Jak už to tak bývá, existuje webová stránka věnovaná kladení dobrých otázek . Některé otázky vypadají docela dobře, jiné nevyhovují některým z výše popsaných testů, zejména testu „snadnosti vyhledávání“.
Dovolte mi ukázat, jak PayPal implementuje bezpečnostní otázky, a zejména úsilí, které web vkládá do ověřování. Nahoře jsme viděli stránku pro zahájení procesu (s CAPTCHA) a zde ukážeme, co se stane poté, co zadáte svou e-mailovou adresu a vyřešíte CAPTCHA:
V důsledku toho uživatel obdrží následující dopis:
Zatím je vše docela normální, ale za touto resetovací adresou URL se skrývá následující:
Do hry tedy vstupují bezpečnostní otázky. Ve skutečnosti vám PayPal také umožňuje resetovat heslo ověřením čísla vaší kreditní karty, takže existuje další kanál, ke kterému mnoho webů nemá přístup. Bez odpovědi si prostě nemůžu změnit heslo obojí bezpečnostní otázka (nebo neznáte číslo karty). I kdyby někdo unesl můj e-mail, nemohl by mi obnovit heslo k účtu PayPal, pokud by o mně neznal trochu více osobních údajů. jaké informace? Zde jsou možnosti bezpečnostních otázek, které PayPal nabízí:
Otázka týkající se školy a nemocnice může být trochu ošemetná, pokud jde o snadné vyhledávání, ale ostatní nejsou tak špatné. Pro zvýšení bezpečnosti však PayPal vyžaduje další identifikaci změny odpovědi na bezpečnostní otázky:
PayPal je docela utopický příklad bezpečného resetování hesla: implementuje CAPTCHA pro snížení nebezpečí útoků hrubou silou, vyžaduje dvě bezpečnostní otázky a pak vyžaduje jiný druh zcela odlišné identifikace, jen aby změnil odpovědi – a to poté, co uživatel se již přihlásil. Samozřejmě, to je přesně to, co my očekávaný z PayPal; je finanční instituce, která obchoduje s velkými částkami peněz. To neznamená, že každé resetování hesla se musí řídit těmito kroky – většinou je to přehnané – ale je to dobrý příklad pro případy, kdy jde o bezpečnost vážně.
Výhodou systému bezpečnostních otázek je, že pokud jste jej neimplementovali hned, můžete jej přidat později, pokud to vyžaduje úroveň ochrany zdrojů. Dobrým příkladem toho je Apple, který tento mechanismus implementoval teprve nedávno [článek napsán v roce 2012]. Jakmile jsem začal aktualizovat aplikaci na svém iPadu, viděl jsem následující požadavek:
Pak jsem viděl obrazovku, kde jsem mohl vybrat několik párů bezpečnostních otázek a odpovědí a také záchrannou e-mailovou adresu:
Pokud jde o PayPal, otázky jsou předem vybrané a některé z nich jsou ve skutečnosti docela dobré:
Každá ze tří dvojic otázka/odpověď představuje jinou sadu možných otázek, takže existuje spousta způsobů, jak konfigurovat účet.
Dalším aspektem, který je třeba zvážit při zodpovězení vaší bezpečnostní otázky, je úložiště. Mít databázi ve formátu prostého textu v databázi představuje téměř stejnou hrozbu jako heslo, totiž že odhalení databáze okamžitě odhalí hodnotu a ohrozí nejen aplikaci, ale potenciálně úplně jiné aplikace používající stejné bezpečnostní otázky (tamtéž ). Jednou z možností je bezpečné hashování (silný algoritmus a kryptograficky náhodná sůl), ale na rozdíl od většiny případů ukládání hesel může existovat dobrý důvod, proč je odpověď viditelná jako prostý text. Typickým scénářem je ověření identity živým telefonním operátorem. Hašování je samozřejmě použitelné i v tomto případě (operátor může jednoduše zadat odpověď pojmenovanou klientem), ale v nejhorším případě musí být tajná odpověď umístěna na nějaké úrovni kryptografického úložiště, i když jde jen o symetrické šifrování . Shrnout: zacházet s tajemstvím jako s tajemstvím!
Jedním z posledních aspektů bezpečnostních otázek a odpovědí je, že jsou zranitelnější vůči sociálnímu inženýrství. Pokusit se přímo získat heslo k cizímu účtu je jedna věc, ale zahájit konverzaci o jeho vytvoření (oblíbená bezpečnostní otázka) je úplně jiná. Ve skutečnosti můžete s někým velmi dobře komunikovat o mnoha aspektech jeho života, které mohou představovat tajnou otázku, aniž byste vzbudili podezření. Samozřejmě, samotný smysl bezpečnostní otázky je v tom, že se vztahuje k něčí životní zkušenosti, takže je zapamatovatelná, a v tom spočívá problém – lidé rádi mluví o svých životních zkušenostech! S tím můžete dělat jen málo, pouze pokud zvolíte takové možnosti bezpečnostní otázky, aby byly menší mohl být pravděpodobně vytažen sociálním inženýrstvím.
[Pokračování příště.]Jako reklama
VDSina nabízí spolehlivé , každý server je připojen k internetovému kanálu 500 megabitů a je zdarma chráněn před útoky DDoS!
Zdroj: www.habr.com