Nedavno sam imao vremena ponovno razmisliti o tome kako bi trebala funkcionirati značajka sigurnog poništavanja lozinke, prvi put kad sam ugrađivao ovu funkciju , a onda kada je pomogao drugoj osobi učiniti nešto slično. U drugom slučaju, htio sam mu dati poveznicu na kanonski izvor sa svim pojedinostima o tome kako sigurno implementirati funkciju resetiranja. Međutim, problem je što takav resurs ne postoji, barem ne onaj koji bi opisao sve što se meni čini važnim. Pa sam odlučio to sam napisati.
Vidite, svijet zaboravljenih lozinki zapravo je prilično tajanstven. Postoji mnogo različitih, sasvim prihvatljivih stajališta i mnogo vrlo opasnih. Vjerojatno ste se susreli sa svakim od njih mnogo puta kao krajnji korisnik; pa ću pokušati upotrijebiti ove primjere da pokažem tko to radi kako treba, a tko ne i na što se trebate usredotočiti da biste dobili pravu značajku u svojoj aplikaciji.
Pohranjivanje lozinki: raspršivanje, enkripcija i (uzdah!) čisti tekst
Ne možemo razgovarati o tome što učiniti sa zaboravljenim lozinkama prije nego što razgovaramo o tome kako ih pohraniti. Lozinke su pohranjene u bazi podataka u jednoj od tri glavne vrste:
- Jednostavan tekst. Postoji stupac zaporke, koji je pohranjen u obliku običnog teksta.
- Šifrirano. Obično se koristi simetrično šifriranje (jedan ključ se koristi i za šifriranje i za dešifriranje), a šifrirane lozinke također se pohranjuju u istom stupcu.
- Raspršeno. Jednosmjerni proces (lozinka se može hashirati, ali ne može dehashirati); lozinka, htio bih se nadati, zatim sol, a svaki je u svojoj koloni.
Prijeđimo odmah na najjednostavnije pitanje: Nikad ne pohranjujte lozinke u običnom tekstu! Nikada. Jedna jedina ranjivost na , jedna nepažljiva sigurnosna kopija ili jedna od desetaka drugih jednostavnih pogrešaka - i to je to, gameover, sve vaše lozinke - to jest, oprostite, lozinke svih vaših klijenata postat će javna domena. Naravno, to bi značilo veliku vjerojatnost da sa svih svojih računa u drugim sustavima. I to će biti tvoja krivnja.
Enkripcija je bolja, ali ima svoje slabosti. Problem s enkripcijom je dešifriranje; možemo uzeti te šifre ludog izgleda i pretvoriti ih natrag u običan tekst, a kada se to dogodi, vraćamo se u situaciju s lozinkom čitljivom za čovjeka. Kako se to događa? Mali nedostatak ulazi u kod koji dekriptira lozinku, čineći je javno dostupnom - ovo je jedan od načina. Hakeri dobivaju pristup stroju na kojem su pohranjeni šifrirani podaci - ovo je druga metoda. Drugi način je, opet, ukrasti sigurnosnu kopiju baze podataka i netko također dobije ključ za šifriranje, koji je često vrlo nesigurno pohranjen.
I ovo nas dovodi do raspršivanja. Ideja iza hashiranja je da je jednosmjerno; jedini način za usporedbu lozinke koju je unio korisnik s njezinom raspršenom verzijom je raspršivanje unosa i njihova usporedba. Kako bismo spriječili napade pomoću alata kao što su dugine tablice, proces zasoljujemo nasumičnim odabirom (pročitajte moje o kriptografskoj pohrani). U konačnici, ako se ispravno implementiraju, možemo biti sigurni da raspršene lozinke više nikada neće postati običan tekst (o prednostima različitih algoritama raspršivanja govorit ću u drugom postu).
Brzi argument o raspršivanju nasuprot enkripciji: jedini razlog zbog kojeg biste ikada trebali šifrirati, a ne raspršiti lozinku je kada trebate vidjeti lozinku u običnom tekstu, i ovo nikad ne bi trebao željeti, barem u standardnoj situaciji na web stranici. Ako vam je ovo potrebno, onda najvjerojatnije radite nešto pogrešno!
Upozorenje!
Ispod teksta objave nalazi se dio screenshot-a pornografske stranice AlotPorn. Uredno je podšišano tako da ne postoji ništa što ne možete vidjeti na plaži, ali ako je vjerojatno da će i dalje uzrokovati probleme, nemojte skrolati prema dolje.
Uvijek poništite lozinku nikad ne podsjećaj ga
Jesu li vas ikada zamolili da izradite funkciju podsjetnici lozinka? Napravite korak unatrag i razmislite o ovom zahtjevu obrnuto: zašto je potreban ovaj "podsjetnik"? Jer je korisnik zaboravio lozinku. Što zapravo želimo učiniti? Pomozite mu da se ponovno prijavi.
Shvaćam da se riječ "podsjetnik" koristi (često) u kolokvijalnom smislu, ali ono što zapravo pokušavamo učiniti je sigurno pomoći korisniku da ponovno bude online. Budući da nam je potrebna sigurnost, postoje dva razloga zašto podsjetnik (tj. slanje korisniku njegove lozinke) nije prikladan:
- E-pošta je nesiguran kanal. Baš kao što ne bismo slali ništa osjetljivo putem HTTP-a (koristili bismo HTTPS), ne bismo trebali slati ništa osjetljivo putem e-pošte jer je njegov prijenosni sloj nesiguran. Zapravo, ovo je puno gore od jednostavnog slanja informacija preko nesigurnog transportnog protokola, jer se pošta često pohranjuje na uređaj za pohranu, dostupna je administratorima sustava, prosljeđuje se i distribuira, dostupna je zlonamjernom softveru itd. Nešifrirana e-pošta izuzetno je nesiguran kanal.
- Ionako ne biste trebali imati pristup lozinci. Ponovno pročitajte prethodni odjeljak o pohranjivanju - trebali biste imati hash lozinke (s dobrom jakom soli), što znači da ne biste trebali moći ni na koji način izdvojiti lozinku i poslati je poštom.
Dopustite mi da demonstriram problem na primjeru : Ovdje je tipična stranica za prijavu:
Očito je da je prvi problem to što se stranica za prijavu ne učitava preko HTTPS-a, ali stranica također od vas traži da pošaljete lozinku ("Pošalji lozinku"). Ovo može biti primjer kolokvijalne upotrebe gore spomenutog izraza, pa idemo korak dalje i vidimo što će se dogoditi:
Ne izgleda puno bolje, nažalost; i e-poruka koja potvrđuje da postoji problem:
Ovo nam govori o dva važna aspekta usoutdoor.com:
- Stranica ne raspršuje lozinke. U najboljem slučaju, oni su šifrirani, ali je vjerojatno da su pohranjeni u običnom tekstu; Ne vidimo dokaze za suprotno.
- Stranica šalje dugoročnu lozinku (možemo se vratiti i koristiti je opet i opet) preko nezaštićenog kanala.
Kad se ovo riješi, moramo provjeriti je li proces resetiranja obavljen na siguran način. Prvi korak za to je provjeriti ima li podnositelj zahtjeva pravo izvršiti resetiranje. Drugim riječima, prije ovoga potrebna nam je provjera identiteta; pogledajmo što se događa kada se identitet potvrdi bez prethodne provjere da je podnositelj zahtjeva zapravo vlasnik računa.
Popis korisničkih imena i njegov utjecaj na anonimnost
Ovaj problem najbolje je ilustrirati vizualno. Problem:
Vidiš li? Obratite pozornost na poruku "Ne postoji korisnik registriran s ovom adresom e-pošte." Problem očito nastaje ako takva stranica potvrdi dostupnost korisnik registriran s takvom adresom e-pošte. Bingo - upravo ste otkrili porno fetiš svog muža/šefa/susjede!
Naravno, pornografija je prilično ikoničan primjer važnosti privatnosti, ali opasnosti povezivanja pojedinca s određenom web stranicom mnogo su šire od gore opisane potencijalno neugodne situacije. Jedna opasnost je društveni inženjering; Ako napadač može spojiti osobu s uslugom, tada će imati informacije koje može početi koristiti. Na primjer, može kontaktirati osobu koja se predstavlja kao predstavnik web stranice i zatražiti dodatne informacije u pokušaju da se obveže .
Takve prakse također povećavaju opasnost od "nabrajanja korisničkih imena", pri čemu se može provjeriti postojanje čitave zbirke korisničkih imena ili adresa e-pošte na web stranici jednostavnim postavljanjem grupnih upita i ispitivanjem odgovora na njih. Imate li popis adresa e-pošte svih zaposlenika i nekoliko minuta da napišete skriptu? Onda vidite u čemu je problem!
Što je alternativa? Zapravo, prilično je jednostavan i izvrsno implementiran u :
Ovdje Entropay ne otkriva apsolutno ništa o postojanju adrese e-pošte u svom sustavu nekome tko ne posjeduje ovu adresu... Ako ti vlastiti ovu adresu i ne postoji u sustavu, tada ćete dobiti e-mail poput ovog:
Naravno, mogu postojati prihvatljive situacije u kojima netko mislida ste se registrirali na web stranici. ali to nije slučaj ili sam to učinio s druge adrese e-pošte. Gore prikazani primjer dobro obrađuje obje situacije. Očito, ako se adresa podudara, primit ćete e-poruku koja će vam olakšati ponovno postavljanje lozinke.
Suptilnost rješenja koje je izabrao Entropay je u tome što se provjera identifikacije provodi prema e-mail prije bilo kakve online provjere. Neka mjesta od korisnika traže odgovor na sigurnosno pitanje (više o tome u nastavku) na kako reset može započeti; međutim, problem s ovime je što morate odgovoriti na pitanje dok dajete neki oblik identifikacije (e-mail ili korisničko ime), što onda čini gotovo nemogućim intuitivno odgovoriti bez otkrivanja postojanja anonimnog korisničkog računa.
S ovim pristupom postoji mali smanjena upotrebljivost jer ako pokušate resetirati nepostojeći račun, nema trenutne povratne informacije. Naravno, to je cijela poanta slanja e-pošte, ali iz perspektive pravog krajnjeg korisnika, ako upišu pogrešnu adresu, prvi put će to znati tek kada prime e-poštu. To može izazvati određenu napetost s njegove strane, ali to je mala cijena za tako rijedak proces.
Još jedna napomena, pomalo izvan teme: funkcije pomoći pri prijavi koje otkrivaju jesu li korisničko ime ili adresa e-pošte točni imaju isti problem. Uvijek odgovorite korisniku porukom "Vaša kombinacija korisničkog imena i lozinke je nevažeća" umjesto eksplicitne potvrde postojanja vjerodajnica (na primjer, "korisničko ime je ispravno, ali lozinka je netočna").
Slanje lozinke za poništavanje u odnosu na slanje URL-a za poništavanje
Sljedeći koncept o kojem trebamo razgovarati je kako poništiti lozinku. Postoje dva popularna rješenja:
- Generiranje nove lozinke na poslužitelju i slanje e-poštom
- Pošaljite e-poruku s jedinstvenim URL-om kako biste olakšali postupak resetiranja
Bez obzira na , prva točka se nikada ne smije koristiti. Problem s ovim je što to znači da postoji pohranjena lozinka, na koji se možete vratiti i ponovno koristiti u bilo kojem trenutku; poslano je putem nesigurnog kanala i ostaje u vašoj pristigloj pošti. Velike su šanse da su pristigle pošte sinkronizirane na mobilnim uređajima i klijentu e-pošte, a mogu biti pohranjene na mreži u web-usluzi e-pošte jako dugo vremena. Poanta je u tome poštanski sandučić ne može se smatrati pouzdanim sredstvom dugotrajne pohrane.
No, osim ovoga, prva točka ima još jedan ozbiljan problem - to pojednostavljuje što je više moguće blokiranje računa sa zlom namjerom. Ako znam adresu e-pošte nekoga tko posjeduje račun na web stranici, mogu ga blokirati u bilo kojem trenutku jednostavnim poništavanjem lozinke; Ovo je napad uskraćivanjem usluge poslužen na srebrnom pladnju! Zbog toga se resetiranje treba izvesti tek nakon uspješne provjere prava podnositelja zahtjeva na njega.
Kada govorimo o URL-u za resetiranje, mislimo na adresu web stranice koja je jedinstveno za ovaj konkretan slučaj procesa resetiranja. Naravno, trebao bi biti nasumičan, ne bi ga trebalo biti lako pogoditi i ne bi trebao sadržavati nikakve vanjske poveznice na račun koje olakšavaju resetiranje. Na primjer, URL za poništavanje ne bi trebao biti samo put poput "Poništi/?username=JohnSmith".
Želimo stvoriti jedinstveni token koji se može poslati poštom kao URL za poništavanje, a zatim usporediti sa zapisom poslužitelja korisničkog računa, čime se potvrđuje da je vlasnik računa zapravo ista osoba koja pokušava poništiti lozinku. Na primjer, token bi mogao biti "3ce7854015cd38c862cb9e14a1ae552b" i pohranjen u tablici zajedno s ID-om korisnika koji izvodi resetiranje i vremenom kada je token generiran (više o tome u nastavku). Kada je e-pošta poslana, ona sadrži URL kao što je “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, a kada je korisnik preuzme, stranica traži postojanje tokena, nakon čega potvrđuje podatke korisnika i dopušta mu promjenu lozinka.
Naravno, budući da gornji postupak (nadajmo se) omogućuje korisniku stvaranje nove lozinke, moramo osigurati da se URL učitava preko HTTPS-a. Ne, , ovaj URL tokena mora koristiti sigurnost prijenosnog sloja tako da novi obrazac lozinke ne može biti napadnut a lozinka koju je izradio korisnik prenesena je sigurnom vezom.
Također za URL resetiranja trebate dodati vremensko ograničenje tokena tako da se proces resetiranja može dovršiti unutar određenog intervala, recimo unutar jednog sata. Ovo osigurava da je vremenski okvir za resetiranje minimalan tako da primatelj URL-a za resetiranje može djelovati samo unutar tog vrlo malog prozora. Naravno, napadač može ponovo pokrenuti proces resetiranja, ali morat će dobiti još jedan jedinstveni URL resetiranja.
Konačno, moramo osigurati da je ovaj proces jednokratan. Nakon što se proces resetiranja završi, token se mora ukloniti tako da URL za resetiranje više ne radi. Prethodna točka je neophodna kako bi se osiguralo da napadač ima vrlo mali prozor tijekom kojeg može manipulirati URL-om za resetiranje. Osim toga, naravno, kada je resetiranje uspješno, token više nije potreban.
Neki od ovih koraka mogu se činiti previše suvišnim, ali oni ne ometaju upotrebljivost i u stvari poboljšati sigurnost, iako u situacijama za koje se nadamo da će biti rijetke. U 99% slučajeva korisnik će omogućiti resetiranje u vrlo kratkom vremenskom razdoblju i neće ponovno resetirati lozinku u bliskoj budućnosti.
Uloga CAPTCHA
Oh, CAPTCHA, sigurnosna značajka koju svi volimo mrziti! Zapravo, CAPTCHA nije toliko zaštitni alat koliko je alat za identifikaciju - bez obzira jeste li osoba ili robot (ili automatizirana skripta). Njegova je svrha izbjeći automatsko podnošenje obrasca, što, naravno, može koristiti kao pokušaj probijanja sigurnosti. U kontekstu poništavanja lozinki, CAPTCHA znači da se funkcija poništavanja ne može grubo natjerati da korisniku pošalje neželjenu poštu ili da pokuša utvrditi postojanje računa (što, naravno, neće biti moguće ako ste slijedili savjete u odjeljku o provjera identiteta).
Naravno, sama CAPTCHA nije savršena; Postoje mnogi presedani za njegovo "hakiranje" softvera i postizanje dovoljnih stopa uspješnosti (60-70%). Osim toga, postoji rješenje prikazano u mom postu o , gdje ljudima možete platiti djeliće centa za rješavanje svake CAPTCHA i postići stopu uspjeha od 94%. Odnosno, ranjiv je, ali (malo) podiže ulaznu barijeru.
Pogledajmo primjer PayPala:
U ovom slučaju, proces resetiranja jednostavno ne može započeti dok se CAPTCHA ne riješi, tako da teoretski nemoguće je automatizirati proces. U teoriji.
Međutim, za većinu web aplikacija to će biti pretjerano i apsolutno u pravu predstavlja smanjenje upotrebljivosti - ljudi jednostavno ne vole CAPTCHA! Osim toga, CAPTCHA je nešto čemu se lako možete vratiti ako je potrebno. Ako usluga počne biti napadnuta (ovdje je bilježenje korisno, ali više o tome kasnije), tada dodavanje CAPTCHA ne može biti lakše.
Tajna pitanja i odgovori
Uz sve metode koje smo razmotrili, uspjeli smo poništiti lozinku samo pristupom računu e-pošte. Kažem "samo", ali, naravno, nezakonito je dobiti pristup tuđem računu e-pošte. mošt biti složen proces. Međutim .
Zapravo, gornja veza o hakiranju Yahooa Sarah Palin! služi u dvije svrhe; prvo, ilustrira koliko je lako hakirati (neke) račune e-pošte, i drugo, pokazuje kako se loša sigurnosna pitanja mogu koristiti sa zlonamjernim namjerama. Ali vratit ćemo se na ovo kasnije.
Problem sa XNUMX% poništavanjem lozinke temeljenim na e-pošti je taj što integritet računa za web mjesto koji pokušavate poništiti postaje XNUMX% ovisan o integritetu računa e-pošte. Svatko tko ima pristup vašoj e-pošti ima pristup bilo kojem računu koji se može resetirati jednostavnim primanjem e-pošte. Za takve račune, e-pošta je "ključ za sva vrata" vašeg online života.
Jedan od načina za smanjenje ovog rizika je implementacija obrasca sigurnosnog pitanja i odgovora. Bez sumnje ste ih već vidjeli: odaberite pitanje na koje samo vi možete odgovoriti imati znate odgovor, a onda kada poništite svoju lozinku, od vas će se tražiti da je unesete. Ovo dodaje povjerenje da je osoba koja pokušava resetirati doista vlasnik računa.
Povratak na Sarah Palin: pogreška je bila u tome što su se odgovori na njezino sigurnosno pitanje/pitanja mogli lako pronaći. Osobito kada ste tako značajna javna osoba, podaci o djevojačkom prezimenu vaše majke, povijesti obrazovanja ili o tome gdje je netko možda živio u prošlosti nisu toliko tajni. Zapravo, većinu toga može pronaći gotovo svatko. Ovo se dogodilo Sari:
Haker David Kernell dobio je pristup Palinovom računu tako što je pronašao pojedinosti o njezinoj pozadini, kao što su njezino sveučilište i datum rođenja, a zatim je koristio Yahoo!-ovu značajku za oporavak zaboravljene lozinke.
Prije svega, ovo je greška u dizajnu od strane Yahooa! — određivanjem tako jednostavnih pitanja tvrtka je u biti sabotirala vrijednost sigurnosnog pitanja, a time i zaštitu svog sustava. Naravno, poništavanje lozinki za račun e-pošte uvijek je teže jer ne možete dokazati vlasništvo slanjem e-pošte vlasniku (bez druge adrese), ali srećom danas nema mnogo načina za stvaranje takvog sustava.
Vratimo se na sigurnosna pitanja – postoji opcija da se korisniku omogući da sam kreira svoja pitanja. Problem je u tome što će to rezultirati užasno očitim pitanjima:
Koje je boje nebo?
Pitanja koja ljudima stvaraju nelagodu kada se za identifikaciju koristi sigurnosno pitanje ljudi (na primjer, u pozivnom centru):
S kim sam spavao za Božić?
Ili iskreno glupa pitanja:
Kako se piše "lozinka"?
Što se tiče sigurnosnih pitanja, korisnike treba čuvati od samih sebe! Drugim riječima, sigurnosno pitanje treba odrediti sama stranica, ili još bolje, postaviti ga niz sigurnosna pitanja među kojima korisnik može birati. A nije ga lako izabrati jedan; idealno bi korisnik trebao odabrati dva ili više sigurnosnih pitanja u trenutku registracije računa, koji će se tada koristiti kao drugi identifikacijski kanal. Posjedovanje više pitanja povećava povjerenje u postupak verifikacije, a također pruža mogućnost dodavanja slučajnosti (ne prikazuje uvijek isto pitanje), plus pruža malo redundantnosti u slučaju da je stvarni korisnik zaboravio lozinku.
Što je dobro sigurnosno pitanje? Na to utječe nekoliko čimbenika:
- Trebalo bi biti kratak — pitanje mora biti jasno i nedvosmisleno.
- Odgovor mora biti specifična — ne trebamo pitanje na koje jedna osoba može odgovoriti različito
- Mogući odgovori bi trebali biti raznolika - postavljanje pitanja o nečijoj omiljenoj boji daje vrlo mali podskup mogućih odgovora
- Traženje odgovor mora biti složen – ako se odgovor može lako pronaći bilo koji (sjetite se ljudi na visokim položajima), onda je on loš
- Odgovor mora biti trajni u vremenu - ako pitate nečiji omiljeni film, godinu dana kasnije odgovor može biti drugačiji
Slučajno postoji web stranica posvećena postavljanju dobrih pitanja pod nazivom . Neka se pitanja čine prilično dobrima, druga ne prolaze neke od gore opisanih testova, posebno test "lakoće pretraživanja".
Dopustite mi da demonstriram kako PayPal implementira sigurnosna pitanja i, posebno, trud koji stranica ulaže u provjeru autentičnosti. Gore smo vidjeli stranicu za pokretanje procesa (s CAPTCHA), a ovdje ćemo pokazati što se događa nakon što unesete svoju adresu e-pošte i riješite CAPTCHA:
Kao rezultat toga, korisnik dobiva sljedeće pismo:
Za sada je sve sasvim normalno, ali evo što se krije iza ovog URL-a za resetiranje:
Dakle, sigurnosna pitanja ulaze u igru. Zapravo, PayPal vam također omogućuje poništavanje lozinke provjerom broja vaše kreditne kartice, tako da postoji dodatni kanal kojem mnoge stranice nemaju pristup. Jednostavno ne mogu promijeniti lozinku bez odgovora oboje sigurnosno pitanje (ili nepoznavanje broja kartice). Čak i da mi je netko ukrao e-poštu, ne bi mogao poništiti lozinku mog PayPal računa osim ako ne zna malo više osobnih podataka o meni. Koje informacije? Evo opcija sigurnosnih pitanja koje PayPal nudi:
Pitanje o školi i bolnici možda je malo sumnjivo u smislu jednostavnosti pretraživanja, ali ostala nisu tako loša. Međutim, radi povećanja sigurnosti, PayPal zahtijeva dodatnu identifikaciju za promjena odgovori na sigurnosna pitanja:
PayPal je prilično utopijski primjer sigurnih poništavanja lozinki: implementira CAPTCHA kako bi smanjio opasnost od napada brutalnom silom, zahtijeva dva sigurnosna pitanja, a zatim zahtijeva drugu vrstu potpuno drugačije identifikacije samo da bi se promijenili odgovori—i to nakon što korisnik se već prijavio. Naravno, to je upravo ono što mi očekivano sa PayPala; je financijska institucija koja se bavi velikim svotama novca. To ne znači da svako poništavanje lozinke mora slijediti ove korake—većinom je to pretjerano—ali dobar je primjer za slučajeve u kojima je sigurnost ozbiljan posao.
Pogodnost sustava sigurnosnih pitanja je da ako ga niste odmah implementirali, možete ga dodati kasnije ako to zahtijeva razina zaštite resursa. Dobar primjer za to je Apple koji je tek nedavno implementirao ovaj mehanizam [članak napisan 2012.]. Nakon što sam počeo ažurirati aplikaciju na svom iPadu, vidio sam sljedeći zahtjev:
Tada sam vidio zaslon na kojem sam mogao odabrati nekoliko parova sigurnosnih pitanja i odgovora, kao i adresu e-pošte za spašavanje:
Što se tiče PayPala, pitanja su unaprijed odabrana i neka od njih su zapravo prilično dobra:
Svaki od tri para pitanje/odgovor predstavlja drugačiji skup mogućih pitanja, tako da postoji mnogo načina za konfiguriranje računa.
Još jedan aspekt koji treba uzeti u obzir u vezi s odgovorom na sigurnosno pitanje je pohrana. Imati bazu podataka s običnim tekstom u bazi podataka predstavlja gotovo iste prijetnje kao i lozinka, naime izlaganje baze podataka trenutačno otkriva vrijednost i dovodi u opasnost ne samo aplikaciju, već i potencijalno potpuno različite aplikacije koje koriste ista sigurnosna pitanja (ovdje opet ). Jedna je opcija sigurno raspršivanje (snažan algoritam i kriptografski nasumična sol), ali za razliku od većine slučajeva pohrane zaporke, može postojati dobar razlog da odgovor bude vidljiv kao običan tekst. Tipičan scenarij je potvrda identiteta od strane telefonskog operatera uživo. Naravno, raspršivanje je također primjenjivo u ovom slučaju (operater može jednostavno unijeti odgovor koji imenuje klijent), ali u najgorem slučaju, tajni odgovor mora biti smješten na nekoj razini kriptografske pohrane, čak i ako je to samo simetrična enkripcija . Rezimirati: tretiraj tajne kao tajne!
Posljednji aspekt sigurnosnih pitanja i odgovora je da su ranjiviji na društveni inženjering. Pokušati izravno izvući lozinku na tuđi račun jedno je, ali započeti razgovor o njenom formiranju (popularno sigurnosno pitanje) potpuno je drugo. Zapravo, vrlo dobro možete komunicirati s nekim o mnogim aspektima njegovog života koji bi mogli predstavljati tajno pitanje, a da pritom ne izazovete sumnju. Naravno, sama poanta sigurnosnog pitanja je da se odnosi na nečije životno iskustvo, pa je pamtljivo, i tu leži problem - ljudi vole pričati o svojim životnim iskustvima! Malo toga možete učiniti po tom pitanju, samo ako odaberete takve opcije sigurnosnog pitanja da jesu manje vjerojatno bi se mogao izvući društvenim inženjeringom.
[Nastavit će se.]O pravima oglašavanja
VDSina nudi pouzdano , svaki poslužitelj je spojen na internetski kanal od 500 megabita i besplatno je zaštićen od DDoS napada!
Izvor: www.habr.com