Nedavno sam ponovo imao vremena da razmislim o tome kako bi funkcija sigurnog ponovnog postavljanja lozinke trebala funkcionirati, prvo kada sam ugrađivao ovu funkcionalnost u , a zatim kada je pomogao drugoj osobi da učini nešto slično. U drugom slučaju, htio sam mu dati vezu do kanonskog izvora sa svim detaljima o tome kako sigurno implementirati funkciju resetiranja. Međutim, problem je što takav resurs ne postoji, barem ne onaj koji opisuje sve što se meni čini važnim. Pa sam odlučio da to sam napišem.
Vidite, svijet zaboravljenih lozinki je zapravo prilično misteriozan. Postoji mnogo različitih, potpuno prihvatljivih gledišta i dosta opasnih. Šanse su da ste se sa svakim od njih susreli mnogo puta kao krajnji korisnik; pa ću pokušati upotrijebiti ove primjere da pokažem ko to radi kako treba, a ko ne i na šta se trebate fokusirati da biste ovu funkciju postavili pravo u svoju aplikaciju.
Pohrana lozinki: heširanje, enkripcija i (zadah!) običan tekst
Ne možemo razgovarati o tome šta da radimo sa zaboravljenim lozinkama prije nego što razgovaramo o tome kako ih pohraniti. Lozinke se pohranjuju u bazi podataka u jednom od tri glavna tipa:
- Jednostavan tekst. Postoji kolona lozinke, koja se pohranjuje u obliku običnog teksta.
- Šifrirano. Obično se koristi simetrično šifrovanje (jedan ključ se koristi i za šifrovanje i za dešifrovanje), a šifrovane lozinke se takođe pohranjuju u istoj koloni.
- Hashed. Jednosmjerni proces (lozinka se može heširati, ali se ne može dehaširati); lozinka, Voleo bih da se nadam, zatim sol, a svaki je u svojoj koloni.
Pređimo direktno na najjednostavnije pitanje: Nikada ne čuvajte lozinke u običnom tekstu! Nikad. Jedna jedina ranjivost na , jedna nemarna sigurnosna kopija, ili jedna od desetina drugih jednostavnih grešaka - i to je to, gameover, sve vaše lozinke - to jest, izvinite, lozinke svih vaših klijenata postaće javno vlasništvo. Naravno, to bi značilo veliku vjerovatnoću sa svih njihovih računa u drugim sistemima. I to će biti tvoja greška.
Šifrovanje je bolje, ali ima svoje slabosti. Problem sa enkripcijom je dešifrovanje; možemo uzeti ove šifre ludog izgleda i pretvoriti ih nazad u običan tekst, a kada se to dogodi vraćamo se u situaciju lozinke čitljive osobe. Kako se to događa? Mala greška ulazi u kod koji dešifruje lozinku, čineći je javno dostupnom - ovo je jedan od načina. Hakeri dobijaju pristup mašini na kojoj se čuvaju šifrovani podaci - ovo je drugi način. Drugi način, opet, je da se ukrade rezervna kopija baze podataka i neko takođe dobije ključ za šifrovanje, koji je često veoma nesigurno pohranjen.
I ovo nas dovodi do heširanja. Ideja iza heširanja je da je jednosmjerno; jedini način da se uporedi lozinka koju je uneo korisnik sa njenom heširanom verzijom je da se heširaju unos i uporede. Kako bismo spriječili napade alata poput duginih tablica, proces solimo nasumičnošću (pročitajte moje o kriptografskom skladištenju). Na kraju, ako se pravilno implementira, možemo biti sigurni da heširane lozinke nikada više neće postati običan tekst (o prednostima različitih algoritama za heširanje ću govoriti u drugom postu).
Brzi argument o heširanju u odnosu na enkripciju: jedini razlog zbog kojeg biste ikada trebali šifrirati umjesto heširati lozinku je kada trebate vidjeti lozinku u običnom tekstu i nikad to ne treba da želiš, barem u standardnoj situaciji na web stranici. Ako vam ovo treba, onda najvjerovatnije radite nešto pogrešno!
Oprez
Ispod teksta objave nalazi se dio snimka ekrana pornografske web stranice AlotPorn. Uredno je dotjeran tako da nema ničega što ne možete vidjeti na plaži, ali ako je i dalje vjerovatno da će uzrokovati probleme, nemojte pomicati prema dolje.
Uvijek resetirajte svoju lozinku nikad ne podsjećaj ga
Da li su vas ikada pitali da kreirate funkciju podsjetnici lozinka? Napravite korak unazad i razmislite o ovom zahtjevu obrnuto: zašto je potreban ovaj „podsjetnik“? Zato što je korisnik zaboravio lozinku. Šta zaista želimo da radimo? Pomozite mu da se ponovo prijavi.
Shvaćam da se riječ "podsjetnik" koristi (često) u kolokvijalnom smislu, ali ono što zaista pokušavamo je sigurno pomoći korisniku da ponovo bude na mreži. Budući da nam je potrebna sigurnost, postoje dva razloga zašto podsjetnik (tj. slanje lozinke korisniku) nije prikladan:
- E-pošta je nesiguran kanal. Kao što ne bismo slali ništa osjetljivo preko HTTP-a (koristili bismo HTTPS), ne bismo trebali slati ništa osjetljivo putem e-pošte jer je njegov transportni sloj nesiguran. U stvari, ovo je mnogo gore od jednostavnog slanja informacija preko nesigurnog transportnog protokola, jer je pošta često pohranjena na uređaju za skladištenje, dostupna administratorima sistema, prosljeđena i distribuirana, dostupna zlonamjernom softveru itd. Nešifrovana e-pošta je izuzetno nesiguran kanal.
- Ionako ne biste trebali imati pristup lozinki. Ponovo pročitajte prethodni odeljak o skladištenju - trebalo bi da imate heš lozinke (sa dobrom jakom soli), što znači da ne biste trebali ni na koji način da izdvojite lozinku i pošaljete je poštom.
Dozvolite mi da demonstriram problem na primjeru : Evo tipične stranice za prijavu:
Očigledno, prvi problem je to što se stranica za prijavu ne učitava preko HTTPS-a, ali stranica također traži da pošaljete lozinku („Pošalji lozinku“). Ovo bi mogao biti primjer kolokvijalne upotrebe gore pomenutog izraza, pa hajde da napravimo korak dalje i vidimo šta se dešava:
Ne izgleda mnogo bolje, nažalost; i email potvrđuje da postoji problem:
Ovo nam govori o dva važna aspekta usoutdoor.com:
- Stranica ne hashira lozinke. U najboljem slučaju, oni su šifrirani, ali je vjerovatno da su pohranjeni u običnom tekstu; Ne vidimo nikakve dokaze za suprotno.
- Stranica šalje dugoročnu lozinku (možemo se vratiti i koristiti je iznova i iznova) preko nezaštićenog kanala.
S obzirom da se ovo makne s puta, moramo provjeriti da li je proces resetiranja obavljen na siguran način. Prvi korak da to uradite je da se uverite da podnosilac zahteva ima pravo da izvrši resetovanje. Drugim riječima, prije toga nam je potrebna provjera identiteta; hajde da pogledamo šta se dešava kada se identitet verifikuje bez prethodnog verifikacije da je podnosilac zahteva zapravo vlasnik naloga.
Navođenje korisničkih imena i njihov utjecaj na anonimnost
Ovaj problem je najbolje ilustrovati vizuelno. problem:
Vidiš? Obratite pažnju na poruku "Nema registrovanog korisnika sa ovom adresom e-pošte." Problem očito nastaje ako takva stranica potvrdi raspoloživost korisnik registrovan sa takvom adresom e-pošte. Bingo - upravo ste otkrili porno fetiš svog muža/šefa/komšije!
Naravno, pornografija je prilično ikoničan primjer važnosti privatnosti, ali opasnosti povezivanja pojedinca sa određenom web-stranicom su mnogo šire od potencijalno neugodne situacije opisane gore. Jedna opasnost je društveni inženjering; Ako napadač može povezati osobu sa uslugom, tada će imati informacije koje može početi koristiti. Na primjer, on može kontaktirati osobu koja se predstavlja kao predstavnik web stranice i zatražiti dodatne informacije u pokušaju da se izvrši .
Takve prakse također povećavaju opasnost od “nabrajanja korisničkog imena”, pri čemu se može provjeriti postojanje cijele kolekcije korisničkih imena ili adresa e-pošte na web stranici jednostavnim provođenjem grupnih upita i ispitivanjem odgovora na njih. Imate li listu email adresa svih zaposlenih i nekoliko minuta da napišete skriptu? Onda vidite u čemu je problem!
Šta je alternativa? U stvari, prilično je jednostavan, i divno je implementiran :
Ovdje Entropay ne otkriva apsolutno ništa o postojanju adrese e-pošte u svom sistemu nekome ko nije vlasnik ove adrese... Ako ti vlastiti ovu adresu i ona ne postoji u sistemu, tada ćete dobiti e-mail ovako:
Naravno, mogu postojati prihvatljive situacije u kojima neko mislida ste se registrovali na web stranici. ali to nije slučaj, ili sam to uradio sa druge adrese e-pošte. Primjer prikazan iznad dobro rješava obje situacije. Očigledno, ako se adresa podudara, primit ćete e-poruku koja će vam olakšati resetiranje lozinke.
Suptilnost rješenja koje je izabrao Entropay je da se provjera identifikacije vrši prema email prije bilo kakve online verifikacije. Neke web stranice traže od korisnika odgovor na sigurnosno pitanje (više o tome u nastavku) do kako resetovanje može početi; međutim, problem s ovim je u tome što morate odgovoriti na pitanje uz pružanje nekog oblika identifikacije (e-mail ili korisničko ime), što onda čini gotovo nemogućim intuitivni odgovor bez otkrivanja postojanja naloga anonimnog korisnika.
Sa ovim pristupom postoji mala smanjena upotrebljivost jer ako pokušate resetirati nepostojeći račun, nema trenutne povratne informacije. Naravno, u tome je cijela poenta slanja e-pošte, ali iz perspektive stvarnog krajnjeg korisnika, ako unese pogrešnu adresu, znat će tek prvi put kada primi e-poštu. To može izazvati određenu napetost s njegove strane, ali ovo je mala cijena za tako rijedak proces.
Još jedna napomena, malo van teme: funkcije pomoći pri prijavljivanju koje otkrivaju da li su korisničko ime ili adresa e-pošte ispravni imaju isti problem. Uvijek odgovorite korisniku porukom “Kombinacija vašeg korisničkog imena i lozinke je nevažeća” umjesto da eksplicitno potvrđujete postojanje vjerodajnica (na primjer, “korisničko ime je ispravno, ali lozinka je netačna”).
Slanje lozinke za poništavanje u odnosu na slanje URL-a za resetiranje
Sljedeći koncept o kojem trebamo razgovarati je kako resetirati vašu lozinku. Postoje dva popularna rješenja:
- Generisanje nove lozinke na serveru i slanje putem e-pošte
- Pošaljite e-poruku s jedinstvenim URL-om kako biste olakšali proces resetiranja
Unatoč tome , prva tač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 ponovo koristiti u bilo kojem trenutku; poslano je preko nesigurnog kanala i ostaje u vašem sandučetu. Šanse su da se sandučići sinkroniziraju na mobilnim uređajima i klijentu e-pošte, plus mogu biti pohranjeni na mreži u web servisu e-pošte jako dugo. Poenta je u tome poštanski sandučić se ne može smatrati pouzdanim sredstvom za dugotrajno skladištenje.
Ali pored ovoga, prva tačka ima još jedan ozbiljan problem - to pojednostavljuje što je više moguće blokiranje naloga sa zlonamjernom namjerom. Ako znam adresu e-pošte nekoga ko posjeduje nalog na web stranici, tada ga mogu blokirati u bilo kojem trenutku jednostavnim resetiranjem njihove lozinke; Ovo je napad uskraćivanja usluge serviran na srebrnom poslužavniku! Zbog toga bi reset trebalo izvršiti tek nakon uspješne provjere prava podnosioca zahtjeva na to.
Kada govorimo o URL-u za resetiranje, mislimo na adresu web stranice koja je jedinstven za ovaj konkretan slučaj procesa resetovanja. Naravno, trebalo bi da bude nasumično, ne bi trebalo da bude lako pogoditi i ne bi trebalo da sadrži nikakve eksterne veze ka nalogu koje olakšavaju resetovanje. Na primjer, URL za resetiranje ne bi trebao biti jednostavno put poput "Reset/?username=JohnSmith".
Želimo da kreiramo jedinstveni token koji se može poslati poštom kao reset URL, a zatim upariti sa zapisom servera korisničkog naloga, čime potvrđujemo da je vlasnik naloga, u stvari, ista osoba koja pokušava da resetuje lozinku. Na primjer, token bi mogao biti "3ce7854015cd38c862cb9e14a1ae552b" i pohranjen u tabeli zajedno s ID-om korisnika koji je izvršio resetiranje i vremenom kada je token generiran (više o tome u nastavku). Kada se email pošalje, sadrži URL poput “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b”, a kada ga korisnik preuzme, stranica traži postojanje tokena, nakon čega potvrđuje podatke o korisniku i dozvoljava mu promjenu lozinka.
Naravno, budući da gornji proces (nadajmo se) omogućava korisniku da kreira novu lozinku, moramo osigurati da se URL učita preko HTTPS-a. ne, , ovaj URL tokena mora koristiti sigurnost transportnog sloja tako da novi obrazac lozinke ne može biti napadnut a lozinka koju je kreirao korisnik prenijeta je preko sigurne veze.
Također za reset URL morate dodati vremensko ograničenje tokena kako bi se proces resetiranja mogao završiti u određenom intervalu, recimo u roku od sat vremena. Ovo osigurava da je vremenski okvir za resetovanje minimalan, tako da primalac URL-a za resetiranje može djelovati samo unutar tog vrlo malog prozora. Naravno, napadač može ponovo pokrenuti proces resetovanja, ali će morati da dobije još jedan jedinstveni URL za resetovanje.
Konačno, moramo osigurati da ovaj proces bude jednokratan. Kada se proces resetiranja završi, token se mora ukloniti tako da URL za resetiranje više ne funkcionira. Prethodna tačka je neophodna da bi se osiguralo da napadač ima veoma mali prozor tokom kojeg može da manipuliše URL-om za resetovanje. Osim toga, naravno, kada je resetiranje uspješno, token više nije potreban.
Neki od ovih koraka mogu izgledati previše suvišni, ali ne ometaju upotrebljivost i zapravo poboljšati sigurnost, iako u situacijama za koje se nadamo da će biti rijetke. U 99% slučajeva korisnik će omogućiti resetovanje u vrlo kratkom vremenskom periodu i neće ponovo resetovati lozinku u bliskoj budućnosti.
Uloga CAPTCHA
Oh, CAPTCHA, sigurnosna funkcija koju svi volimo da mrzimo! Zapravo, CAPTCHA nije toliko zaštitni alat koliko je alat za identifikaciju - bilo da ste osoba ili robot (ili automatska skripta). Njegova svrha je izbjeći automatsko podnošenje obrasca, što, naravno, moći koristiti kao pokušaj provale sigurnosti. U kontekstu poništavanja lozinke, CAPTCHA znači da se funkcija resetiranja ne može grubo prisiliti da korisniku pošalje neželjenu poštu ili pokuša utvrditi postojanje naloga (što, naravno, neće biti moguće ako slijedite savjete u odjeljku o provjera identiteta).
Naravno, sama CAPTCHA nije savršena; Postoje mnogi presedani za njegovo „hakovanje“ softvera i postizanje dovoljnih stopa uspjeha (60-70%). Osim toga, postoji rješenje prikazano u mom postu o , gdje možete platiti ljudima djeliće centa za rješavanje svake CAPTCHA i postizanje stope uspješnosti od 94%. Odnosno, ranjivo je, ali (malo) podiže barijeru ulasku.
Pogledajmo primjer PayPal-a:
U ovom slučaju, proces resetovanja jednostavno ne može započeti dok se CAPTCHA ne riješi, dakle teoretski nemoguće je automatizovati 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 servis počne da bude napadnut (ovde dobro dođe logovanje, ali o tome kasnije), dodavanje CAPTCHA ne može biti lakše.
Tajna pitanja i odgovori
Uz sve metode koje smo razmatrali, uspjeli smo resetirati lozinku samo pristupom računu e-pošte. Kažem „samo“, ali, naravno, nezakonito je dobiti pristup tuđem nalogu e-pošte. treba biti složen proces. kako god .
Zapravo, gornji link o hakiranju Yahoo-a Sarah Palin! služi u dvije svrhe; prvo, ilustruje koliko je lako hakirati (neke) naloge e-pošte, a drugo, pokazuje koliko loša bezbednosna pitanja mogu da se koriste sa zlonamernim namerama. Ali na ovo ćemo se vratiti kasnije.
Problem sa XNUMX% poništavanjem lozinke na bazi e-pošte je taj što integritet naloga za lokaciju koju pokušavate da resetujete postaje XNUMX% ovisan o integritetu naloga e-pošte. Svako ko ima pristup vašoj e-pošti ima pristup svakom nalogu koji se može resetovati jednostavnim primanjem e-pošte. Za takve naloge, e-pošta je „ključ svih vrata“ vašeg onlajn života.
Jedan od načina da se smanji ovaj rizik je implementacija sigurnosnog pitanja i obrasca odgovora. Nema sumnje da ste ih već vidjeli: odaberite pitanje na koje samo vi možete odgovoriti must znate odgovor, a onda kada resetujete lozinku od vas će se tražiti da je unesete. Ovo dodaje povjerenje da je osoba koja pokušava resetirati zaista vlasnik računa.
Da se vratimo Sarah Palin: greška je bila u tome što su se odgovori na njena sigurnosna pitanja/pitanja lako mogli pronaći. Naročito kada ste tako značajna javna ličnost, podaci o djevojačkom prezimenu vaše majke, istoriji obrazovanja ili o tome gdje je neko možda živio u prošlosti nisu baš tajna. Zapravo, većinu toga može pronaći gotovo svatko. Evo šta se desilo Sari:
Haker David Kernell je dobio pristup Palininom nalogu tako što je pronašao detalje o njenom porijeklu, poput njenog univerziteta i datuma rođenja, a zatim koristeći Yahoo!-ovu funkciju za oporavak zaboravljene lozinke.
Prije svega, ovo je greška u dizajnu od strane Yahooa! — precizirajući tako jednostavna pitanja, kompanija je suštinski sabotirala vrijednost sigurnosnog pitanja, a time i zaštitu svog sistema. Naravno, resetovanje lozinki za nalog e-pošte je uvek teže jer ne možete dokazati vlasništvo slanjem e-pošte vlasniku (bez druge adrese), ali srećom, danas nema mnogo mogućnosti za kreiranje ovakvog sistema.
Vratimo se na sigurnosna pitanja – postoji opcija da se korisniku omogući da kreira svoja pitanja. Problem je što će to rezultirati užasno očiglednim pitanjima:
Koje je boje nebo?
Pitanja koja izazivaju nelagodu kod ljudi kada se za identifikaciju koristi sigurnosno pitanje osoba (na primjer, u pozivnom centru):
S kim sam spavao za Božić?
Ili iskreno glupa pitanja:
Kako se piše "lozinka"?
Kada su u pitanju sigurnosna pitanja, korisnike treba sačuvati od samih sebe! Drugim riječima, tajno pitanje treba odrediti samu stranicu, ili još bolje, postaviti serija sigurnosna pitanja od kojih korisnik može birati. I nije lako izabrati один; 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 proces 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.
Šta je dobro sigurnosno pitanje? Na to utiče nekoliko faktora:
- To bi trebao biti brief — pitanje mora biti jasno i nedvosmisleno.
- Odgovor mora biti specifično — ne treba nam pitanje na koje jedna osoba može odgovoriti drugačije
- Mogući odgovori bi trebali biti raznolik - postavljanje pitanja o nečijoj omiljenoj boji daje vrlo mali podskup mogućih odgovora
- Поиск odgovor mora biti složen - ako se odgovor može lako pronaći bilo koji (sjetite se ljudi na visokim pozicijama), onda je loš
- Odgovor mora biti stalni s vremenom - ako pitate nečiji omiljeni film, onda bi godinu dana kasnije odgovor mogao biti drugačiji
Kako to biva, postoji web stranica posvećena postavljanju dobrih pitanja tzv . Neka pitanja izgledaju prilično dobra, druga ne prolaze neke od gore opisanih testova, posebno test „lakoće pretraživanja“.
Dozvolite mi da pokažem kako PayPal implementira sigurnosna pitanja i, posebno, napore koje stranica ulaže u autentifikaciju. Iznad smo vidjeli stranicu za početak procesa (sa CAPTCHA), a ovdje ćemo pokazati šta se dešava nakon što unesete svoju email adresu i riješite CAPTCHA:
Kao rezultat, korisnik dobija sljedeće pismo:
Do sada je sve bilo sasvim normalno, ali evo šta se krije iza ovog reset URL-a:
Dakle, sigurnosna pitanja dolaze u igru. Zapravo, PayPal vam također omogućava da poništite lozinku tako što ćete potvrditi broj vaše kreditne kartice, tako da postoji dodatni kanal kojem mnoge web stranice nemaju pristup. Jednostavno ne mogu promijeniti svoju lozinku bez odgovora oboje sigurnosno pitanje (ili neznanje broja kartice). Čak i da je neko oteo moju e-poštu, ne bi mogao da resetuje lozinku za moj PayPal nalog osim ako ne zna malo više ličnih podataka o meni. Koje informacije? Evo opcija sigurnosnih pitanja koje PayPal nudi:
Pitanje škole i bolnice može biti malo nejasno u smislu lakoće pretraživanja, ali ostala nisu tako loša. Međutim, da bi poboljšao sigurnost, PayPal zahtijeva dodatnu identifikaciju za promjena odgovori na sigurnosna pitanja:
PayPal je prilično utopijski primjer sigurnog resetiranja lozinke: implementira CAPTCHA kako bi smanjio rizik od grube sile, zahtijeva dva sigurnosna pitanja, a zatim zahtijeva još jednu vrstu potpuno drugačijeg identiteta samo da bi promijenio odgovore - i to nakon što korisnik se već prijavio. Naravno, to smo upravo mi očekivano sa PayPal-a; je finansijska institucija koja posluje sa velikim sumama novca. Ovo ne znači da svako resetovanje lozinke mora da prati ove korake – u većini slučajeva to je previše – ali je dobar primer za slučajeve u kojima je bezbednost ozbiljan posao.
Pogodnost sistema sigurnosnih pitanja je da ako ga niste odmah implementirali, možete ga dodati kasnije ako nivo zaštite resursa to zahtijeva. Dobar primjer za to je Apple, koji je tek nedavno implementirao ovaj mehanizam [članak napisan 2012.]. Kada sam počeo da ažuriram aplikaciju na svom iPad-u, video sam sledeći zahtev:
Tada sam vidio ekran na kojem sam mogao odabrati nekoliko parova sigurnosnih pitanja i odgovora, kao i adresu e-pošte za spašavanje:
Što se tiče PayPal-a, pitanja su unaprijed odabrana i neka od njih su zapravo prilično dobra:
Svaki od tri para pitanja/odgovora predstavlja različit skup mogućih pitanja, tako da postoji mnogo načina za konfigurisanje naloga.
Drugi aspekt koji treba razmotriti u vezi sa odgovorom na vaše sigurnosno pitanje je skladištenje. Posjedovanje baze podataka u obliku običnog teksta u bazi podataka predstavlja gotovo iste prijetnje kao i lozinka, naime da otkrivanje baze podataka trenutno otkriva vrijednost i dovodi ne samo aplikaciju u opasnost, već i potencijalno potpuno različite aplikacije koje koriste ista sigurnosna pitanja (tu opet ). Jedna opcija je sigurno heširanje (snažan algoritam i kriptografski nasumična sol), ali za razliku od većine slučajeva skladištenja lozinki, može postojati dobar razlog da odgovor bude vidljiv kao običan tekst. Tipičan scenario je provjera identiteta od strane telefonskog operatera uživo. Naravno, heširanje 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 lociran na nekom nivou kriptografske memorije, čak i ako se radi samo o simetričnoj enkripciji . rezimirati: tretiraj tajne kao tajne!
Poslednji aspekt bezbednosnih pitanja i odgovora je da su oni ranjiviji na društveni inženjering. Pokušaj direktnog izdvajanja lozinke na tuđi nalog je jedno, ali započeti razgovor o njenom formiranju (popularno sigurnosno pitanje) je potpuno drugačija. U stvari, možete vrlo dobro komunicirati s nekim o mnogim aspektima njihovog života koji mogu predstavljati tajno pitanje, a da ne izazovete sumnju. Naravno, sama poenta sigurnosnog pitanja je da se ono odnosi na nečije životno iskustvo, pa je za pamćenje, i tu je problem - ljudi vole da pričaju o svojim životnim iskustvima! Malo toga možete učiniti po tom pitanju, samo ako odaberete takve opcije sigurnosnog pitanja da budu manje vjerovatno bi mogao biti izvučen socijalnim inženjeringom.
[Nastavlja se.]O pravima reklame
VDSina nudi pouzdan , svaki server je povezan na internet kanal od 500 megabita i zaštićen je od DDoS napada besplatno!
izvor: www.habr.com