Nedavno sam imao vremena ponovno razmisliti o tome kako bi trebala raditi funkcija sigurnog resetiranja lozinke, prvo kada sam integrirao ovu funkcionalnost u , a zatim kada sam pomagao drugoj osobi da napravi nešto slično. U drugom slučaju, želio sam mu dati vezu na kanonski resurs sa svim detaljima sigurnog implementiranja funkcije resetiranja. Međutim, problem je u tome što takvog resursa ne postoji, barem ne onog koji opisuje sve što mislim da je važno. Stoga sam odlučio napisati ga sam.
Vidite, svijet zaboravljenih lozinki zapravo je prilično tajanstven. Postoji mnoštvo različitih, potpuno prihvatljivih gledišta i hrpa prilično opasnih. Postoji velika vjerojatnost da ste se s svakim od njih više puta susreli kao krajnji korisnik; stoga ću pokušati iskoristiti ove primjere kako bih pokazao tko sve to ispravno radi, a tko ne, i na čemu se treba fokusirati za pravilnu implementaciju funkcije u vlastitoj aplikaciji.
Pohrana lozinki: hashiranje, šifriranje i (oh!) običan tekst
Ne možemo razgovarati o tome što učiniti sa zaboravljenim lozinkama prije nego što raspravimo o načinu njihova pohranjivanja. U bazi podataka lozinke se pohranjuju u jednom od tri osnovna oblika:
- Običan tekst. Postoji stupac s lozinkom koja se pohranjuje u običnom tekstualnom obliku.
- Šifrirano. Obično uz pomoć simetričnog šifriranja (jedan ključ se koristi i za šifriranje i za dešifriranje), a šifrirane lozinke također se pohranjuju u jednom stupcu.
- Hashirano. Jednosmjerni proces (lozinku je moguće hashirati, ali ne i dehashirati); lozinka, nadajmo se, prati se solju, i svaka od njih nalazi se u vlastitom stupcu.
Odmah da razjasnimo najjednostavnije pitanje: nikada ne pohranjujte lozinke u običnom tekstu! Nikada. Jedna jedina ranjivost , jedna neoprezno napravljena sigurnosna kopija ili jedna od desetaka drugih jednostavnih grešaka — i to je to, game over, sve vaše lozinke — tj. ispričavam se, lozinke svih vaših klijenata postat će javno dobro. Naravno, to bi značilo ogromnu vjerojatnost da će javno dobro postati iz svih njihovih računa u drugim sustavima. I to će biti vaša krivica.
Enkripcija je bolja, ali ima svoje slabosti. Problem enkripcije leži u dekripciji; možete uzeti te ludo izgledajuće šifre i pretvoriti ih natrag u prost tekst, a kada se to dogodi, vraćamo se situaciji s čitljivim lozinkama. Kako se to događa? Mali kvar infiltrira kod koji se bavi dekripcijom lozinke, čineći je javno dostupnom — to je jedan od načina. Hakeri dobivaju pristup mašini na kojoj se nalaze enkriptirani podaci — to je drugi način. Još jedan način ponovo uključuje krađu rezervne kopije baze podataka, a netko također dobiva ključ za enkripciju, koji se često čuva vrlo nepouzdano.
I to nas dovodi do heširanja. Ideja heširanja je u tome da se ono vrši u jednom smjeru; jedini način usporedbe lozinke unesene od strane korisnika s njenom heširanom verzijom je heširanje unesene lozinke i njihovo uspoređivanje. Kako bismo spriječili napade pomoću alata poput "rajzanskih tablica", dodajemo slučajnost u proces pomoću soli (za potpuniju sliku pročitajte moj o kriptografskom pohranjivanju). Na kraju, uz pravilnu implementaciju, možemo s velikim povjerenjem tvrditi da heširane lozinke nikada više neće postati prost tekst (o prednostima različitih algoritama heširanja ću govoriti u drugom postu).
Kratki argument o heširanju i enkripciji: jedini razlog zašto ćete ikad trebati enkriptiirati, a ne heširati lozinku — je kada trebate vidjeti lozinku u prostom tekstu, a to nikada ne biste trebali željeti, barem u situaciji standardnog web-sajta. Ako vam je to potrebno, vjerojatno radite nešto pogrešno!
Pažnja!
Nedugo dolje u tekstu posta nalazi se dio snimke ekrana pornografskog web-sajta AlotPorn. Pažljivo je obrezan, i tako nema ničega što se ne može vidjeti na plaži, ali ako bi to moglo izazvati neke probleme, ne pomičite stranicu prema dolje.
Uvijek resetirajte lozinku, nikada je ne podsjećajte
Da li su vas ikada tražili da stvorite funkciju podsjećanja Lozinke? Povucite se korak unatrag i razmislite o ovoj molbi iz suprotnog kuta: zašto je potrebno ovo "podsjećanje"? Zato što je korisnik zaboravio lozinku. Što zapravo želimo učiniti? Pomoći mu da ponovno pristupi sustavu.
Razumijem da se riječ „podsjećanje” koristi (često) u razgovornom smislu, ali zapravo pokušavamo sigurno pomoći korisniku da ponovno bude online. Budući da nam je potrebna sigurnost, postoje dva razloga zbog kojih podsjećanje (tj. slanje lozinke korisniku) nije prikladno:
- E-pošta je nesiguran kanal. Baš kao što ne bismo slali ništa povjerljivo putem HTTP-a (koristili bismo HTTPS), ne bismo trebali slati ništa putem e-pošte jer je njezin transportni sloj nesiguran. U stvarnosti, to je mnogo gore od jednostavnog slanja informacija putem nezaštićenog transportnog protokola, jer se e-pošta često pohranjuje na pohranama, dostupna je sustavnim administratorima, proslijeđuje se i širi, dostupna je zlonamjernom softveru itd. Nešifrirana e-pošta je izuzetno nesiguran kanal.
- Na kraju, ne biste trebali imati pristup lozinki. Ponovno pročitajte prethodni odjeljak o pohrani - trebate imati hash lozinke (s dobrom solju), što znači da nikako ne biste trebali moći izvući lozinku i poslati je e-poštom.
Dopustite mi da pokažem problem na primjeru : Ovo je tipična stranica za prijavu:
Očigledno, prvi problem je što se stranica za prijavu ne učitava putem HTTPS-a, ali stranica također nudi slanje lozinke ("Send Password"). Možda je ovo primjer ranije spomenute razgovorne upotrebe tog pojma, pa hajde da krenemo još jedan korak dalje i vidimo što će se dogoditi:
Nažalost, ne izgleda mnogo bolje; a e-pošta potvrđuje postojanje problema:
To nam govori o dva važna aspekta usoutdoor.com:
- Stranica ne hashira lozinke. U najboljem slučaju, one su šifrirane, ali je vrlo vjerojatno da se pohranjuju u tekstualnom obliku; svjedočanstvo suprotnog nemamo.
- Stranica šalje dugotrajnu lozinku (možemo se vraćati i koristiti je iznova i iznova) putem nezaštićenog kanala.
Nakon što smo to razjasnili, trebamo provjeriti provodi li se proces resetiranja na siguran način. Prvo se treba uvjeriti ima li podnositelj zahtjeva pravo na izvršavanje resetiranja. Drugim riječima, prije toga potrebna nam je provjera identiteta; pogledajmo što se događa kada se identitet potvrđuje bez prethodne provjere da li podnositelj zahtjeva zaista jest vlasnik računa.
Popis korisničkih imena i njegov utjecaj na anonimnost
Ovaj problem je najbolje ilustrirati vizualno. Problem:
Vidite? Obratite pažnju na poruku „There is no user registered with this email address“ („Korisnik s tom adresom e-pošte nije registriran“). Problem se očito javlja ako takav web-sajt potvrđuje postojanje registriranog korisnika s tom adresom e-pošte. Bingo – upravo ste otkrili porno-fetiš vašeg muža/šefa/susjeda!
Naravno, pornografija je prilično kanoničan primjer važnosti privatnosti, međutim opasnost povezivanja identiteta s određenim web-mjestom daleko je šira od gore opisane potencijalno nelagodne situacije. Jedna od opasnosti je socijalni inženjering; ako napadač uspije povezati osobu s uslugom, dobit će informacije koje može početi koristiti. Na primjer, može kontaktirati osobu predstavljajući se kao predstavnik web-mjesta i zatražiti dodatne informacije, pokušavajući izvršiti .
Slične prakse također uzrokuju nastanak opasnosti „popisivanja korisničkih imena“, pri čemu se može provjeriti postojanje cijelog skupa korisničkih imena ili adresa e-pošte na web-mjestu jednostavnim grupnim upitima i proučavanjem odgovora na njih. Imate li popis adresa e-pošte svih zaposlenika i nekoliko minuta za pisanje skripte? Tada vidite u čemu je problem!
Koja je alternativa? Zapravo, vrlo je jednostavna i divno je realizirana na :
Ovdje Entropay uopće ne otkriva postojanje adrese e-pošte u svom sustavu onome tko ne posjeduje tu adresu. Ako vi posjedujete s ovom adresom koja ne postoji u sustavu, dobit ćete sličan e-mail:
Naravno, mogu postojati prihvatljive situacije u kojima netko misli, da se registrirao na web stranici. no to nije slučaj, ili je to učinio s druge e-mail adrese. Primjer prikazan iznad uspješno pokriva obje situacije. Jasno je da ako se adresa poklapa, dobit ćete e-mail koji pojednostavljuje resetiranje lozinke.
Suština izabranog Entropay rješenja je u tome što se provjera identifikacije vrši putem e-pošte prije bilo kakve online provere. Neki sajtovi traže od korisnika da odgovore na tajno pitanje (više o tome u nastavku) do pre nego što započne resetiranje; međutim, problem je u tome što treba odgovoriti na pitanje, pružajući bilo koji oblik identifikacije (e-mail ili korisničko ime), zbog čega je gotovo nemoguće intuitivno odgovoriti, a da ne otkrijete postojanje naloga anonimnog korisnika.
S ovim pristupom postoji malo smanjenja upotrebljivosti, jer u slučaju pokušaja resetiranja nepostojećeg računa nema trenutne povratne informacije. Naravno, u tome je i cijela svrha slanja e-maila, ali s gledišta stvarnog krajnjeg korisnika, ako unese pogrešnu adresu, tada će prvi put saznati o tome tek kada primi e-mail. To može izazvati određenu napetost s njegove strane, ali to je mala cijena za tako rijedak proces.
Još jedna napomena, koja se malo odmiče od teme: funkcije pomoći pri prijavi, koje otkrivaju ispravnost korisničkog imena ili e-mail adrese, imaju isti problem. Uvijek odgovarajte korisniku porukom 'Pogrešna kombinacija korisničkog imena i lozinke' (You username and password combination is invalid), a ne potvrđujte izričito postojanje identifikacijskih informacija (npr. 'korisničko ime je ispravno, ali je lozinka unesena pogrešno').
Slanje lozinke za resetiranje protiv slanja URL-a za resetiranje
Sljedeća koncepcija koju trebamo raspraviti odnosi se na način resetiranja lozinke. Postoje dva popularna rješenja:
- Generiranje nove lozinke na serveru i njezino slanje putem e-pošte
- Slanje e-maila s jedinstvenim URL-om, koji pojednostavljuje proces resetiranja
Iako , prvu točku nikada ne bi trebalo koristiti. Njegov problem je što to znači postojanje pohranjenje lozinke, kojoj se može pristupiti i ponovo je iskoristiti u bilo kojem trenutku; ona je prenesena nešifriranim kanalom i ostaje u vašem ulaznom poštanskom sandučiću. Postoji mogućnost da se ulazna pošta sinkronizira s mobilnim uređajima i aplikacijom za e-poštu, a uz to može ostati online u web-servisu za e-poštu jako dugo vremena. Suština je da poštanski sandučić ne može biti smatran pouzdanim sredstvom za dugotrajno pohranu.
Osim toga, postoji još jedan ozbiljan problem s prvom točkom - ona maksimalno pojednostavljuje blokiranje računa sa zlonamjernim namjerama. Ako znam adresu e-pošte onoga tko posjeduje račun na web-stranici, mogu ga blokirati u bilo kojem trenutku jednostavno resetirajući njegovu lozinku; to je napad tipa 'usluga odbijena', poslužena na pladnju! Zato treba izvršiti resetiranje samo nakon uspješne provjere prava na to od strane onoga tko to traži.
Kada govorimo o URL-u za resetiranje, mislimo na adresu web-stranice koja je jedinstvena za ovaj konkretni proces resetiranja. Naravno, mora biti nasumična, ne smije biti lako pogoditi i ne smije sadržavati nikakve vanjske linkove na račun koji olakšava resetiranje. Na primjer, URL za resetiranje ne bi trebao biti samo putanja poput 'Reset/?username=JohnSmith'.
Želimo stvoriti jedinstveni token koji se može poslati putem e-pošte kao URL za resetiranje, a zatim ga usporediti s zapisom na poslužitelju s korisničkim računom, potvrđujući tako da je vlasnik računa zaista ista osoba koja pokušava resetirati lozinku. Na primjer, token može izgledati kao '3ce7854015cd38c862cb9e14a1ae552b' i pohraniti se u tablicu zajedno s ID-jem korisnika koji provodi resetiranje i vremenom generiranja tokena (više o tome malo niže). Kada se šalje e-poruka, ona sadrži URL poput 'Reset/?id=3ce7854015cd38c862cb9e14a1ae552b', a kada korisnik učita taj URL, stranica provjerava postojanje tokena, nakon čega potvrđuje informacije o korisniku i omogućava promjenu lozinke.
Naravno, budući da opisani proces (nadamo se) omogućuje korisniku da stvori novu lozinku, potrebno je osigurati da URL bude učitan putem HTTPS-a. Ne, ovaj URL s tokenom mora koristiti sigurnost transportnog sloja, kako bi se sprečila napadačka forma za unos nove lozinke. i lozinka koju je korisnik stvorio morala bi biti prenesena putem sigurnog spoja.
Također, za URL za resetiranje potrebno je dodati vremensko ograničenje za token, kako bi se proces resetiranja mogao izvršiti unutar određenog vremenskog okvira, recimo unutar sata. To osigurava da prozor vremena za resetiranje bude minimalan, tako da osoba koja je primila ovaj URL za resetiranje može djelovati samo unutar tog vrlo malog okvira. Naravno, napadač može ponovno pokrenuti proces resetiranja, ali će mu trebati dobiti još jedan jedinstveni URL za resetiranje.
Na kraju, moramo osigurati jednokratnost ovog procesa. Nakon završetka procesa resetiranja, token treba ukloniti, tako da URL za resetiranje više ne bude funkcionalan. Prethodna točka je potrebna kako bi napadač imao vrlo mali prozor unutar kojeg može manipulirati URL-om za resetiranje. Plus, naravno, nakon uspješnog završetka resetiranja, token više nije potreban.
Neki od ovih koraka mogu se činiti prekomjernim, ali apsolutno ne ometaju korisničko iskustvo i zapravo povećavaju sigurnost, iako se u situacijama za koje se nadamo da će biti rijetke. U 99% slučajeva korisnik će aktivirati resetiranje unutar vrlo kratkog vremenskog razdoblja i neće ponovo resetirati lozinku u bliskoj budućnosti.
Uloga CAPTCHA-e
Oh, CAPTCHA, zaštitno sredstvo koje svi s toliko ljubavi mrzimo! U stvarnosti, CAPTCHA nije toliko zaštita koliko identifikacija — da li ste čovjek ili robot (ili automatizirani skript). Njena svrha je spriječiti automatsko slanje formulara, što, naravno, može može se koristiti kao pokušaj hakiranja zaštite. U kontekstu resetiranja lozinki, CAPTCHA znači da funkciju resetiranja nije moguće hakirati silovitim pokušajem, kako bi se potom spam-ovalo korisnika ili pokušalo odrediti postojanje korisničkih računa (što, naravno, neće biti moguće ako ste pratili savjete iz dijela o provjeri identifikacije).
Naravno, sama CAPTCHA nije savršena; postoje mnogi primeri njenog programskog "hakovanja" i postizanja značajnih uspeha (60-70%). Pored toga, postoji rešenje, prikazano u mom postu o , gde se ljudima mogu plaćati delovi centa za rešavanje svake CAPTCHA i postizanje uspeha od 94%. Dakle, ona je ranjiva, ali (malo) povećava ulaznu barijeru.
Pogledajmo primer PayPal-a:
U ovom slučaju, proces resetovanja jednostavno ne može početi dok se CAPTCHA ne reši, tako da teoretski automatizovati proces nije moguće. Teoretski.
Međutim, za većinu veb aplikacija to će biti prekomerno i definitivno predstavlja smanjenje korisničkog iskustva — ljudima jednostavno ne sviđa CAPTCHA! Pored toga, CAPTCHA je nešto čemu se može lako vratiti po potrebi. Ako usluga počne biti napadnuta (ovde se koristi logovanje, ali o tome više kasnije), lako je dodati CAPTCHA.
Tajni pitanja i odgovori
Kod svih načina koje smo razmatrali, imali smo mogućnost da resetujemo lozinku, samo uz pristup e-mail nalogu. Kažem "samo", ali naravno, nezakoniti pristup tuđem e-mail nalogu treba može biti složen proces. Međutim, .
U stvari, link prikazan iznad o hakovanju naloga Sare Pejlin na Yahoo! ima dve svrhe; prvo, ilustrira koliko je lako hakovati (neke) e-mail naloge, a drugo, pokazuje kako se loša tajna pitanja mogu zloupotrebljavati. Ali o tome ćemo se vratiti kasnije.
Problem sa resetovanjem lozinki koji se u potpunosti oslanjaju na e-mail jeste da integritet naloga na sajtu, čiju lozinku pokušavate da resetujete, postaje u potpunosti zavistan od integriteta e-mail naloga. Bilo ko ko ima pristup vašem e-mailu, ima pristup bilo kojem nalogu koji se može resetovati jednostavnim prijemom e-maila. Za takve naloge e-mail je "ključ svih vrata" vašeg online života.
Jedan od načina kako smanjiti ovaj rizik je implementacija obrasca tajnog pitanja i odgovora. Bez sumnje, već ste ih vidjeli: birate pitanje na koje samo vi moraju znate odgovor, nakon čega vam ga postavljaju prilikom resetiranja lozinke. To dodaje povjerenje da je osoba koja pokušava izvršiti reset zapravo vlasnik računa.
Vratimo se Sari Palin: greška je bila u tome što su odgovori na njezino tajno pitanje/pitanja lako mogli biti pronađeni. Naime, kada ste tako značajna javna figura, informacije poput djevojačkog prezimena majke, povijesti školovanja ili gdje je netko mogao živjeti u prošlosti nisu toliko tajne. U stvarnosti, veći dio toga može pronaći gotovo svatko. Tako se i dogodilo sa Sarom:
Haker David Kernell došao je do pristupa Palininoj računu, pronašavši detalje o njezinoj biografiji, kao što su njezino sveučilište i datum rođenja, a zatim koristeći funkciju vraćanja zaboravljenih lozinki za Yahoo! račune.
Prije svega, to je dizajnerska greška s Yahoo! — postavljanjem tako jednostavnih pitanja, kompanija u osnovi sabotira vrijednost tajnog pitanja, a time i zaštitu svog sustava. Naravno, resetiranje lozinki na e-mail računu uvijek je složenije jer ne možete potvrditi njegovo vlasništvo slanjem e-maila vlasniku (bez drugog adresara), no srećom, danas za stvaranje takvog sustava nema puno mogućnosti.
Vratimo se tajnim pitanjima — postoji opcija osigurati korisniku mogućnost stvaranja vlastitih pitanja. Problem je u tome što u rezultatu nastaju užasno očita pitanja:
Koje je boje nebo?
Pitanja koja stavljaju ljude u neugodnu poziciju, kada za identifikaciju tajno pitanje koristi osobu (npr. u call centru):
S kime sam spavao na Božić?
Ili otvoreno glupa pitanja:
Kako se piše "lozinka"?
Kada su u pitanju tajna pitanja, potrebno je spasiti korisnike od samih sebe! Drugim riječima, tajno pitanje bi trebao odrediti sam sajt, a još bolje, postavljati niz tajnih pitanja iz kojih korisnik može birati. I ne samo birati jedan; u idealnom slučaju, korisnik bi trebao odabrati dva ili više tajnih pitanja u trenutku registracije računa, koji se zatim koriste kao drugi kanal identifikacije. Prisutnost više pitanja povećava razinu sigurnosti u procesu provjere, a također omogućava dodavanje nasumičnosti (ne uvijek prikazivati isto pitanje), plus osigurava malo redundantnosti u slučaju da pravi korisnik zaboravi lozinku.
Koji bi trebao biti dobar tajni pitanje? To ovisi o nekoliko faktora:
- Trebalo bi biti kratko — pitanje bi trebalo biti jasno i nedvosmisleno.
- Odgovor bi trebao biti konkretan — ne trebamo pitanje na koje jedna osoba može odgovoriti na više načina.
- Mogući odgovori trebali bi biti raznoliki — pitanje o nečijoj omiljenoj boji daje vrlo mali skup mogućih odgovora.
- Pretraživanje odgovor bi trebao biti složen — ako se odgovor lako može pronaći bilo koje (sjetimo se ljudi na visokim pozicijama), onda je to loše
- Odgovor bi trebao biti stalnim u vremenu — ako pitamo koji je nečiji omiljeni film, poslije godine odgovor može biti drugačiji.
Kao što to obično biva, postoji web stranica posvećena dobrim pitanjima, koja se zove . Neka pitanja izgledaju prilično dobra, dok druga ne prolaze dio gorenavedenih testova, posebno provjeru 'lakoće pretraživanja'.
Dopustite mi da vam pokažem kako su tajna pitanja implementirana u PayPalu i, posebno, koje napore stranica ulaže za identifikaciju. Iznad smo vidjeli stranicu početka procesa (s CAPTCHA), a ovdje ćemo pokazati što se događa nakon što unesete svoju e-mail adresu i riješite CAPTCHA:
Kao rezultat toga, korisnik dobiva takvo pismo:
Sve je prilično uobičajeno, ali evo što se krije iza ovog URL-a za resetiranje:
Dakle, tajna pitanja ulaze u igru. Ustvari, PayPal također dopušta resetiranje lozinke potvrđivanjem broja kreditne kartice, stoga postoji dodatni kanal kojem ne pristupaju mnoge stranice. Jednostavno ne mogu promijeniti lozinku bez odgovaranja na oba tajna pitanja (ili ne znajući broj kartice). Čak i ako netko preuzme moju e-mail adresu, ne može resetirati lozinku PayPal računa ako ne zna malo više osobnih informacija o meni. Koje informacije? Evo opcija tajnih pitanja koje nudi PayPal:
Pitanje o školi i bolnici može biti malo sumnjivo kada je u pitanju jednostavnost pretraživanja, ali ostala nisu toliko loša. Međutim, radi veće sigurnosti, PayPal zahtijeva dodatnu identifikaciju za promjene odgovore na tajna pitanja:
PayPal je prilično utopijski primjer sigurne obnove lozinke: implementira CAPTCHA kako bi smanjio opasnost od napada pomoću brute force-a, zahtijeva dva tajna pitanja, a zatim zahtijeva još jedan oblik potpuno druge identifikacije samo za promjenu odgovora — i to nakon što se korisnik već prijavio. Naravno, upravo to smo i očekivali od PayPala; to je financijska institucija koja se bavi velikim iznosima novca. Ne znači da svaka obnova lozinke mora slijediti te korake — u većini slučajeva to je preopširno — no to je dobar primjer za situacije u kojima je sigurnost ozbiljna stvar.
Pogodnost sustava tajnih pitanja je u tome što, ako ga odmah niste implementirali, možete ga dodati kasnije, ako to zahtijeva razina zaštite resursa. Dobar primjer toga je Apple, koji je tek nedavno implementirao ovaj mehanizam [članak napisan 2012. godine]. Kada sam jednom započeo ažuriranje aplikacije na iPadu, vidio sam sljedeći zahtjev:
Zatim sam vidio ekran na kojem ste mogli odabrati nekoliko parova tajnih pitanja i odgovora, kao i alternativnu adresu e-pošte:
Što se tiče PayPala, pitanja su unaprijed odabrana i neka od njih su zapravo prilično dobra:
Svaki od tri para pitanja i odgovora predstavlja zaseban skup mogućih pitanja, tako da postoji dovoljan broj načina za konfiguriranje računa.
Još jedan aspekt koji treba razmotriti u vezi s odgovorom na tajno pitanje je pohrana. Čuvanje u bazi podataka kao običan tekst predstavlja gotovo iste prijetnje kao i u slučaju lozinke, naime — otkrivanje baze podataka odmah otkriva vrijednost i dovodi u opasnost ne samo aplikaciju, već i potencijalno potpuno druge aplikacije koje koriste ista tajna pitanja (to je opet ). Jedna od opcija je sigurno heširanje (otpornim algoritmom i kriptografski slučajnom soli), međutim, za razliku od većine slučajeva pohrane lozinki, ovdje može postojati opravdan razlog za vidljivost odgovora kao običnog teksta. Tipični scenarij je provjera identiteta s ljudskim operaterom putem telefona. Naravno, u tom slučaju heširanje je također primjenjivo (operater može samo unijeti odgovora koji je naveo klijent), ali u najgorem slučaju tajni odgovor mora biti na nekom nivou kriptografskog skladišta, čak i ako je to samo simetrična šifra. Ukratko: postupajte s tajnama kao s tajnama!
I posljednji aspekt tajnih pitanja i odgovora — oni su podložniji socijalnom inženjeringu. Pokušavanje direktno izvući lozinku tuđeg računa je jedno, a započeti razgovor o njegovom obrazovanju (popularno tajno pitanje) je sasvim drugo. U stvarnosti, možete razgovarati s nekim o mnogim aspektima njihovog života koji mogu predstavljati tajno pitanje, a da pritom ne izazivate sumnju. Naravno, suština tajnog pitanja je u tome što je povezano s nečijim životnim iskustvom, pa se ono pamti, i upravo u tome leži problem — ljudi vole pričati o svom životnom iskustvu! S tim se malo može učiniti, osim odabira takvih opcija tajnih pitanja, da bi ih s manjom vjerojatnošću bilo moguće izvući socijalnim inženjeringom.
[Nastavlja se.]
U okviru reklame
VDSina nudi pouzdane , svaki server je povezan s internet kanalom od 500 Megabita i besplatno je zaštićen od DDoS napada!
Izvor: habr.com
