Kohë më parë kam pasur mundësinë të rifilloj të mendoj për atë se si duhet të funksionojë funksioni i rikuperimit të sigurt të fjalëkalimit, fillimisht kur e inkorporova këtë funksionalitet në , dhe pastaj kur i ndihmova një personi tjetër të bënte diçka të ngjashme. Në rastin e dytë, doja t'i jepja një link në burimin kanonik me të gjitha detajet mbi implementimin e sigurt të funksionit të rikuperimit. Megjithatë, problemi është se nuk ekziston një burim i tillë, së paku një që përshkruan gjithçka që më duket e rëndësishme. Prandaj, vendosa ta shkruaj unë vetë.
E shihni, bota e fjalëkalimeve të harruara është në të vërtetë mjaft misterioze. Ekzistojnë shumë pikëpamje të ndryshme, të gjithanshme dhe një mori pikëpamjesh mjaft të rrezikshme. Ka të ngjarë që me secilën nga ato të keni përballur si përdorues përfundimtar; prandaj, do të përpiqem të shfrytëzoj këto shembuj për të treguar se kush po bën gjithçka siç duhet dhe kush jo, dhe se në çfarë duhet të fokusohemi për implementimin e duhur të funksionit në aplikacionin tuaj.
Ruajtja e fjalëkalimeve: heshim, enkriptim dhe (oh!) tekst i qartë
Nuk mund të diskutojmë se çfarë duhet bërë me fjalëkalimet e harruara përpara se të diskutojmë për mënyrën e ruajtjes së tyre. Në bazën e të dhënave, fjalëkalimet ruhen në një nga tre forma kryesore:
- Tekst i qartë. Ekziston një kolonë me fjalëkalimin që ruhet në formën e zakonshme tekstuale.
- I enkriptuar. Zakonisht me ndihmën e enkriptimit simetrik (një çelës përdoret si për enkriptimin ashtu edhe për dekriptimin), ndërsa fjalëkalimet e enkripuara gjithashtu ruhen në një kolonë.
- I heshur. Një proces njëanshor (fjala kalim mund të hesohet, por nuk mund të dehesohet); fjala kalim, shpresojmë, shoqërohet me kripë dhe secili prej tyre ndodhet në kolonën e vet.
Le t'i qartësojmë menjëherë pyetjen më të thjeshtë: kurrë mos e ruhani fjalëkalimin në tekst të qartë! Kurrë. Një e vetme dobësi ndaj , një kopje rezervë e bërë pak e mençur ose një nga dhjetëra gabimet e tjera të thjeshta — dhe gjithçka, game over, të gjitha fjalëkalimet tuaja — do thoni, më falni, fjalëkalimet e të gjithë klientëve tuaj do të bëhen pronë publike. Sigurisht, kjo do të nënkuptojë një probabilitet të madh që pronë publike të bëhen nga të gjitha llogaritë e tyre në sisteme të tjera. Dhe kjo do të jetë faji juaj.
Kriptimi është më i mirë, por ka dobësi të tijat. Problemi i kriptimit është dekriptimi; mund të merrni këto kodime që duken të çmendura dhe t'i transformoni përsëri në tekst të thjeshtë, dhe kur kjo ndodh, ne kthehemi në situatën e fjalëkalimeve të lexueshme. Si ndodh kjo? Një defekt i vogël depërton në kodin që merret me dekriptimin e fjalëkalimit, duke e bërë atë publik — kjo është njëra mënyrë. Hakerat fitojnë akses në makinën ku ruhen të dhënat e kriptuara — kjo është një tjetër mënyrë. Një tjetër mënyrë është gjithashtu të vidhen kopjet rezervë të bazës së të dhënave, dhe dikush gjithashtu merr çelësin e kriptimit, i cili shpesh ruhet shumë pasigurt.
Dhe kjo na çon te heshimi. Ideja e heshimit është se ai realizohet në një drejtim; mënyra e vetme për të krahasuar fjalëkalimin e futur nga përdoruesi me versionin e tij të heshuar është heshimi i të dhënave të futura dhe krahasimi i tyre. Për të parandaluar sulmet me mjete si 'tabelat e harkuara', ne shtojmë rastësinë në proces përmes kripti (për të pasur një pamje të plotë lexoni artikullin tim për ruajtjen kriptografike). Në fund të fundit, me implementim të duhur ne mund të jemi me një masë të madhe besimi se fjalëkalimet e heshura nuk do të kthehen kurrë më në tekst të thjeshtë (për avantazhet e algoritmeve të ndryshme të heshimit do të flas në një postim tjetër).
Një argument i shkurtër mbi heshimin dhe kriptimin: arsyeja e vetme pse ndonjëherë do t'ju nevojitet të kriptoni, dhe jo të heshoni fjalëkalimin, është kur ju nevojitet të shihni fjalëkalimin në tekst të thjeshtë, dhe këtë nuk duhet ta dëshironit asnjëherë, së paku në situatën e një webb standard. Nëse ju nevojitet, atëherë me siguri po bëni diçka të gabuar!
Kujdes!
Pak më poshtë në tekstin e posts ka një pjesë të një screenshot-i të një faqeje pornografike AlotPorn. Ai është prerë me kujdes, dhe nuk ka asgjë që nuk mund ta shihni në plazh, por nëse kjo sërish mund të shkaktojë ndonjë problem, atëherë mos e rrokni poshtë faqen.
Gjithmonë rivendosni fjalëkalimin, asnjëherë mos ia kujtoni
A keni ndonjëherë pasur kërkesë për të krijuar një funksion për kujtesë fjalëkalimi? Bëni një hap prapa dhe mendoni për këtë kërkesë në anën tjetër: përse na nevojitet kjo "kujtesë"? Sepse përdoruesi e ka harruar fjalëkalimin. Çfarë vërtet duam të bëjmë? Ta ndihmojmë të hyjë përsëri në sistem.
E kuptoj, fjala "kujtesë" përdoret (shpesh) në një kuptim përditshmërie, por në të vërtetë po përpiqemi të ndihmojmë përdoruesin të jetë përsëri online në mënyrë të sigurt. Duke marrë parasysh nevojën për siguri, ka dy arsye pse kujtesa (dmth. dërgimi i fjalëkalimit të përdoruesit) nuk është e përshtatshme:
- Emaili është një kanal i pasigurt. Ashtu siç nuk do ta kalonim asgjë konfidenciale përmes HTTP (do të përdornim HTTPS), nuk është e mençur të dërgojmë asgjë përmes emailit, sepse treni i saj i transportit është i pasigurt. Në fakt, kjo është shumë më keq se thjesht kalimi i informacionit përmes një protokolli transporti të papajisur, sepse emaili shpesh ruhet në një ruajtës, është i aksesueshëm për administratorët e sistemeve, dërgohet dhe shpërndahet, është e aksesueshme për softuerin keqdashës, etj. Emaili i paenkriptuar është një kanal jashtëzakonisht i pasigurt.
- Në çdo rast, nuk duhet të keni qasje në fjalëkalimin. Rishikoni seksionin e mëparshëm rreth ruajtjes — duhet të keni një hash të fjalëkalimit (me një kriptopik të mirë), domethënë nuk duhet të keni asnjë mënyrë për të nxjerrë fjalëkalimin dhe për ta dërguar atë përmes emailit.
Lejoni të ilustrohem problemin me një shembull : Ky është një faqe tipike hyrjeje:
Evidentisht, problemi i parë është se faqja e hyrjes nuk ngarkohet përmes HTTPS, por gjithashtu siti ofron të dërgojë fjalëkalimin ("Dërgo Fjalëkalimin"). Ndoshta ky është një shembull i përdorimit të lartpërmendur të këtij termi, kështu që le të bëjmë një hap tjetër dhe të shohim se çfarë do ndodhë:
Duket pak më mirë, fatkeqësisht; dhe emaili konfirmon ekzistencën e problemit:
Kjo na tregon dy aspekte të rëndësishme të usoutdoor.com:
- Siti nuk hashon fjalëkalimet. Në mënyrën më të mirë, ato kriptohen, por është shumë e mundshme që ato të ruhen në format tekstual; nuk kemi dëshmi tjetër përkundrazi.
- Siti dërgon një fjalëkalim afatgjatë (mund të kthehemi dhe ta përdorim përsëri dhe përsëri) përmes një kanali të pasigurt.
Pas pasi që e shqyrtuam këtë, na nevojitet të kontrollojmë nëse procesi i rikthimit po kryhet në mënyrë të sigurt. E para që duhet të bëjmë është të sigurohemi se kërkuesi ka të drejtë të kryejë rikthimin. Në terma të tjerë, për këtë na nevojitet verifikimi i identitetit; le të shohim çfarë ndodh kur identiteti konfirmohet pa kontrollin paraprak se kërkuesi në të vërtetë është pronari i llogarisë.
Listimi i emrave të përdoruesve dhe ndikimi i tij në anonimitet
Këtë problem është më mirë ta ilustrojmë vizualisht. Problemi:
A e shihni? Vini re njoftimin "There is no user registered with this email address" ("Nuk ka përdorues të regjistruar me këtë adresë emaili"). Problemi, është qartë, ndodh nëse një faqe e tillë konfirmon praninë e një përdoruesi të regjistruar me këtë adresë emaili. Bingo — sapo zbulove fiksimin seksual të burrit/të shefit/të fqinjit tuaj!
Natyrisht, pornografia është një shembull mjaft klasik i rëndësisë së privatësisë, megjithatë rreziku i lidhjes së identitetit me një faqe të caktuar është shumë më i gjerë se situata e mundshme e sikletshme e përshkruar më lart. Një nga rreziqet është inxhinieria sociale; nëse sulmuesi arrin të lidhë një person me shërbimin, atëherë ai do të ketë informacion që mund ta fillojë të përdorë. Për shembull, ai mund të kontaktojë personin duke u shfaqur si një përfaqësues i faqes dhe të kërkojë informacion shtesë, duke përpjekur të kryejë .
Praktikat e tilla gjithashtu shkaktojnë rrezikun e "listimit të emrave të përdoruesve", ku mund të kontrollohet egzistenca në një faqe të tërë koleksionesh emrash përdoruesish ose adresash emaili me kërkesa të thjeshta grupore dhe shqyrtimin e përgjigjeve të tyre. A keni një listë adresash emaili të të gjithë punonjësve dhe disa minuta për të shkruar një skript? Atëherë e kuptoni se cila është problemi!
Cila është alternativa? Në të vërtetë, ajo është mjaft e thjeshtë, dhe realizohet mrekullisht në :
Këtu Entropay nuk zbulon asgjë për ekzistencën në sistemin e saj të adresës emaili për atë që nuk e zotëron këtë adresë. Nëse ju zotëroni këtë adresë dhe ai nuk ekziston në sistem, do të merrni një email të ngjashëm:
Natyrisht, ndodhin situata të pranueshme ku dikush mendon, se është regjistruar në uebfaqe. por nuk është kështu, ose e ka bërë këtë nga një adresë tjetër emaili. Shembulli i paraqitur më sipër e përballon me sukses të dyja situatat. Sigurisht, nëse adresa përputhet, do të merrni një email që lehtëson rinovimin e fjalëkalimit.
Nuanca e zgjidhjes së zgjedhur Entropay është se verifikimi i identitetit bëhet përmes emailit përpara çdo verifikimi online. Disa do të kërkojnë nga përdoruesit të përgjigjen në një pyetje të fshehtë (më shumë për këtë më poshtë) në se si do të fillojë rinovimi; megjithatë, problemi me këtë është se është e nevojshme që të përgjigjeni në pyetje duke ofruar njëlloj të dhënash identifikimi (email ose emër përdoruesi), duke sjellë kështu që është e vështirë të përgjigjeni intuitivisht, pa zbuluar ekzistencën e një llogarie anonime.
Me këtë qasje, ka një ulje të vogël të përdorshmërisë, sepse në rast se përpiqet të rinovojë një llogari që nuk ekziston, nuk ka reagim të menjëhershëm. Sigurisht, kjo është e gjitha në lidhje me dërgimin e emailit, por nga pikëpamja e përdoruesit përfundimtar, nëse ai/ajo fut një adresë të gabuar, do ta kuptojë këtë vetëm kur të marrë emailin. Diçka e tillë mund të shkaktojë disa tension nga ana e tij/saj, por kjo është një çmim i vogël për një proces kaq të rrallë.
Një vërejtje tjetër, pak e shkëputur nga tema: funksionet e ndihmës për hyrjen në sistem, që zbulojnë saktësinë e emrit të përdoruesit ose adresës së emailit, kanë të njëjtin problem. Gjithmonë përgjigjuni përdoruesit me mesazhin “Kombinimi i emrit të përdoruesit dhe fjalëkalimit është i pavlefshëm” (Your username and password combination is invalid), dhe jo të konfirmoni në mënyrë të drejtpërdrejtë ekzistencën e informacionit identifikues (p.sh., “emri i përdoruesit është i saktë, por fjalëkalimi është i gabuar”).
Dërgimi i fjalëkalimit të rinovuar kundrejt dërgimit të URL-së për rinovim
Koncepti tjetër që duhet të diskutojmë lidhet me mënyrën e rinovimit të fjalëkalimit. Ka dy zgjidhje të njohura:
- Gjenerimi i një fjalëkalimi të ri në server dhe dërgimi i tij me email
- Dërgimi i një emaili me një URL unik që lehtëson procesin e rinovimit
Pavarësisht , pika e parë nuk duhet kurrë të përdoret. Problemi i tij është se kjo nënkupton ekzistencën e një passwordi të ruajtur, i cili mund të kthehet dhe përdoret sërish në çdo moment; ai u dërgua përmes një kanali të papërgatitur dhe mbetet në hyrjet tuaja. Ka një mundësi që hyrjet të sinkronizohen me pajisjet mobile dhe klientin e postës elektronike, plus që ato mund të ruhen online në një shërbim të postës elektronike për një kohë të gjatë. Sinnifikimi është që posta elektronike nuk mund të konsiderohet një mjet të sigurt për ruajtjen afatgjatë.
. Por përveç kësaj, pika e parë ka një problem të rëndësishëm tjetër - ajo e thjeshton maksimalisht bllokimin e llogarisë me qëllim të keq. Nëse unë e di adresën e postës elektronike të atij që zotëron llogarinë në uebsajtin, mund ta bllokoj atë në çdo moment, thjesht duke rikuperuar passwordin e tij; kjo është një sulm i tipit "ndalimi i shërbimit", i paraqitur në një pllakë me borde blu! Pikërisht për këtë arsye rikuperimi duhet të kryhet vetëm pas një verifikimi të suksesshëm të të drejtave të kërkuesit.
Kur flasim për URL-në e rikuperimit, ne nënkuptojmë adresën e uebsajtit, e cila është unike për këtë rast të veçantë të procesit të rikuperimit. Natyrisht, ajo duhet të jetë rastësore, nuk duhet të jetë e lehtë për t'u zbuluar dhe nuk duhet të përmbajë ndonjë lidhje të jashtme me llogarinë që lehtëson rikuperimin. Për shembull, URL-ja e rikuperimit nuk duhet të jetë thjesht një rrugë si "Reset/?username=JohnSmith".
Ne duam të krijojmë një token unik, i cili mund të dërgohet përmes postës si URL për rikuperimin, dhe më pas të krahasohet me regjistrin në server me llogarinë e përdoruesit, duke konfirmuar kështu se pronari i llogarisë me të vërtetë është po ai person që po përpiqet të rikuperojë passwordin. Për shembull, tokeni mund të duket si "3ce7854015cd38c862cb9e14a1ae552b" dhe të ruhet në një tabelë së bashku me ID-në e përdoruesit, që po kryen rikuperimin, dhe kohën e krijimit të tokenit (më shumë për këtë pak më poshtë). Kur dërgohet letra, ajo përmban një URL si "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", dhe kur përdoruesi e ngarkon atë, faqja kontrollon ekzistencën e tokenit, më pas konfirmon informacionin e përdoruesit dhe lejon ndryshimin e passwordit.
Natyrisht, pasi procesi i përshkruar më sipër (shpresojmë) i lejon përdoruesit të krijojë një fjalëkalim të ri, duhet të garantoni ngarkimin e URL-së përmes HTTPS. Jo, , kjo URL me token duhet të përdorë sigurinë e nivelit të transportit që forma e hyrjes së fjalëkalimit të ri të mos jetë e ekspozuar ndaj sulmeve dhe fjalëkalimi i krijuar nga përdoruesi të dërgohet përmes një lidhjeje të sigurt.
Gjithashtu, për URL-në e rivendosjes duhet të shtohet një kufi në kohë për token, në mënyrë që procesi i rivendosjes të mund të kryhet brenda një intervali të caktuar, për shembull, brenda një ore. Kjo siguron që pasqyra e kohës së rivendosjes të jetë minimale, në mënyrë që ai që merr këtë URL rivendosje të veprojë vetëm brenda këtij intervali shumë të vogël. Natyrisht, sulmuesi mund të niset për të filluar përsëri procesin e rivendosjes, por ai do të ketë nevojë të marrë një URL rivendosjeje tjetër unik.
Në fund, na nevojitet të sigurojmë njëanshmërinë e këtij procesi. Pas përfundimit të procesit të rivendosjes, token duhet të fshihet, kështu që URL e rivendosjes përsëri të mos jetë funksionale. Pika e mëparshme është e nevojshme për të siguruar që sulmuesi të ketë një dritare të vogël të kohës gjatë së cilës mund të manipulojë URL e rivendosjes. Plus, natyrisht, pas një përfundimi të suksesshëm të rivendosjes, token nuk është më e nevojshme.
Disa nga këto hapa mund të duken tepër të tepruar, por ato nuk pengojnë fare përdorshmërinë dhe në të vërtetë rritin sigurinë, edhe pse në situata që, shpresojmë, do të jenë të rralla. Në 99% të rasteve, përdoruesi do të përfitojë nga rivendosja brenda një intervali shumë të shkurtër dhe nuk do të rivendosë fjalëkalimin përsëri në një të ardhme të afërt.
Roli i CAPTCHA
O, CAPTCHA, mjeti i mbrojtjes që të gjithë ne e duam të urrejmë! Në të vërtetë, CAPTCHA është një mjet jo aq shumë mbrojtjeje, sa identifikimi — je njeri apo robot (apo skenar automatizimi). Qëllimi i saj është të shmangë dërgimin automatik të formave, i cili, natyrisht, mund mund të përdoret si një përpjekje për të thyer mbrojtjen. Në kontekstin e rivendosjes së fjalëkalimeve, CAPTCHA do të thotë që funksioni i rivendosjes nuk mund të thyehet me anë të sulmeve brute, për të spamuar përdoruesin, ose për të përpiquar të përcaktojë ekzistencën e llogarive (gjë që, natyrisht, do të jetë e pamundur nëse keni ndjekur këshillat nga seksioni mbi verifikimin e identitetit).
Natyrisht, CAPTCHA vetë nuk është e përsosur; ekzistojnë shumë raste të "hakerimit" të saj dhe arritjes së niveleve të suksesit (60-70%). Për më tepër, ekziston një zgjidhje, e cila është treguar në postimin tim mbi , ku mund të paguani njerëzit disa qindarka për të zgjidhur çdo CAPTCHA dhe për të arritur një tregues suksesi prej 94%. Pra, ajo është e ndjeshme, megjithatë (pak) e rrit barrierën në hyrje.
Le të shohim një shembull PayPal:
Në këtë rast, procesi i rivendosjes nuk mund të fillojë deri sa të zgjidhet CAPTCHA, kështu që teorisht automatizimi i procesit është i pamundur. Teorisht.
Megjithatë, për shumicën e aplikacioneve web, kjo do të ishte tepër dhe kanë sigurisht një ndikim negativ në përdorshmëri — njerëzit thjesht nuk e duan CAPTCHA-në! Për më tepër, CAPTCHA është një gjë, që në rast nevoje mund të ktheheni lehtësisht. Nëse shërbimi fillon të sulmohet (këtu është i dobishëm regjistrimi, por do të flasim më shumë për këtë më vonë), atëherë është shumë e lehtë të shtoni CAPTCHA.
Pyetje të sekretit dhe përgjigje
Me të gjitha metodat e shqyrtuara, ne patëm mundësinë të rivendosim fjalëkalimin, vetëm duke pasur akses në llogarinë e postës elektronike. Unë po them "vetëm", por, natyrisht, qasja e paligjshme në llogarinë e një personi tjetër të postës duhet të jetë një proces i komplikuar. Megjithatë .
Në të vërtetë, lidhja e mësipërme mbi hakerimin e llogarisë së Sarah Palin në Yahoo! shërben për dy qëllime; së pari, ilustron se sa lehtë mund të hakeroheshin (disa) llogari postash, së dyti, tregon se si mund të shfrytëzohen keq pyetjet e këqija të sekretit. Por do të kthehemi te kjo më vonë.
Problemi me rivendosjen e fjalëkalimeve që varen 100% nga emaili është se integriteti i llogarisë së faqes, fjalëkalimi i së cilës po përpiqeni të rivendosni, bëhet 100% e varur nga integriteti i llogarisë së postës elektronike. Çdo kush që ka akses në emailin tuaj, ka akses në çdo llogari që mund të rivendoset thjesht duke marrë një email. Për këto llogari, emaili është "çelësi për të gjitha dyert" e jetës tuaj online.
Një nga mënyrat për të ulur këtë rrezik është implementimi i një modeli të pyetjes dhe përgjigjes sekrete. Pa dyshim, ju tashmë i keni parë ato: zgjidhni një pyetje, për të cilën vetëm ju duhet dini përgjigjen, pas së cilës gjatë rivendosjes së fjalëkalimit ju e keni për atë pyetje. Kjo shton sigurinë që personi që përpiqet të kryejë rivendosjen është me të vërtetë pronari i llogarisë.
Le të kthehemi te Sara Palin: gabimi ishte se përgjigjet për pyetjen e saj sekrete / pyetjet e saj mund të ishin lehtësisht të gjetura. Në veçanti, kur jeni një figurë publike e tillë e rëndësishme, informacioni rreth emrit të vajzës së nënës, historisë së arsimit ose vendit ku dikush mund të ketë jetuar në të kaluarën, nuk është kaq sekret. Në të vërtetë, një pjesë e madhe e tij mund të gjendet nga askush. Kështu ndodhi me Sarën:
Hakeri David Kernell fitoi qasje në llogarinë e Palin duke gjetur detaje të biografisë së saj si universiteti dhe data e lindjes, dhe pastaj duke përdorur funksionin e rikuperimit të fjalëkalimeve të harruara për llogaritë Yahoo!
Në radhë të parë, kjo është një gabim dizajni nga ana e Yahoo! — duke vendosur pyetje kaq të thjeshta, kompania në thelb sabotoi vlerën e pyetjes sekrete dhe, për rrjedhojë, mbrojtjen e sistemit të saj. Sigurisht, rivendosja e fjalëkalimeve për llogarinë e postës elektronike është gjithmonë më e vështirë, sepse nuk mund të konfirmoni pronësinë e saj duke i dërguar pronarit një e-mail (pa një adresë të dytë), por, për fat të mirë, sot për krijimin e një sistemi të tillë nuk ka shumë mundësi përdorimi.
Le të kthehemi te pyetjet sekrete — ekziston opsioni për t'i ofruar përdoruesit mundësinë e krijimit të pyetjeve të veta. Problemi është se si rezultat do të dalin pyetje shumë evidente:
Cila është ngjyra e qiellit?
Pyetje që i vendosin njerëzit në një pozite të rënduar kur për identifikimin përdoren pyetje sekrete njeri (për shembull, në qendër të thirrjeve):
Me kë kam fjetur për Krishtlindje?
Ose pyetje krejtësisht të çmendura:
Si shkruhet 'fjalëkalim'?
Kur bëhet fjalë për pyetjet sekrete, përdoruesit duhet të shpëtohen nga vetvetja! Në fjalë të tjera, pyetja sekrete duhet të përcaktojë vetë faqen, dhe më mirë akoma, të vendosë një seri pyetjesh sekrete, nga të cilat përdoruesi mund të zgjedhë. Dhe jo thjesht të zgjedhë një; në ideal, përdoruesi duhet të zgjedhë dy ose më shumë pyetje sekrete në momentin e regjistrimit të llogarisë, të cilat më pas do të përdoren si një kanal i dytë identifikimi. Prania e disa pyetjeve rrit shkallën e sigurisë në procesin e verifikimit, si dhe ofron mundësinë e shtimit të rastësisë (të mos shfaqet gjithmonë e njëjta pyetje), plus siguron pak redondancë për rastin që përdoruesi i vërtetë të ketë harruar fjalëkalimin.
Si duhet të jetë një pyetje e mirë sekrete? Këtë e ndikon disa faktorë:
- Ajo duhet të jetë e shkurtër — pyetja duhet të jetë e qartë dhe pa dyshime.
- Përgjigjja duhet të jetë konkrete — nuk na nevojitet një pyetje, në të cilën një person mund të përgjigjet ndryshe
- Përgjigjet e mundshme duhet të jenë të ndryshme — një pyetje për ngjyrën e preferuar të dikujt ofron një nëngrup shumë të vogël përgjigjesh
- Kërkimi përgjigjia duhet të jetë e ndërlikuar — nëse përgjigjja mund të gjendet lehtësisht çfarëdo (të kujtojmë njerëzit në pozita të larta), atëherë ajo është e keqe
- Përgjigjja duhet të jetë të pandryshueshme në kohë — nëse pyetet për filmin e preferuar të dikujt, atëherë pas një viti përgjigjja mund të jetë ndryshe
Siç ndodh, ekziston një uebfaqe e dedikuar për pyetje të mira, e quajtur . Disa nga pyetjet duken mjaft të mira, ndërsa disa nuk kalojnë disa nga testet e përmendura më sipër, veçanërisht testin e "lehtësisë së gjetjes".
Më lejoni të demonstroj se si pyetjet sekrete janë realizuar në PayPal dhe, në veçanti, përpjekjet që bënë për identifikim. Më lart kemi parë faqen e fillimit të procesit (me CAPTCHA), dhe këtu do të tregojmë se çfarë ndodh pasi të shkruani adresën e emailit dhe të zgjidhni CAPTCHA:
Si rezultat, përdoruesi merr një email si ky:
Derisa gjithçka të jetë krejt normale, ja se çfarë fshihet pas këtij URL-i për rivendosjen e fjalëkalimit:
Pra, tani hyjnë në lojë pyetjet sekrete. Në të vërtetë, PayPal gjithashtu lejon rivendosjen e fjalëkalimit duke konfirmuar numrin e kartës së kreditit, kështu që ekziston një kanal shtesë në të cilin shumë faqeve nuk kanë qasje. Thjesht nuk mund të ndryshoj fjalëkalimin pa u përgjigjur në të dy pyetjet sekrete (ose pa e ditur numrin e kartës). Edhe nëse dikush arrin të marrë emailin tim, ai nuk do të jetë në gjendje të rivendosë fjalëkalimin e llogarisë PayPal pa ditur diçka më shumë informacion personal në lidhje me mua. Çfarë informacioni? Këtu janë opsionet e pyetjeve sekrete që ofron PayPal:
Pyetja për shkollën dhe spitalin mund të duket pak e dyshimtë në aspektin e thjeshtësisë së kërkimit, por të tjerat nuk janë aq të këqija. Megjithatë, për të rritur sigurinë, PayPal kërkon identifikim të shtuar për ndryshime përgjigjet në pyetje sekrete:
PayPal është një shembull shumë ideal për një procedurë të sigurt për restarimin e fjalëkalimit: implementon CAPTCHA për të ulur rrezikun e provave të dhunshme, kërkon dy pyetje sekrete dhe pastaj një formë tjetër identifikimi për të ndryshuar përgjigjet — dhe kjo pas hyrjes së përdoruesit. Natyrisht, kjo është pikërisht ajo që ne pritej nga PayPal; kjo është një organizatë financiare që punon me sasi të mëdha parash. Kjo nuk do të thotë se çdo restarim fjalëkalimi duhet të ndjekë këto hapa — në shumicën e rasteve, kjo është e tepruar — megjithatë, kjo është një shembull i mirë për rastet kur siguria është një çështje serioze.
Lehtësia e sistemit të pyetjeve sekrete është se, nëse nuk e implementoni menjëherë, mund ta shtoni më vonë nëse niveli i mbrojtjes së burimit e kërkon atë. Një shembull i mirë për këtë është Apple, e cila sapo e ka realizuar këtë mekanizëm [artikulli është shkruar në vitin 2012]. Njëherë duke filluar të përditësoj aplikacionin në iPad, pashë kërkesën e mëposhtme:
Pastaj pashë një ekran ku mund të zgjidhja disa çifte pyetjesh sekrete dhe përgjigjesh, si dhe një adresë elektronike shpëtimi:
Sa i përket PayPal, pyetjet janë zgjedhur paraprakisht dhe disa prej tyre janë në të vërtetë mjaft të mira:
Çdo çift pyetjesh dhe përgjigjesh paraqet një grup të veçantë pyetjesh të mundshme, kështu që ka mjaft mënyra për të konfiguruar llogarinë.
Një tjetër aspekt që duhet marrë parasysh në lidhje me përgjigjen në pyetjen sekrete është ruajtja. Të qenit në DB me tekst të thjeshtë paraqet pothuajse këto kërcënime të njëjta si në rastin e fjalëkalimit, domethënë — zbuluar baza e dhënash shpërthen menjëherë vlerën dhe rrezikon jo vetëm aplikacionin, por edhe potencialisht aplikacione të tjera që përdorin të njëjtat pyetje sekrete (kjo përsëri është ). Një nga mundësitë është hashimi i sigurt (algoritmi i fortë dhe kriiptografi rastësore), megjithatë, në kundërshtim me shumicën e rasteve të ruajtjes së fjalëkalimeve, këtu mund të ketë një arsyetim të arsyeshëm për shfaqjen e përgjigjes si tekst i zakonshëm. Një skenar tipik është verifikimi i identitetit nga një operator i gjallë përmes telefonit. Sigurisht, në këtë rast, hashimi është gjithashtu i vlefshëm (operatori mund ta shkruajë thjesht përgjigjen e dhënë nga klienti), por në rastin më të keq, përgjigjja sekrete duhet të jetë në një nivel të ndonjë depoje kriptografike, madje nëse është vetëm enkriptim simetrik. Të bëjmë një përmbledhje: trajtoni sekretet si sekrete!
Dhe aspekti i fundit i pyetjeve dhe përgjigjeve sekrete është se ato janë më të brishta ndaj inxhinierisë sociale. Të provosh të nxjerrësh drejtpërdrejt fjalëkalimin për një llogari të huaj — është një gjë, ndërsa të bisedosh për arsimimin e tij (një pyetje sekrete e njohur) — është krejtësisht diçka tjetër. Në të vërtetë, ju mund të bisedoni me dikë për shumë aspekte të jetës së tij, të cilat mund të jenë një pyetje sekrete, dhe të mos ngjallni dyshime. Sigurisht, vetë natyra e pyetjes sekrete është se ajo lidhet me përvojën e jetës së dikujt, prandaj ajo është e lehtë për t'u mbajtur mend, dhe pikërisht kjo është problemi — njerëzit e duan të flasin për përvojat e tyre të jetës! Me këtë mund të bëni shumë pak, vetëm nëse zgjidhni mundësi të tilla për pyetje sekrete që kanë mundësi më të ulëta për t'u tërhequr nga inxhinieria sociale.
[Vazhdon.]
SOF6
VDSina ofron serverë të besueshëm , çdo server është i lidhur me një kanal interneti prej 500 Megabit dhe është i mbrojtur falas nga sulmet DDoS!
Burimi: habr.com
