Së fundi kam pasur kohë të reflektoj përsëri mbi se si duhet të funksionojë funksioni i rivendosjes së sigurt të fjalëkalimeve, fillimisht kur e integrova këtë funksionalitet në , dhe pastaj kur ndihmova për të krijuar diçka të ngjashme për një person tjetër. Në këtë rast, doja t’i jepja atij një lidhje për burimin kanonik me të gjitha detajet për implementimin e sigurt të funksionit të rivendosjes. Megjithatë, problemi është se nuk ekziston një burim të tillë, të paktën jo një që përshkruan gjithçka që më duket e rëndësishme. Prandaj, vendosa ta shkruaj vetë atë.
Shihni, bota e fjalëkalimeve të harruara është në të vërtetë mjaft enigmatike. Ekzistojnë shumë pikëpamje të ndryshme, krejt të pranueshme dhe një grumbull shumë të rrezikshëm. Ka mundësi që me secilën prej tyre ju jeni përballur shumë herë si përdorues i fundit; prandaj unë do të përpiqem të përdor këto shembuj për të treguar se kush bën gjithçka siç duhet dhe kush jo, dhe në çfarë duhet të përqendroheni për një implementim të saktë të funksionit në aplikacionin tuaj.
Ruajtja e fjalëkalimeve: hashing, enkriptim dhe (ah!) tekst i thjeshtë
Nuk e kemi mundësinë të diskutojmë se çfarë duhet të bëjmë me mënyrën e ruajtjes së fjalëkalimeve të harruara. Në bazën e të dhënave, fjalëkalimet ruhen në një nga tre lloje kryesore:
- Tekst i thjeshtë. Ekziston një kolone me fjalëkalimin, i cili ruhet në formën e zakonshme të tekstit.
- I koduar. Zakonisht duke përdorur kodimin simetrik (nje çelës përdoret për kodim dhe dekodim), dhe fjalëkalimet e koduara gjithashtu ruhen në një kolone.
- Të hash-uar. Një proces njëanshëm (mund të hash-osh fjalëkalimin, por nuk mund ta dekodosh atë); fjalëkalimi, shpresojmë, shoqërohet me një kripë, dhe çdo një prej tyre ndodhet në kolonën e saj.
Le të zgjidhim menjëherë pyetjen më të thjeshtë: kurrë mos e ruani fjalëkalimin në tekst të thjeshtë! Kurrë. Një e vetme dobësi ndaj , një kopje e bërë papërgjegjshme ose një nga dhjetëra gabime të tjera të thjeshta — dhe gjithçka, game over, të gjitha fjalëkalimet tuaja — pra, më falni, të gjitha fjalëkalimet e klientëve tuaj do të bëhen prona publike. Natyrisht, kjo do të thotë një mundësi të madhe që do të bëhen publike 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ësitë e tij. Problemi i kriptimit është në deshifrimin; mund të merret ky kod me pamje të çmendur dhe të kthehet sërish në tekst të thjeshtë, dhe kur të ndodhë kjo, do të kthehemi në situatën me fjalëkalim të lexueshëm. Si ndodh kjo? Një defekt i vogël infiltruar në kodin që merret me deshifrimin e fjalëkalimit, duke e bërë atë publik - kjo është një mënyrë. Hakerat fitojnë akses në makinën që ruan të dhënat e kriptuara - kjo është një mënyrë e dytë. Një tjetër mënyrë është se përfitohet rezervë e bazës së të dhënave dhe dikush gjithashtu merr çelësin e kriptimit, i cili shpesh ruhet shumë në mënyrë të pasigurt.
Dhe kjo na çon te hashimi. Ideja e hashimit është se ai kryhet në një drejtim; mënyra e vetme për të krahasuar fjalëkalimin e futur nga përdoruesi me versionin e tij të hashuar është me hashimin e të dhënave të futur dhe krahasimi i tyre. Për të parandaluar sulmet me mjete si "tabela mëngjyrash", ne shtojmë rastësishmërinë në proces me anë të kripës (për një pasqyrë më të plotë, lexoni artikullin tim për ruajtjen kriptografike). Në fund të fundit, me një implementim të saktë, mund të besojmë me një nivel të lartë të sigurisë që fjalëkalimet e hashur do të mbeten kurrë në tekst të qartë (do të flas për avantazhet e algoritmeve të ndryshme të hashimit në një postim tjetër).
Një argument i shkurtër në lidhje me hashimin dhe enkriptimin: arsyeja e vetme pse ndonjëherë do t'ju duhet të enkriptoni dhe jo të hashoni një fjalëkalim është kur ju nevojitet të shihni fjalëkalimin në tekst të qartë, dhe kjo nuk duhet të jetë kurrë dëshira juaj, të paktën, në një situatë me një faqe interneti standarde. Nëse ju nevojitet kjo, ndoshta po bëni diçka gabim!
Kujdes!
Pak sa poshtë në tekstun e postës ka një pjesë të screenshot-it nga faqja pornografike AlotPorn. Ai është prerë me kujdes, dhe nuk ka asgjë që nuk mund të shihet në plazh, por nëse kjo mund të shkaktojë ndonjë problem, mos e rrokullisni faqen poshtë.
Gjithmonë resetoni fjalëkalimin, kurrë mos e kujtoni atë
A keni pasur ndonjëherë kërkesën për të krijuar një funksion kujtesë për fjalëkalimin? 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ë duam me të vërtetë të bëjmë? Të ndihmojmë atë të rifutë në sistem.
E kuptoj, fjala «kujtesë» përdoret (shpesh) në kuptim bisedor, por në të vërtetë ne po përpiqemi të ndihmojmë përdoruesin që të jetë sërish online në mënyrë të sigurt. Duke qenë se na nevojitet siguria, 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 të dërgonim asnjë informacion konfidencial përmes HTTP (do të përdornim HTTPS), nuk duhet të dërgojmë asgjë përmes emailit, pasi shtresa e tij e transportit është e pasigurt. Në të vërtetë, kjo është shumë më keq se thjesht dërgimi i informacionit përmes një protokolli transporti të pasigurt, pasi emaili shpesh ruhet në një pajisje, është i aksesueshëm për administratorët e sistemeve, përcillet dhe shpërndahet, është i ekspozuar ndaj malware dhe kështu me radhë. Emaili i pa encryptuar është një kanal jashtëzakonisht i pasigurt.
- Në çdo rast, nuk duhet të keni akses në fjalëkalimin. Rishikoni seksionin e mëparshëm rreth ruajtjes — duhet të keni një hash të fjalëkalimit (me një kripë të fortë), që do të thotë se ju nuk duhet të keni ndonjë mundësi për të nxjerrë fjalëkalimin dhe për ta dërguar atë përmes emailit.
Më lejoni të demonstroj problemin me një shembull : Këtu është një faqe tipike login:
Duket qartë, problemi i parë është se faqja e regjistrimit nuk ngarkohet përmes HTTPS, por faqja gjithashtu ofron dërgimin e fjalëkalimit («Send Password»). Ndoshta ky është një shembull i përdorimit të përmendur më sipër të këtij termi, prandaj le të bëjmë një hap tjetër dhe të shohim çfarë do ndodhë:
Duket se nuk është shumë më mirë, fatkeqësisht; dhe emaili konfirmon ekzistencën e problemit:
Kjo na tregon dy aspekte të rëndësishme të usoutdoor.com:
- Faqja nuk hashizon fjalëkalimet. Në mënyrën më të mirë, ato encryptohen, por, shumë shpesh, ato ruhen në formë tekstuale; nuk kemi dëshmi tjetër për të.
- Faqja dërgon një fjalëkalim afatgjatë (ne mund të kthehemi dhe ta përdorim atë përsëri e përsëri) përmes një kanali të pa mbrojtur.
Pas pasi që e kuptuam këtë, tani na nevojitet të kontrollojmë nëse procesi i rivendosjes po kryhet në një mënyrë të sigurt. E para që duhet të bëjmë është të sigurohemi se kërkuesi ka të drejtën për të kryer rivendosjen. Me fjalë të tjera, para kësaj na nevojitet një verifikim identiteti; le të shohim se çfarë ndodh kur identiteti konfirmohet pa një kontroll paraprak për të vërtetuar që kërkuesi është vërtet pronari i llogarisë.
Shqyrtimi i emrave të përdoruesve dhe ndikimi i tij në anonimatin
Kjo problematikë është më mirë të ilustrohet vizualisht. Problemi:
A e shihni? Vini re mesazhin «There is no user registered with this email address» («Përdoruesi me këtë adresë e-maili nuk është i regjistruar»). Problemi, duke qenë se është i qartë, shfaqet nëse një faqe e tillë konfirmon praninë e një përdoruesi të regjistruar me këtë adresë e-mail. Bingo — sapo gjete fetishin e pornos së burrit/shefit/fqinjit tuaj!
Natyrisht, pornografia është një shembull mjaft kanonik i rëndësisë së privatësisë, por rreziku i lidhjes së identitetit me një sit të caktuar është shumë më i gjerë se situata potencialisht e sikletshme e përshkruar më sipër. Një nga rreziqet është inxhinieria sociale; nëse një sulmues arrin të lidhet një person me një shërbim, ai do të ketë informacione që mund t'i përdorë më pas. Për shembull, mund të kontaktojë personin, duke pretenduar se është një përfaqësues i sitit dhe të kërkojë informacion shtesë, duke u përpjekur të kryejë .
Praktikat e ngjashme gjithashtu krijojnë rrezikun e "nxjerrjes së emrave të përdoruesve", ku mund të kontrollohet ekzistenca në një sit të tërë e një koleksioni emrash përdoruesish ose adresash elektronike përmes kërkesave grupore të thjeshta dhe shqyrtimit të përgjigjeve të tyre. A keni një listë adresash elektronike të të gjithë punonjësve dhe disa minuta për të shkruar një skript? Atëherë e kuptoni se ku është problemi!
Cila është alternativa? Në të vërtetë, ajo është mjaft e thjeshtë dhe është zbatuar në mënyrë të shkëlqyer në :
Këtu, Entropay nuk zbulohet në asnjë mënyrë mbi ekzistencën e një adrese emaili në sistemin e saj atyre që nuk e zotërojnë këtë adresë. Nëse ju e zotëroni këtë adresë dhe ajo nuk ekziston në sistem, atëherë do të merrni një email të tillë:
Sigurisht, ka situata të pranuara ku një person mendon, se është regjistruar në një faqe interneti, kur nuk është kështu, ose e ka bërë këtë nga një adresë tjetër emaili. Shembulli i mësipërm trajton me sukses të dy situatat. Sigurisht, nëse adresa përputhet, do të merrni një email që thjeshton rivendosjen e fjalëkalimit.
Natyra e zgjidhjes së zgjedhur nga Entropay është se verifikimi i identitetit bëhet përmes emailit para se çdo verifikimi online të ndodhë. Disa faqe kërkojnë nga përdoruesit përgjigjen në një pyetje sekrete (më shumë rreth kësaj më poshtë) deri te para se të fillojë rivendosja; megjithatë, problemi me këtë është se duhet të përgjigjet në pyetje ndërsa jep një lloj identifikimi (emaili ose emri i përdoruesit), duke e bërë pothuajse të pamundur të përgjigjesh intuitivisht pa zbuluar ekzistencën e një llogarie anonime.
Me këtë qasje ka i vogël në një rënie të lehtë të përdorshmërisë, sepse në rastin e një përpjekjeje për të rivendosur një llogari që nuk ekziston, nuk ka përgjigje të menjëhershme. Sigurisht, për këtë arsye dërgohet një email, por nga pikëpamja e përdoruesit të zakonshëm, nëse ai shkruan një adresë të gabuar, do ta mësojë këtë vetëm kur të marrë emailin. Kjo mund të shkaktojë tension nga ana e tij, por është një çmim i vogël për një proces kaq të rrallë.
Një vërejtje tjetër, paksa jashtë temës: 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ëjtën problematikë. 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 mos e konfirmoni në mënyrë të qartë 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 për rivendosje përballë dërgimit të URL-së për rivendosje
Koncepti tjetër që duhet të diskutojmë lidhet me mënyrën e rivendosjes së fjalëkalimit. Ekzistojnë dy zgjidhje të njohura:
- Generimi i një password të ri në server dhe dërgimi i tij me email
- Dërgimi i një email-i me një URL unik që thjeshton procesin e rikuperimit
Megjithatë , pika e parë nuk duhet kurrë të përdoret. Problemi i saj është se kjo nënkupton ekzistencën e një passwordi të ruajtur, i cili mund të rikthehet dhe të përdoret përsëri në çdo moment; ai është dërguar përmes një kanali të pasigurt dhe mbetet në hyrjet tuaja. Ka të ngjarë që hyrjet të sinkronizohen me pajisjet mobile dhe klientin e email-it, plus ato mund të ruajnë online në një shërbim email-i për një kohë shumë të gjatë. Nënkuptimi është se postalja nuk mund të konsiderohet si një mjet të besueshëm për ruajtjen afatgjatë.
Por përveç kësaj, pika e parë ka një problem të rëndësishëm tjetër — ajo maksimalisht thjeshton bllokimin e llogarisë me qëllim të keq. Nëse e di adresën e emailit të atij që e zotëron llogarinë në faqen e internetit, atëherë mund ta bllokoj atë në çdo moment duke i rivendosur fjalëkalimin; kjo është një sulm i tipit "refuzim i shërbimit", i servuar në një pjatë me skaj të kaltër! Kjo është arsyeja pse rivendosja duhet të kryhet vetëm pas verifikimit të suksesshëm të të drejtat e kërkuesit.
Kur flasim për URL-në e rivendosjes, nënkuptojmë adresën e faqes së internetit, e cila është unikale për këtë rast të veçantë të procesit të rivendosjes. Natyrisht, ajo duhet të jetë e rastësishme, nuk duhet të jetë e lehtë për t'u zbuluar dhe nuk duhet të përmbajë lidhje të jashtme për llogarinë, duke lehtësuar rivendosjen. Për shembull, URL-ja e rivendosjes nuk duhet të jetë thjesht një rrugë si "Reset/?username=JohnSmith".
Ne duam të krijojmë një token unik, i cili mund të dërgohet me email si një URL për rinovimin e fjalëkalimit, dhe më pas të verifikohet me regjistrimin në server me llogarinë e përdoruesit, duke konfirmuar kështu se pronari i llogarisë është vërtet personi që po përpiqet të rinovojë fjalëkalimin. Për shembull, tokeni mund të ketë formën «3ce7854015cd38c862cb9e14a1ae552b» dhe të ruhet në një tabelë së bashku me ID-në e përdoruesit që po bën rinovimin dhe kohën e krijimit të tokenit (më shumë rreth kësaj më poshtë). Kur dërgohet emaili, ai përmban një URL si «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», dhe kur përdoruesi e ngarkon atë, faqja kërkon ekzistencën e tokenit, pas së cilës konfirmon informacionin e përdoruesit dhe lejon ndërrimin e fjalëkalimit.
Sigurisht, pasi procesi i përshkruar më sipër (shpresojmë) i lejon përdoruesit të krijojë një fjalëkalim të ri, duhet garantuar ngarkimi i URL-së përmes HTTPS. Jo, , kjo URL me tokenin duhet të përdorë sigurinë e transportit të shtresës, që të përpjekja për të sulmuar formularin e futjes së fjalëkalimit të ri të jetë e pamundur dhe fjalëkalimi i krijuar nga përdoruesi u dërgua përmes një lidhjeje të sigurt.
Gjithashtu, për URL-në e rivendosjes është e nevojshme të shtohet një kufizim kohor për token, në mënyrë që procesi i rivendosjes të mund të realizohet brenda një intervali të caktuar, le të themi, brenda një ore. Kjo garanton që dritarja e kohës së rivendosjes të jetë minimale, në mënyrë që ai që ka marrë këtë URL rivendosjeje të mund të veprojë vetëm brenda kësaj dritareje shumë të vogël. Natyrisht, një sulmues mund të nisin përsëri procesin e rivendosjes, por do t'i nevojitet një URL rivendosjeje tjetër unik.
përfundimisht, na nevojitet të sigurojmë një herësinë e këtij procesi. Pas përfundimit të procesit të rivendosjes, token duhet të fshihet, në mënyrë që URL e rivendosjes të mos jetë më aktive. Pika e mëparshme është e nevojshme për të siguruar që sulmuesi të ketë një dritare shumë të vogël, gjatë së cilës mund të manipuloj me URL-në e rivendosjes. Po ashtu, pas përfundimit të suksesshëm të rivendosjes, token nuk ka nevojë më.
Disa nga këto hapa mund të duken të tepërt, por ato në të vërtetë nuk pengojnë përdorueshmërinë dhe në të vërtetë përmirëson sigurinë, ndonëse në situata që shpresojmë se do të jenë të rralla. Në 99% të rasteve, përdoruesi do të angazhohet në rikthimin e fjalëkalimeve brenda një periudhe shumë të shkurtër dhe nuk do të rikthejë fjalëkalimin përsëri në të ardhmen e afërt.
Roli i CAPTCHA
O, CAPTCHA, mjeti mbrojtës që të gjithë ne e duam ta urrejmë! Në të vërtetë, CAPTCHA është më shumë një mjet identifikimi — nëse jeni njeri apo robot (ose skript automatizuar). Qëllimi i saj është të parandalojë dërgimin automatik të formave, e cila, natyrisht, mund të përdoresh si një përpjekje për të thyer mbrojtjen. Në kontekstin e rikthimit të fjalëkalimeve, CAPTCHA do të thotë se funksioni i rikthimit nuk mund të thyhet me ndihmën e një sulmi me brute force, në mënyrë që të mos spamohet përdoruesi ose të provohet të përcaktohet ekzistenca e llogarive (e cila, natyrisht, do të jetë e pamundur, nëse keni ndjekur këshillat nga seksioni për verifikimin e identitetit).
Natyrisht, vetë CAPTCHA nuk është e përsosur; ka shumë precedente për "thyerjen" e saj programore dhe arritjen e treguesve të mjaftueshëm të suksesit (60-70%). Për më tepër, ekziston një zgjidhje, e paraqitur në postimin tim për , ku mund të paguani njerëz për të zgjidhur çdo CAPTCHA dhe të merrni një shkallë suksesi prej 94%. Kështu që, është e ndjeshme, por (pak) rrit barrierën e hyrjes.
Le të shohim një shembull të PayPal:
Në këtë rast, procesi i rivendosjes nuk mund të fillojë deri sa të zgjidhet CAPTCHA, kështu që teorikisht automatizimi i procesit është i pamundur. Teorikisht.
Megjithatë, për shumicën e aplikacioneve web, kjo do të ishte tepricë dhe në të vërtetë paraqet një ulje të përdorshmërisë — njerëzit thjesht nuk e pëlqejnë CAPTCHA! Për më tepër, CAPTCHA është një gjë që mund të ktheheni lehtë në rast nevoje. Nëse shërbimi fillon të sulmohet (këtu vjen në ndihmë regjistrimi, por më shumë për këtë më vonë), kurse të shtoni CAPTCHA është shumë e lehtë.
Pyetje dhe përgjigje sekrete
Nga të gjitha metodat që kemi shqyrtuar, ne patëm mundësinë të rivendosim fjalëkalimin duke pasur qasje vetëm në llogarinë e postës elektronike. Them "vetëm", por, sigurisht, marrja e paautorizuar e qasjes në llogarinë e dikujt tjetër duhet të jetë një proces i komplikuar. Megjithatë .
Në të vërtetë, lidhja e paraqitur më sipër për hackimin e llogarisë së Sarah Palin në Yahoo! shërben për dy qëllime; së pari, ilustron se sa lehtë mund të hackohen (disa) llogaritë e postës elektronike, së dyti, tregon se si mund të abuzohet për keq me pyetje të këqija sekrete. Por do të kthehemi te kjo më vonë.
Problemi me rikuperimin e fjalëkalimeve që varen gjithmonë nga posta elektronike është se integriteti i llogarisë në faqe, të cilën po përpiqeni ta rikuperoni, bëhet plotësisht i varur nga integriteti i llogarisë së postës elektronike. Çdo kush që ka akses në postën tuaj elektronike, ka akses në çdo llogari që mund të rikuperohet thjesht duke marrë një email. Për këto llogari, emaili është 'çelësi që hap të gjitha dyert' e jetës suaj online.
Një nga mënyrat për të reduktuar këtë rrezik është të implementoni një model të pyetjes dhe përgjigjes sekrete. Pa dyshim, e keni parë këtë: zgjidhni një pyetje, për të cilën vetëm ju duhet dinë përgjigjen, pas së cilës kur riktheni fjalëkalimin, ajo do t'ju kërkohet. Kjo rrit sigurinë që personi që përpiqet të bëjë rikthimin vërtet është pronari i llogarisë.
Le të kthehemi te Sara Palin: gabimi ishte që përgjigjet për pyetjen e saj sekrete ishin lehtësisht të gjetshme. Sidomos kur je një figurë publike e rëndësishme, informacionet për emrin e vajzërisë së nënës, historinë e arsimimit ose ku dikush mund të ketë jetuar në të kaluarën, nuk janë aq sekrete. Në të vërtetë, shumica e tyre mund të gjenden pothuajse nga kushdo. 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 më pas duke përdorur funksionin për rikuperimin e fjalëkalimeve të harruara për llogaritë Yahoo!.
Së pari, është një gabim projektimi nga ana e Yahoo! - duke vendosur pyetje kaq të thjeshta, kompania në thelb sabotoi vlerën e pyetjes sekrete, dhe kështu, mbrojtjen e sistemit të saj. Natyrisht, rikuperimi i fjalëkalimeve për llogarinë e postës elektronike është gjithmonë më i vështirë, pasi nuk mund të konfirmoni pronësinë e saj duke dërguar një email pronarit (pa pasur një adresë të dytë), por, fatmirësisht, sot ka shumë pak mënyra aplikimi për të krijuar një sistem të tillë.
Le të kthehemi te pyetjet sekrete - ekziston mundësia për të ofruar përdoruesit mundësinë për të krijuar pyetje të tyre. Problemi është se rezultati do të jenë pyetje të tmerrshme të dukshme:
Çfarë ngjyre është qielli?
Pyetje që i vënë njerëzit në një situatë të vështirë, kur për identifikimin, pyetja sekrete përdor njerëzin (për shembull, në një qendër thirjes):
Me kë kam fjetur për Krishtlindje?
Ose pyetje që janë hapur qartë budallaçe:
Si shkruhet "fjalëkalim"?
Kur bëhet fjalë për pyetjet sekrete, përdoruesit duhet t'i shpëtojmë vetvetes! Me fjalë të tjera, pyetja sekrete duhet të përcaktohet nga vetë vendi, dhe më mirë, të kërkojë një seri pyetjeve të fshehta, nga të cilat mund të zgjedhë përdoruesi. Dhe jo thjesht të zgjedhë një; idealisht, 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ë kanali dytësor identifikimi. Prania e disa pyetjeve rrit besueshmërinë e procesit të verifikimit, si dhe ofron mundësinë e shtimit të rastësisë (të mos tregohet gjithmonë e njëjta pyetje), plus siguron pak redundantë për rastin kur përdoruesi i vërtetë harrohet fjalëkalimi.
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 e pavendosur.
- Përgjigjja duhet të jetë e saktë — nuk na nevojitet një pyetje, të cilës një person mund t'i përgjigjet ndryshe
- Përgjigjet e mundshme duhet të jenë variabile — një pyetje për ngjyrën e preferuar të dikujt ofron një nëngrup shumë të vogël të mundshmerive të përgjigjeve
- Kërko përgjigjja duhet të jetë e vështirë — nëse përgjigjja mund të gjendet lehtësisht çdo kush (le të kujtojmë për njerëzit në pozita të larta), atëherë ajo është e keqe
- Përgjigjja duhet të jetë përherë në kohë — nëse pyesni për filmin e preferuar të dikujt, përgjigjja mund të jetë ndryshe pas një viti
Si ndodh zakonisht, ekziston një faqe interneti e dedikuar për pyetje të mira, e quajtur . Disa nga pyetjet duken mjaft të mira, të tjera nuk përmbushin disa nga testet e përmendura më sipër, veçanërisht provimin e «lehtësisë së kërkimit».
Më lejoni të demonstroj se si pyetjet sekrete zbatohen në PayPal dhe, në veçanti, përpjekjet që bën faqja për identifikim. Më sipër pamë faqen që fillon procesin (me CAPTCHA), dhe këtu do të tregojmë se çfarë ndodh pasi të keni futur adresën e emailit dhe të keni zgjidhur CAPTCHA-në:
Si rezultat, përdoruesi merr një email të tillë:
Derisa gjithçka duket mjaft normale, ja se çfarë fshihet pas këtij URL për rikuperimin:
Kështu, pyetjet sekrete hyjnë në lojë. Në të vërtetë, PayPal gjithashtu lejon rikuperimin e fjalëkalimit duke konfirmuar numrin e kartës së kreditit, kështu që ekziston një kanal shtesë, në të cilin shumë faqe nuk kanë qasje. Thjesht nuk mund ta ndryshoj fjalëkalimin pa u përgjigjur në të dyja pyetjet sekrete (ose pa e ditur numrin e kartës). Edhe nëse dikush merr kontrollin e emailit tim, ai nuk mund të rivendosë fjalëkalimin e llogarisë PayPal nëse nuk di pak më shumë informacion personal për mua. Cilat informata? Këtu janë opsionet për pyetjet sekrete që ofron PayPal:
Pyetja për shkollën dhe spitalin mund të duket paksa e dyshimtë sa i përket lehtësisë së gjetjes, por të tjerat nuk janë aq të këqija. Megjithatë, për të përmirësuar sigurinë, PayPal kërkon identifikim shtesë për në përgjigjet e pyetjeve sekrete:
PayPal është një shembull mjaft utopik i një procesi të sigurt për rivendosjen e fjalëkalimit: ai zbaton CAPTCHA për të ulur rrezikun e sulmeve me brute force, kërkon dy pyetje sekrete dhe pastaj kërkon një lloj tjetër identifikimi krejtësisht të ndryshëm vetëm për të ndryshuar përgjigjet — dhe kjo pas hyrjes së përdoruesit. Natyrisht, ky është pikërisht ciò që pritej nga PayPal; kjo është një organizatë financiare që punon me shuma të mëdha parash. Kjo nuk do të thotë se çdo rivendosje fjalëkalimi duhet të ndjekë këto hapa — në shumicën e rasteve, kjo është e tepruar — megjithatë, është një shembull i mirë për raste kur siguria është një biznes serioz.
Komoditeti i sistemit të pyetjeve sekrete është se, nëse nuk e keni zbatuar menjëherë, mund ta shtoni më vonë, nëse niveli i mbrojtjes së burimit e kërkon këtë. Një shembull i mirë është Apple, e cila vetëm së fundmi e ka zbatuar këtë mekanizëm. [artikulli është shkruar në vitin 2012]. Pasi fillova të përditësoj aplikacionin në iPad, pashë kërkesën e mëposhtme:
Më pas pashë një ekran ku mund të zgjedh disa palë pyetjesh sekrete dhe përgjigjesh, si dhe një adresë të shpëtimit në email:
Sa i përket PayPal, pyetjet janë zgjedhur paraprakisht dhe disa prej tyre janë mjaft të mira:
Çdo çift pyetjesh dhe përgjigjesh përfaqëson një grup të veçantë pyetjesh të mundshme, kështu që ka mjaft mundësi për konfigurimin e llogarisë.
Një aspekt tjetër që duhet konsideruar në lidhje me përgjigjen në pyetjen sekrete është ruajtja. Të pasesh një tekst të thjeshtë në DB paraqet pothuajse të njëjtat rreziqe si në rastin e një fjalëkalimi, në veçanti — ekspozimi i bazës së të dhënave zbulon menjëherë vlerën dhe i ekspozon në rrezik jo vetëm aplikacionin, por gjithashtu potencialisht aplikacione të tjera që përdorin të njëjtat pyetje sekrete (kjo përsëri ). Një nga opsionet është hashimi i sigurt (një algoritëm i fortë dhe kriptografikisht rastësor), megjithatë, ndryshe nga shumica e rasteve të ruajtjes së fjalëkalimeve, këtu mund të ketë një arsye të respektueshme për dukshmërinë e përgjigjes si tekst i thjeshtë. Një skenar tipik është verifikimi i identitetit nga një operator i gjallë përmes telefonit. Sigurisht, në këtë rast, hashimi është gjithashtu i aplikueshëm (operatori mund të thjesht të japë përgjigjen e përmendur nga klienti), por në rastin më të keq, përgjigja sekrete duhet të jetë në një nivel të ndonjë ruajtjeje kriptografike, ndonëse kjo mund të jetë vetëm enkriptim simetrik. Përfundimisht: trajtoni sekretet si sekrete!
Dhe aspekto i fundit i pyetjeve dhe përgjigjeve sekrete është se ato janë më të prekshme ndaj inxhinierisë sociale. Të përpiqesh të nxjerrësh drejtpërdrejt fjalëkalimin e një llogarie të huaj është një gjë, ndërsa të fillosh një bisedë për arsimimin e tij (një pyetje e zakonshme sekrete) është krejt tjetër. Në fakt, ju ndiheni mjaft rehat të flisni me dikë për shumë aspekte të jetës së tij, të cilat mund të përbëjnë pyetje sekrete, dhe të mos shkaktoni dyshime. Natyrisht, vetë thelbi i pyetjes sekrete është se ajo lidhet me përvojën e jetës së dikujt, prandaj ajo mbahet mend, e pikërisht në këtë qëndron problemi — njerëzit i pëlqen të flasin për përvojën e tyre të jetës! Me këtë ka pak mundësi të bësh diçka, vetëm nëse zgjidhni opsione të tilla të pyetjeve sekrete që të kenë më pak mundësi për t'u nxjerrë me anë të inxhinierisë sociale.
[Vazhdon...]
Si reklamë
VDSina ofron serverë të besueshëm , çdo server është i lidhur me një kanal interneti prej 500 Megabit dhe mbron falas nga sulmet DDoS!
Burimi: habr.com
