Nedavno sem imel čas razmisliti o tem, kako naj deluje funkcija varnega ponastavitve gesla, sprva, ko sem to funkcionalnost implementiral v , nato pa, ko sem pomagal narediti kaj podobnega drugi osebi. V drugem primeru sem želel zanj pripraviti povezavo na kanonični vir z vsemi podrobnostmi o varni implementaciji funkcije ponastavitve gesla. Vendar pa je težava v tem, da takšnega vira ni, vsaj ne takega, ki opisuje vse, kar se mi zdi pomembno. Zato sem se odločil, da ga napišem sam.
Vidite, svet pozabljenih gesel je pravzaprav precej skrivnosten. Obstajajo številni različni, povsem sprejemljivi pogledi in kup precej nevarnih. Verjetno ste se s vsakim od njih večkrat srečali kot končni uporabnik; zato bom poskušal uporabiti te primere, da pokažem, kdo dela vse prav in kdo ne, ter na čem se je treba osredotočiti za pravilno implementacijo funkcije v svoji aplikaciji.
Shranjevanje gesel: hashanje, šifriranje in (oh!) navaden tekst
Ne moremo razpravljati o tem, kaj storiti s pozabljenimi gesli, preden ne razpravljamo o načinu njihovega shranjevanja. V bazi podatkov so gesla shranjena na enega od treh osnovnih načinov:
- Navaden tekst. Obstaja stolpec z geslom, ki je shranjeno v običajnem besedilu.
- Šifrirano. Običajno z uporabo simetričnega šifriranja (en ključ se uporablja tako za šifriranje kot za dešifriranje), šifrirana gesla pa so prav tako shranjena v enem stolpcu.
- Hashirano. Enosmerni postopek (geslo se lahko hashi, vendar se ne more dehashirati); geslo, upam, da, je spremljano s soljo, in vsak od njiju se nahaja v svojem stolpcu.
Poglejmo kar takoj najprej najpreprostejše vprašanje: nikoli ne shranjujte gesel v navadnem besedilu! Nikoli. Ena sama ranljivost za , ena nepremišljena varnostna kopija ali ena od številnih drugih preprostih napak — in to je to, konec igre, vsa vaša gesla — torej, oprostite, gesla vseh vaših strank bodo postala javna. Seveda bo to pomenilo ogromno verjetnost, da bodo javna za vse njihove račune v drugih sistemih. In to bo vaša krivda.
Šifriranje je bolje, ali ima svoje slabosti. Problem šifriranja leži u dešifrovanju; moguće je uzeti ove lude šifre i prevesti ih nazad u običan tekst, a kada se to dogodi, vraćamo se na situaciju sa čitljivim lozinkama. Kako se to događa? Mali nedostatak ulazi u kod koji se bavi dešifrovanjem lozinke, čineći je javno dostupnom — to je jedan od načina. Hakeri dobijaju pristup mašini na kojoj se čuvaju šifrovani podaci — to je drugi način. Još jedan način je ponovo taj da se koristi rezervna kopija baze podataka, a neko takođe dobija šifrirajući ključ, koji se često čuva veoma nepouzdano.
I to nas dovodi do heširanja. Ideja heširanja je da se ono odvija u jednom pravcu; jedini način za upoređivanje lozinke koju je korisnik uneo sa njenom heširanom verzijom je heširanje unete lozinke i njihovo međusobno poređenje. Da bismo sprečili napade pomoću alata kao što su 'dugačke tabele', dodajemo slučajnost u proces pomoću soli (za potpunost, pročitajte moj o kriptografskom skladištenju). Na kraju, uz pravilnu implementaciju možemo sa velikim stepenom sigurnosti tvrditi da heširane lozinke nikada više neće postati običan tekst (o prednostima različitih heširajućih algoritama ću govoriti u drugom postu).
Kratka razlika između heširanja i šifriranja: jedini razlog zbog kojeg ćete ikada morati da šifrirate, a ne heširate lozinku — je kada želite da vidite lozinku u običnom tekstu, a to nikada ne bi trebalo da želite, bar u situaciji sa standardnim veb sajtom. Ako vam to treba, verovatno radite nešto pogrešno!
Pozor!
Niže u tekstu posta nalazi se deo snimka ekrana pornografskog veb sajta AlotPorn. Pažljivo je isečen, i zaista nema ništa od onoga što se ne može videti na plaži, ali ako to i dalje može izazvati neke probleme, nemojte skrolovati niz.
Uvek resetujte lozinku, nikoli nikada je ne podsećajte
Da li su vas ikada tražili da kreirate funkciju podsećanja Zastavljate? Pomislite na to prošnju iz suprotnog ugla: zašto je potrebno ovo „podsećanje“? Zato što je korisnik zaboravio svoju lozinku. Šta zapravo želimo da uradimo? Pomoći mu da se ponovo prijavi.
Razumem, reč „podsećanje“ se koristi (često) u konverzacijskom smislu, ali zapravo pokušavamo bezbedno pomoći korisniku da ponovo bude online. Budući da nam je potrebna bezbednost, postoje dva razloga zbog kojih podsećanje (tj. slanje korisnikovih lozinki) nije adekvatno:
- Email je nesiguran kanal. Baš kao što ne bismo slali ništa poverljivo putem HTTP-a (koristili bismo HTTPS), nije preporučljivo slati ništa putem email-a, jer njegov transportni sloj nije siguran. U stvari, to je mnogo gore od običnog slanja informacija putem nezaštićenog transportnog protokola, jer se email često čuva na uređajima, dostupna je sistemskim administratorima, proslijeđuje se i deluje, dostupna je zlonamernim programima, itd. Nešifrovani email je izuzetno nesiguran kanal.
- U svakom slučaju ne biste trebali imati pristup lozinki. Ponovo pročitajte prethodni deo o skladištenju — morate imati heš lozinke (sa dobrom jakom solju), to jest nipošto ne biste trebali biti u mogućnosti da izvlačite lozinku i šaljete je email-om.
Dozvolite mi da ilustrujem problem na primeru : Ovo je tipična stranica za prijavu:
Očigledno je prvi problem to što se stranica za prijavu ne učitava putem HTTPS-a, ali sajt takođe nudi slanje lozinke („Send Password“). Možda je ovo primer gore pomenutog konverzacijskog korišćenja ovog termina, pa hajde da učinimo još jedan korak i vidimo šta će se desiti:
Izgleda neznatno bolje, nažalost; i email potvrđuje postojanje problema:
Ovo nam govori o dva važna aspekta usoutdoor.com:
- Sajt ne hešira lozinke. U najboljem slučaju, šifruju se, ali je vrlo verovatno da se čuvaju u tekstualnom formatu; svedočanstvo suprotnog ne vidimo.
- Sajt šalje dugotrajnu lozinku (možemo se vraćati i koristiti je ponovo i ponovo) putem nesigurnog kanala.
Ko se s tem spoprimemo, moramo preveriti, ali se postopek ponastavitve izvaja na varen način. Prvo, kar je potrebno, je preveriti, ali ima prosilec pravico do ponastavitve. Z drugimi besedami, pred tem potrebujemo preverjanje identitete; poglejmo, kaj se zgodi, ko je identiteta potrjena brez predhodne potrditve, da je prosilec res lastnik računa.
Seznam uporabniških imen in njegov vpliv na anonimnost
To težavo je najbolje ponazoriti vizualno. Problem:
Vidite? Pozorite na sporočilo „There is no user registered with this email address“ („Uporabnik s tem e-poštnim naslovom ni registriran“). Težava se očitno pojavi, če takšno spletno mesto potrdi prisotnost registriranega uporabnika s tem e-poštnim naslovom. Bingo – pravkar ste odkrili pornografski fetiš vašega moža/šefa/soseda!
Seveda je pornografija precej klasičen primer pomembnosti zasebnosti, vendar je nevarnost povezovanja identitete s specifično spletno stranjo mnogo širša od zgoraj opisanega potencialno neprijetnega položaja. Ena izmed nevarnosti je socialno inženirstvo; če napadalec lahko poveže osebo s storitvijo, pridobi informacije, ki jih lahko začne uporabljati. Na primer, lahko stopi v stik z osebo in se lažno predstavi kot predstavnik spletne strani, da bi zahteval dodatne informacije, poskuša izvesti .
Takšne prakse prav tako predstavljajo nevarnost »seznama uporabniških imen«, kjer lahko z enostavnimi skupinskimi poizvedbami preverimo obstoj celotne zbirke uporabniških imen ali e-poštnih naslovov na spletnem mestu in analiziramo njihove odgovore. Imate seznam e-poštnih naslovov vseh zaposlenih in nekaj minut za pisanje skripta? Potem vidite, v čem je težava!
Kakšna pa je alternativa? V resnici je precej preprosta in odlično izvedena na :
Tukaj Entropay ne razkriva ničesar o obstoju e-poštnega naslova v svojem sistemu tistemu, ki ne upravlja s tem naslovom. Če ste lastnik s tem naslovom in ne obstaja v sistemu, boste prejeli podobno elektronsko sporočilo:
Seveda so možne sprejemljive situacije, v katerih nekdo misli, da se je registriral na spletnem mestu. vendar temu ni tako, ali pa je to storil z druge e-pošte. Zgornji primer uspešno obravnava obe situaciji. Očitno, če se naslov ujema, boste prejeli sporočilo, ki poenostavi ponastavitev gesla.
Natančnost izbranega rešenja Entropay je v tem, da se preverjanje identitete izvede preko elektronske pošte pred kakršnimikoli spletnimi preverjanji. Nekatere spletne strani od uporabnikov zahtevajo odgovor na skrivno vprašanje (več o tem spodaj) do ko se lahko začne ponastavitev; vendar je težava v tem, da je treba odgovoriti na vprašanje, pri čemer je treba zagotoviti kakršno koli obliko identifikacije (e-pošto ali uporabniško ime), zaradi česar je nato skoraj nemogoče odgovoriti intuitivno, ne da bi razkrili obstoječnost računa anonimnega uporabnika.
Pri takšnem pristopu je majhna zmanjšana uporabnost, ker ob poskusu ponastavitve neobstoječega računa ni takojšnje povratne informacije. Seveda je v tem celoten namen pošiljanja elektronskega sporočila, vendar z vidika pravega končnega uporabnika, če vpiše napačen naslov, izve o tem šele, ko prejme sporočilo. To lahko povzroči določeno napetost z njegove strani, vendar je to majhna cena za tako redek postopek.
Še ena opomba, ki nekoliko odstopa od teme: funkcije pomoči pri prijavi, ki razkrivajo pravilnost uporabniškega imena ali e-poštnega naslova, imajo enako težavo. Vedno odgovorite uporabniku s sporočilom 'Nepravilna kombinacija uporabniškega imena in gesla' (Vaša kombinacija uporabniškega imena in gesla ni veljavna), in ne potrjujte izrecno obstoja identifikacijskih informacij (na primer, 'uporabniško ime je pravilno, vendar je geslo napačno').
Pošiljanje gesla za ponastavitev proti pošiljanju URL-ja za ponastavitev
Naslednja koncept, o katerem se moramo pogovoriti, se nanaša na način ponastavitve gesla. Obstajajo dve priljubljeni rešitvi:
- Generiranje novega gesla na strežniku in pošiljanje po elektronski pošti
- Pošiljanje elektronskega sporočila z edinstvenim URL-jem, ki poenostavi postopek ponastavitve
Kljub temu , prvi točki nikoli ne bi smeli uporabljati. Njena težava je, da to pomeni obstoj shranjenega gesla, do katerega se lahko vrnete in ga ponovno uporabite kadarkoli; poslano je bilo preko nezaščitenega kanala in ostaja v vašem prejetem sporočilu. Obstaja možnost, da so prejeto sporočilo sinhronizirano z mobilnimi napravami in e-poštnim odjemalcem, poleg tega pa se lahko dolgo časa shranjujejo na spletnem servisu za e-pošto. Smisel je v tem, da e-poštni predal ni zanesljivo sredstvo za dolgoročno shranjevanje.
Toda poleg tega ima prva točka še en resen problem — ji kar se da poenostavi blokado računa z zlonamernimi nameni. Če poznam e-poštni naslov tistega, ki ima račun na spletni strani, ga lahko kadar koli zablokiram, samo s ponastavitvijo njegovega gesla; to je napad tipa 'zanikanje storitve', postrežen na krožniku z modrim robom! Zato se mora ponastavitev opraviti le po uspešni verifikaciji pravice do nje.
Ko govorimo o URL ponastavitvi, imamo v mislih spletni naslov, ki je edinstven za ta specifičen primer postopka ponastavitve. Seveda mora biti naključen, ne sme biti lahko uganljiv in ne sme vsebovati nobenih zunanjih povezav na račun, ki bi olajšale ponastavitev. Na primer, URL ponastavitve ne sme biti samo pot tipa 'Reset/?username=JohnSmith'.
Želimo ustvariti edinstven žeton, ki ga lahko pošljemo po pošti kot URL ponastavitve, nato pa ga primerjati z zapisom na strežniku s uporabniškim računom, s čimer potrdimo, da je lastnik računa res isti oseba, ki poskuša ponastaviti geslo. Na primer, žeton je lahko videti '3ce7854015cd38c862cb9e14a1ae552b' in se shrani v tabeli skupaj z ID-jem uporabnika, ki izvaja ponastavitev, in časom generacije žetona (več o tem kasneje). Pri pošiljanju e-pošte vsebuje URL, kot je 'Reset/?id=3ce7854015cd38c862cb9e14a1ae552b', in ko ga uporabnik naloži, stran preveri obstožnost žetona, nato pa potrdi uporabniške informacije in omogoči spremembo gesla.
Seveda, ker proces, opisan zgoraj (upajmo), omogoča uporabniku ustvariti novo geslo, je treba zagotoviti nalaganje URL-ja prek HTTPS. Ne, , ta URL s tokenom mora uporabljati varnost transportne plasti, da na obrazec za vnos novega gesla ne bi bilo mogoče izvesti napada in ustvarjeno geslo je bilo posredovano preko zaščitene povezave.
Prav tako je treba za URL za ponastavitev dodati časovno omejitev za token, da se postopek ponastavitve lahko izvede v določenem časovnem okviru, recimo v eni uri. To zagotavlja, da je časovno okno za ponastavitev čim manjše, da lahko oseba, ki je prejela ta URL za ponastavitev, deluje le v okviru tega zelo majhnega okna. Seveda, napadalec lahko ponovno začne postopek ponastavitve, vendar bo moral pridobiti še en edinstven URL za ponastavitev.
Nazadnje, moramo poskrbeti, da je ta postopek enkraten. Po končanju postopka ponastavitve je treba token izbrisati, da URL za ponastavitev ne bi bil več aktiven. Prejšnja točka je potrebna, da ima napadalec zelo majhno okno, v katerem lahko manipulira z URL-jem za ponastavitev. Poleg tega, seveda, po uspešni ponastavitvi token ni več potreben.
Nekateri od teh korakov se morda zdijo prekomerni, vendar nikakor ne ovirajo uporabnosti in v resnici povečujejo varnost, četudi v situacijah, ki, upamo, bodo redke. V 99% primerov bo uporabnik izkoristil ponastavitev v zelo kratkem času in ne bo ponastavljal gesla kmalu po tem.
Vloga CAPTCHA
Oh, CAPTCHA, sredstvo zaščite, ki ga vsi tako radi sovražimo! Pravzaprav je CAPTCHA sredstvo ne toliko zaščite, kot je identifikacije — ali ste človek ali robot (ali avtomatiziran skript). Njen namen je preprečiti avtomatsko oddajo obrazcev, kar seveda lahko se lahko uporablja kot poskus vdora zaščite. V kontekstu ponastavitve gesel CAPTCHA pomeni, da funkcije ponastavitve ne bo mogoče zlahka vdreti, da bi ali spamali uporabnika ali poskušali določiti obstoječe račune (kar seveda ne bo mogoče, če ste upoštevali nasvete iz razdelka o preverjanju identitete).
Seveda, sama CAPTCHA ni popolnoma nedolžna; obstajajo številni primeri njenega programskega 'hekanja' in doseganja zadovoljivih stopenj uspešnosti (60-70%). Poleg tega obstaja rešitev, prikazana v mojem prispevku o , pri kateri lahko plačate ljudem delčke centa za rešitev vsake CAPTCHA in dosego stopnje uspešnosti 94%. To pomeni, da je ranljiva, vendar (rahlo) povečuje vstopno oviro.
Poglejmo primer PayPal:
V tem primeru se postopek ponastavitve ne more začeti, dokler CAPTCHA ni rešena, zato teoretično avtomatizacija procesa ni mogoča. Teoretično.
Vendar pa bo to za večino spletnih aplikacij preveč in popolnoma zagotovo predstavlja zmanjšanje uporabnosti — ljudje preprosto ne marajo CAPTCHA! Poleg tega je CAPTCHA takšna stvar, ki jo bo mogoče zlahka dodati, če bo to potrebno. Če storitev začne doživljati napade (tukaj je uporabna logging, a o tem kasneje), je dodati CAPTCHA zelo enostavno.
Zasebna vprašanja in odgovori
Pri vseh doslej razpravljenih metodah smo lahko ponastavili geslo, le da smo imeli dostop do računa elektronske pošte. Govorim 'le', vendar je seveda nezakonit dostop do tujega računa pošte moral biti zapleten postopek. Vendar .
Dejansko zgoraj navedena povezava o hekanju računa Sare Palin na Yahoo! služi dvema namenom; prvič, ponazarja, kako lahko zlahka hekate (nekaterih) poštnih računov, in drugič, pokaže, kako lahko z zlo namenom uporabite slaba zasebna vprašanja. A se bomo k temu vrnili kasneje.
Težava s ponastavitvijo gesel, ki sta povsem odvisna od elektronske pošte, je ta, da celovitost računa na spletnem mestu, katerega geslo poskušate ponastaviti, postane popolnoma odvisna od celovitosti računa elektronske pošte. Kdor ima dostop do vaše elektronske pošte, ima dostop do katerega koli računa, ki ga je mogoče ponastaviti z enostavnim prejemom e-pošte. Za take račune je elektronska pošta 'kljuc do vseh vrat' vašega življenja na spletu.
Eden od načinov za zmanjšanje tega tveganja je uveljavitev vzorca skrivnega vprašanja in odgovora. Brez dvoma ste jih že videli: izberete vprašanje, na katerega le vi morate poznati odgovor, nato pa vas ob ponastavitvi gesla vprašajo to vprašanje. To povečuje zaupanje, da je oseba, ki poskuša opraviti ponastavitev, pravzaprav lastnik računa.
Vrnimo se k Sari Palin: napaka je bila v tem, da so odgovori na njeno skrivno vprašanje/vprašanja enostavno dostopni. Zlasti, ko si tako pomembna javna osebnost, informacije o dekliškem priimku matere, zgodovini izobraževanja ali o tem, kje je nekdo morda živel v preteklosti, niso ravno skrivnost. Dejansko lahko večina teh informacij najde skoraj vsakdo. Tako se je zgodilo s Saro:
Hacker David Kernell je dostopal do računa Palin tako, da je našel podrobnosti o njeni biografiji, kot so njena univerza in datum rojstva, nato pa uporabil funkcijo za obnovitev pozabljenih gesel za račune Yahoo!.
To je predvsem napaka načrtovanja s strani Yahoo! — z navedbo tako preprostih vprašanj je podjetje v bistvu sabotiralo vrednost skrivnega vprašanja, kar pomeni tudi zaščito svojega sistema. Seveda je ponastavitev gesel za račune elektronske pošte vedno težja, saj ne morete potrditi lastništva, če pošljete e-pošto lastniku (brez drugega naslova), vendar pa na srečo danes ni veliko načinov za implementacijo takšnega sistema.
Vrnimo se k skrivnim vprašanjem — obstaja možnost, da uporabniku omogočimo ustvarjanje lastnih vprašanj. Težava je v tem, da se v tem primeru ustvarijo grozno očitna vprašanja:
Kakšne barve je nebo?
Vprašanja, ki ljudi postavljajo v neprijeten položaj, ko za identifikacijo skrivno vprašanje uporablja oseba (na primer v klicnem centru):
S kom sem se zatekel na božič?
Ali očitno neumna vprašanja:
Kako se piše "geslo"?
Ko gre za skrivna vprašanja, je treba uporabnike rešiti pred njimi samimi! Z drugimi besedami, skrivno vprašanje bi moral določiti sam splet, še bolje pa je, da postavi niz skrivnih vprašanj, med katerimi lahko uporabnik izbira. In ne samo enega ; v idealnem primeru bi moral uporabnik izbrati dva ali več skrivnih vprašanjob registraciji računa в момент регистрации аккаунта, ki se bodo nato uporabili kot drugi kanal za identifikacijo. Ima več vprašanj povečuje stopnjo zaupanja v postopek preverjanja, prav tako pa omogoča dodajanje naključnosti (da vprašanje ni vedno isto), poleg tega pa nudi nekaj odvečne varnosti za primer, da se pravi uporabnik ne spomni gesla.
Kakšen naj bo dober tajni vprašanj? To vpliva več dejavnikov:
- Moral bi biti kratko — vprašanje mora biti jasno in nedvoumno.
- Odgovor mora biti konkretno — ne potrebujemo vprašanja, na katero bi lahko en človek odgovoril na različne načine.
- Možni odgovori morajo biti raznoliki — vprašanje o nekaterem najljubšem barvi daje zelo majhno podmnožico možnih odgovorov.
- Iskanje odgovora mora biti težavno — če je odgovor lahko hitro najden katerikoli (spomnimo se ljudi na visokih položajih), je slabo
- Odgovor mora biti постоянным v času — če sprašujete za nečiji najljubši film, se lahko čez leto odgovor spremeni.
Kot to običajno je, obstaja spletna stran, posvečena dobrim vprašanjem, ki se imenuje . Nekatera vprašanja se zdijo kar dobra, druga ne prestanejo del testov, opisanih zgoraj, še posebej preizkusa "enostavnosti iskanja".
Dovolite mi, da pokažem, kako so tajna vprašanja implementirana v PayPal in, posebej, kakšna prizadevanja spletna stran vlaga za identifikacijo. Zgornji del je prikaz procesa začetka (s CAPTCHA), tukaj pa bomo pokazali, kaj se zgodi po tem, ko vnesete e-poštni naslov in rešite CAPTCHA:
Rezultat je, da uporabnik prejme takšno e-pošto:
Dokler je vse povsem običajno, pa tukaj je, kaj se skriva za tem URL za ponastavitev:
Tako na prizorišče stopijo tajna vprašanja. V resnici PayPal tudi omogoča ponastavitev gesla z potrditvijo številke kreditne kartice, zato obstaja dodaten kanal, do katerega imajo dostop številne strani. Preprosto ne morem spremeniti gesla, ne da bi odgovoril na oba tajna vprašanja (ali ne poznam številke kartice). Tudi če nekdo ujame moje e-poštno sporočilo, ne more ponastaviti gesla računa PayPal, če ne ve več osebnih informacij o meni. Katere informacije? Tukaj so možnosti tajnih vprašanj, ki jih ponuja PayPal:
Vprašanje o šoli in bolnici je lahko nekoliko sporno, kar se tiče enostavnosti iskanja, vendar ostala vprašanja niso tako slaba. Vendar pa za povečanje varnosti PayPal zahteva dodatno identifikacijo za spremembe odgovore na skrivna vprašanja:
PayPal je precej utopičen primer varnega ponastavljanja gesla: implementira CAPTCHA za zmanjšanje nevarnosti grobega uganjevanja, zahteva dva skrivna vprašanja in nato zahteva še en način popolnoma druge identifikacije samo za spreminjanje odgovorov — in to po tem, ko se je uporabnik že prijavil. Seveda smo ravno to tudi pričakovali od PayPal; to je finančna organizacija, ki dela z velikimi zneski denarja. To ne pomeni, da mora vsak ponastavitev gesla slediti tem korakom — v večini primerov je to pretirano — vendar je to dober primer za primere, ko je varnost resen posel.
Prednost sistema skrivnih vprašanj je v tem, da če je niste implementirali takoj, jo lahko dodate pozneje, če to zahteva raven zaščite virov. Dober primer tega je Apple, ki je to metodo vpeljal šele nedavno [članek je bil napisan leta 2012]. Ko sem enkrat začel posodabljati aplikacijo na iPadu, sem videl naslednji poziv:
Nato sem videl zaslon, ki je omogočal izbiro več parov skrivnih vprašanj in odgovorov, pa tudi reševalni elektronski naslov:
Kar zadeva PayPal, so vprašanja izbrana vnaprej in neka izmed njih so v resnici precej dobra:
Vsak od treh parov vprašanj in odgovorov predstavlja posamezno množico možnih vprašanj, zato obstaja dovolj načinov za konfiguracijo računa.
Še en vidik, ki ga je treba upoštevati glede odgovora na skrivno vprašanje, je shranjevanje. Shranjevanje v bazi podatkov v običajnem besedilu predstavlja skoraj enake grožnje kot pri geslu, saj takojšnje razkritje baze podatkov razkrije vrednost in ogrozi ne samo aplikacijo, ampak potencialno tudi povsem druge aplikacije, ki uporabljajo ista skrivna vprašanja (to je spet ). Ena od možnosti je varno hashiranje (trd algoritem in kriptografsko naključna sol), vendar pa lahko obstaja upravičen razlog, da je odgovor v obliki navadnega besedila v nasprotju z večino primerov shranjevanja gesel. Tipičen scenarij je preverjanje identitete s strani živega operaterja po telefonu. Seveda se v tem primeru hashiranje uporablja tudi (operater preprosto vnese odgovor, ki ga poda stranka), a v najslabšem primeru mora biti skrivni odgovor na neki ravni kriptografskega skladišča, tudi če gre le za simetrično šifriranje. Povzemimo: ravnajte s skrivnostmi kot s skrivnostmi!
In zadnji vidik skrivnostnih vprašanj in odgovorov je, da so bolj ranljiva za socialni inženiring. Poskusiti neposredno izvleči geslo iz tujega računa je eno, toda začeti pogovor o njegovi izobrazbi (priljubljeno skrivnostno vprašanje) je povsem nekaj drugega. V resnici se lahko resnično pogovarjate z nekom o mnogih vidikih njegovega življenja, ki bi lahko predstavljali skrivnostno vprašanje, in ne bi vzbudili suma. Seveda je bistvo skrivnostnega vprašanja, da je povezano z nekim življenjskim izkušnjam, zato ga je enostavno zapomniti, kar pa predstavlja težavo – ljudje radi govorijo o svojih življenjskih izkušnjah! S tem se ne moremo veliko ukvarjati, razen če izberemo takšne možnosti skrivnostnih vprašanj, ki bi bile s manjšo verjetnostjo izpostavljene socialnemu inženiringu.
[Nadaljevanje sledi.]
V okviru oglaševanja
VDSina ponuja zanesljive , vsak strežnik je povezan z internetnim kanalom 500 Megabit in je brezplačno zaščiten pred DDoS napadi!
Izvor: habr.com
