Kohët e fundit pata kohë të mendoj përsëri se si duhet të funksionojë një veçori e sigurt e rivendosjes së fjalëkalimit, fillimisht kur po ndërtoja këtë funksionalitet , dhe më pas kur ai ndihmoi një person tjetër të bënte diçka të ngjashme. Në rastin e dytë, doja t'i jepja atij një lidhje me një burim kanonik me të gjitha detajet se si të zbatohet në mënyrë të sigurt funksioni i rivendosjes. Megjithatë, problemi është se një burim i tillë nuk ekziston, të paktën jo një që përshkruan gjithçka që më duket e rëndësishme. Kështu që vendosa ta shkruaj vetë.
E shihni, bota e fjalëkalimeve të harruara është në të vërtetë mjaft misterioze. Ka shumë këndvështrime të ndryshme, krejtësisht të pranueshme dhe shumë mjaft të rrezikshme. Shanset janë që ju ta keni hasur secilin prej tyre shumë herë si përdorues fundor; kështu që unë do të përpiqem t'i përdor këta shembuj për të treguar se kush po e bën siç duhet, kush jo dhe në çfarë duhet të përqendroheni për ta futur funksionin siç duhet në aplikacionin tuaj.
Ruajtja e fjalëkalimit: hash, enkriptim dhe tekst i thjeshtë
Ne nuk mund të diskutojmë se çfarë të bëjmë me fjalëkalimet e harruara përpara se të diskutojmë se si t'i ruajmë ato. Fjalëkalimet ruhen në bazën e të dhënave në një nga tre llojet kryesore:
- Tekst i thjeshtë. Ekziston një kolonë fjalëkalimi, e cila ruhet në formë teksti të thjeshtë.
- E koduar. Në mënyrë tipike duke përdorur kriptim simetrik (një çelës përdoret si për enkriptim ashtu edhe për deshifrim), dhe fjalëkalimet e enkriptuara ruhen gjithashtu në të njëjtën kolonë.
- Hashed. Procesi i njëanshëm (fjalëkalimi mund të hashohet, por nuk mund të hiqet); fjalëkalimi, Unë do të doja të shpresoja, e ndjekur nga një kripë, dhe secila është në kolonën e vet.
Le të kalojmë drejtpërdrejt te pyetja më e thjeshtë: Asnjëherë mos i ruani fjalëkalimet në tekst të thjeshtë! kurrë. Një cenueshmëri e vetme ndaj , një kopje rezervë e pakujdesshme, ose një nga dhjetëra gabime të tjera të thjeshta - dhe kaq, gameover, të gjitha fjalëkalimet tuaja - domethënë, më falni, fjalëkalimet e të gjithë klientëve tuaj do të bëhet domen publik. Sigurisht, kjo do të nënkuptonte një gjasë të madhe që nga të gjitha llogaritë e tyre në sisteme të tjera. Dhe do të jetë faji juaj.
Kriptimi është më i mirë, por ka dobësitë e veta. Problemi me enkriptimin është deshifrimi; ne mund t'i marrim këto shifra me pamje të çmendur dhe t'i kthejmë ato në tekst të thjeshtë, dhe kur kjo të ndodhë, ne kthehemi në situatën e fjalëkalimit të lexueshëm nga njeriu. Si ndodh kjo? Një e metë e vogël futet në kodin që deshifron fjalëkalimin, duke e bërë atë të disponueshëm publikisht - kjo është një mënyrë. Hakerët fitojnë akses në makinën në të cilën ruhen të dhënat e koduara - kjo është metoda e dytë. Një mënyrë tjetër, përsëri, është të vjedhësh kopje rezervë të bazës së të dhënave dhe dikush gjithashtu merr çelësin e enkriptimit, i cili shpesh ruhet në mënyrë shumë të pasigurt.
Dhe kjo na çon në hash. Ideja pas hashimit është se është njëkahëshe; mënyra e vetme për të krahasuar fjalëkalimin e futur nga përdoruesi me versionin e tij të hashuar është të hash të dhëna dhe t'i krahasosh ato. Për të parandaluar sulmet nga mjete si tabelat e ylberit, ne e kriposim procesin në mënyrë të rastësishme (lexo timin në lidhje me ruajtjen kriptografike). Në fund të fundit, nëse zbatohet si duhet, mund të jemi të sigurt se fjalëkalimet e hashuara nuk do të bëhen më kurrë tekst i thjeshtë (do të flas për përfitimet e algoritmeve të ndryshme të hashimit në një postim tjetër).
Një argument i shpejtë në lidhje me hashimin kundrejt kriptimit: e vetmja arsye që do t'ju duhet të kriptoni në vend që të hash një fjalëkalim është kur ju duhet ta shihni fjalëkalimin në tekst të thjeshtë, dhe ju kurrë nuk duhet ta dëshironi këtë, të paktën në një situatë standarde të internetit. Nëse keni nevojë për këtë, atëherë ka shumë të ngjarë që po bëni diçka të gabuar!
Kujdes!
Më poshtë në tekstin e postimit ka një pjesë të një fotografie të faqes pornografike AlotPorn. Është shkurtuar mjeshtërisht, kështu që nuk ka asgjë që nuk mund të shihni në plazh, por nëse ende ka gjasa të shkaktojë ndonjë problem, mos lëvizni poshtë.
Rivendosni gjithmonë fjalëkalimin tuaj kurrë mos ia kujto atij
A ju është kërkuar ndonjëherë të krijoni një funksion përkujtues fjalëkalimin? Bëni një hap prapa dhe mendoni për këtë kërkesë në të kundërt: pse është i nevojshëm ky "kujtues"? Sepse përdoruesi ka harruar fjalëkalimin. Çfarë duam të bëjmë vërtet? Ndihmojeni të identifikohet përsëri.
E kuptoj që fjala "kujtues" përdoret (shpesh) në një kuptim bisedor, por ajo që ne me të vërtetë po përpiqemi të bëjmë është ndihmoni në mënyrë të sigurt përdoruesin të jetë përsëri në linjë. Meqenëse kemi nevojë për siguri, ka dy arsye pse një kujtesë (d.m.th. dërgimi i fjalëkalimit të përdoruesit) nuk është i përshtatshëm:
- Email-i është një kanal i pasigurt. Ashtu siç nuk do të dërgonim asgjë të ndjeshme mbi HTTP (do të përdornim HTTPS), nuk duhet të dërgojmë asgjë të ndjeshme përmes emailit sepse shtresa e tij e transportit është e pasigurt. Në fakt, kjo është shumë më keq sesa thjesht dërgimi i informacionit përmes një protokolli të pasigurt transporti, sepse posta shpesh ruhet në një pajisje ruajtëse, e aksesueshme për administratorët e sistemit, e përcjellë dhe e shpërndarë, e aksesueshme për malware, etj. Email-i i pakriptuar është një kanal jashtëzakonisht i pasigurt.
- Gjithsesi nuk duhet të kesh akses te fjalëkalimi. Rilexoni seksionin e mëparshëm për ruajtjen - duhet të keni një hash të fjalëkalimit (me një kripë të mirë të fortë), që do të thotë se nuk duhet të jeni në gjendje në asnjë mënyrë të nxirrni fjalëkalimin dhe ta dërgoni atë me postë.
Më lejoni ta demonstroj problemin me një shembull : Këtu është një faqe tipike identifikimi:
Natyrisht, problemi i parë është se faqja e hyrjes nuk ngarkohet në HTTPS, por faqja ju kërkon gjithashtu të dërgoni një fjalëkalim ("Dërgo fjalëkalimin"). Ky mund të jetë një shembull i përdorimit kolokial të termit të përmendur më lart, kështu që le ta bëjmë një hap më tej dhe të shohim se çfarë ndodh:
Nuk duket shumë më mirë, për fat të keq; dhe një email konfirmon se ka një problem:
Kjo na tregon dy aspekte të rëndësishme të usoutdoor.com:
- Faqja nuk hash fjalëkalimet. Në rastin më të mirë, ato janë të koduara, por ka të ngjarë që ato të ruhen në tekst të thjeshtë; Nuk shohim asnjë provë për të kundërtën.
- Sajti 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.
Me këtë jashtë rrugës, ne duhet të kontrollojmë nëse procesi i rivendosjes është bërë në një mënyrë të sigurt. Hapi i parë për ta bërë këtë është të siguroheni që kërkuesi ka të drejtë të kryejë rivendosjen. Me fjalë të tjera, para kësaj na duhet një kontroll identiteti; le të hedhim një vështrim se çfarë ndodh kur një identitet verifikohet pa verifikuar më parë se kërkuesi është në të vërtetë pronari i llogarisë.
Listimi i emrave të përdoruesve dhe ndikimi i tij në anonimitetin
Ky problem ilustrohet më së miri vizualisht. Problemi:
A e shikon? Kushtojini vëmendje mesazhit "Nuk ka asnjë përdorues të regjistruar me këtë adresë emaili". Problemi padyshim lind nëse një faqe e tillë konfirmon наличие përdorues i regjistruar me një adresë të tillë emaili. Bingo - sapo keni zbuluar fetishin pornografik të burrit/shefit/komshiut tuaj!
Sigurisht, pornografia është një shembull mjaft ikonik i rëndësisë së privatësisë, por rreziqet e shoqërimit të një individi me një faqe interneti specifike janë shumë më të gjera sesa situata potencialisht e vështirë e përshkruar më sipër. Një rrezik është inxhinieria sociale; Nëse sulmuesi mund të përputhet me një person me shërbimin, atëherë ai do të ketë informacion që mund të fillojë të përdorë. Për shembull, ai mund të kontaktojë një person që paraqitet si përfaqësues i një faqe interneti dhe të kërkojë informacion shtesë në një përpjekje për të kryer .
Praktika të tilla ngrenë gjithashtu rrezikun e "regjistrimit të emrave të përdoruesit", ku mund të verifikohet ekzistenca e një koleksioni të tërë të emrave të përdoruesve ose adresave të postës elektronike në një faqe interneti thjesht duke kryer pyetje në grup dhe duke shqyrtuar përgjigjet ndaj tyre. A keni një listë të adresave të emailit të të gjithë punonjësve dhe disa minuta për të shkruar një skenar? Atëherë e shihni se cili është problemi!
Cila është alternativa? Në fakt, është mjaft e thjeshtë dhe zbatohet mrekullisht në :
Këtu Entropay nuk zbulon absolutisht asgjë në lidhje me ekzistencën e një adrese emaili në sistemin e tij për dikë që nuk e zotëron këtë adresë. nëse ti vet kjo adresë dhe nuk ekziston në sistem, atëherë do të merrni një email si ky:
Sigurisht, mund të ketë situata të pranueshme në të cilat dikush mendonqë keni regjistruar në faqen e internetit. por nuk është kështu, ose e bëra nga një adresë tjetër e-mail. Shembulli i treguar më sipër i trajton mirë të dyja situatat. Natyrisht, nëse adresa përputhet, do të merrni një email duke e bërë më të lehtë rivendosjen e fjalëkalimit tuaj.
E veçanta e zgjidhjes së zgjedhur nga Entropay është se verifikimi i identifikimit kryhet sipas e-mail përpara çdo verifikimi online. Disa sajte u kërkojnë përdoruesve përgjigjen e një pyetjeje sigurie (më shumë për këtë më poshtë) tek si mund të fillojë rivendosja; megjithatë, problemi me këtë është se ju duhet t'i përgjigjeni pyetjes duke ofruar një formë identifikimi (email ose emër përdoruesi), gjë që më pas e bën pothuajse të pamundur përgjigjen intuitive pa zbuluar ekzistencën e llogarisë së përdoruesit anonim.
Me këtë qasje ekziston i vogël ulet përdorshmëria sepse nëse përpiqeni të rivendosni një llogari që nuk ekziston, nuk ka reagim të menjëhershëm. Sigurisht, kjo është e gjithë çështja e dërgimit të një emaili, por nga këndvështrimi i një përdoruesi të vërtetë fundor, nëse futin adresën e gabuar, ata do ta dinë vetëm për herë të parë kur e marrin emailin. Kjo mund të shkaktojë tension nga ana e tij, por ky është një çmim i vogël për të paguar për një proces kaq të rrallë.
Një tjetër shënim, paksa jashtë temës: funksionet e ndihmës për hyrjen që zbulojnë nëse emri i përdoruesit ose adresa e emailit është e saktë kanë të njëjtin problem. Gjithmonë përgjigjuni përdoruesit me një mesazh "Kombimi i emrit të përdoruesit dhe fjalëkalimit është i pavlefshëm" në vend që të konfirmoni në mënyrë eksplicite ekzistencën e kredencialeve (për shembull, "emri i përdoruesit është i saktë, por fjalëkalimi është i pasaktë").
Dërgimi i rivendosjes së fjalëkalimit kundrejt dërgimit të URL-së së rivendosur
Koncepti tjetër që duhet të diskutojmë është se si të rivendosni fjalëkalimin tuaj. Ekzistojnë dy zgjidhje të njohura:
- Gjenerimi i një fjalëkalimi të ri në server dhe dërgimi i tij me email
- Dërgoni një email me një URL unike për ta bërë më të lehtë procesin e rivendosjes
Përkundër , pika e parë nuk duhet përdorur kurrë. Problemi me këtë është se do të thotë se ka fjalëkalimin e ruajtur, në të cilin mund të ktheheni dhe ta përdorni përsëri në çdo kohë; është dërguar përmes një kanali të pasigurt dhe mbetet në kutinë tuaj hyrëse. Shanset janë që kutitë hyrëse të sinkronizohen nëpër pajisjet celulare dhe klientin e postës elektronike, plus ato mund të ruhen në internet në shërbimin e postës elektronike në internet për një kohë shumë të gjatë. Çështja është se një kuti postare nuk mund të konsiderohet si një mjet i besueshëm i ruajtjes afatgjatë.
Por përveç kësaj, pika e parë ka një problem tjetër serioz - atë thjeshton sa më shumë që të jetë e mundur bllokimi i një llogarie me qëllim të keq. Nëse e di adresën e emailit të dikujt që zotëron një llogari në një faqe interneti, atëherë mund ta bllokoj atë në çdo kohë thjesht duke rivendosur fjalëkalimin e tij; Ky është një sulm mohimi i shërbimit i shërbyer në një pjatë argjendi! Kjo është arsyeja pse rivendosja duhet të kryhet vetëm pas verifikimit të suksesshëm të të drejtave të kërkuesit për të.
Kur flasim për një URL të rivendosur, nënkuptojmë adresën e një faqe interneti që është unike për këtë rast të veçantë të procesit të rivendosjes. Sigurisht, duhet të jetë i rastësishëm, nuk duhet të jetë i lehtë për t'u hamendësuar dhe nuk duhet të përmbajë lidhje të jashtme me llogarinë që e bëjnë më të lehtë rivendosjen. Për shembull, URL-ja e rivendosjes nuk duhet të jetë thjesht një shteg si "Rivendos/?username=JohnSmith".
Ne duam të krijojmë një shenjë unike që mund të dërgohet me postë si një URL e rivendosur, dhe më pas të përputhet me të dhënat e serverit të llogarisë së përdoruesit, duke konfirmuar kështu që pronari i llogarisë është, në fakt, i njëjti person që po përpiqet të rivendosë fjalëkalimin. Për shembull, një token mund të jetë "3ce7854015cd38c862cb9e14a1ae552b" dhe të ruhet në një tabelë së bashku me ID-në e përdoruesit që kryen rivendosjen dhe kohën e gjenerimit të tokenit (më shumë për këtë më poshtë). Kur emaili dërgohet, ai përmban një URL si "Reset/?id=3ce7854015cd38c862cb9e14a1ae552b", dhe kur përdoruesi e shkarkon atë, faqja kërkon ekzistencën e tokenit, pas së cilës konfirmon informacionin e përdoruesit dhe i lejon ata të ndryshojnë fjalëkalimin.
Natyrisht, meqenëse procesi i mësipërm (shpresojmë) i lejon përdoruesit të krijojë një fjalëkalim të ri, ne duhet të sigurohemi që URL-ja të jetë e ngarkuar në HTTPS. Jo, , kjo URL e shenjës duhet të përdorë sigurinë e shtresës së transportit në mënyrë që formulari i ri i fjalëkalimit të mos sulmohet dhe fjalëkalimi i krijuar nga përdoruesi u transmetua përmes një lidhjeje të sigurt.
Gjithashtu për URL-në e rivendosjes duhet të shtoni një kufi kohor të shenjës në mënyrë që procesi i rivendosjes të mund të përfundojë brenda një intervali të caktuar, le të themi brenda një ore. Kjo siguron që dritarja e kohës së rivendosjes të mbahet në minimum, në mënyrë që marrësi i URL-së së rivendosur të mund të veprojë vetëm brenda asaj dritareje shumë të vogël. Natyrisht, sulmuesi mund të fillojë përsëri procesin e rivendosjes, por ata do të duhet të marrin një URL tjetër unike të rivendosjes.
Së fundi, ne duhet të sigurohemi që ky proces të jetë i disponueshëm. Pasi të përfundojë procesi i rivendosjes, token duhet të hiqet në mënyrë që URL-ja e rivendosjes të mos jetë më funksionale. 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 ai mund të manipulojë URL-në e rivendosjes. Plus, sigurisht, pasi rivendosja të jetë e suksesshme, shenja nuk është më e nevojshme.
Disa nga këto hapa mund të duken tepër të tepërt, por ato nuk ndërhyjnë në përdorshmërinë dhe në fakt të përmirësojë sigurinë, megjithëse në situata që shpresojmë se do të jenë të rralla. Në 99% të rasteve, përdoruesi do të mundësojë rivendosjen brenda një periudhe shumë të shkurtër kohore dhe nuk do ta rivendosë më fjalëkalimin në të ardhmen e afërt.
Roli i CAPTCHA
Oh, CAPTCHA, veçoria e sigurisë që të gjithëve na pëlqen ta urrejmë! Në fakt, CAPTCHA nuk është aq një mjet mbrojtjeje sa është një mjet identifikimi - nëse jeni person apo robot (ose një skenar i automatizuar). Qëllimi i tij është të shmangë dorëzimin automatik të formularit, i cili, natyrisht, mund të përdoret si një përpjekje për të thyer sigurinë. Në kontekstin e rivendosjes së fjalëkalimit, CAPTCHA do të thotë që funksioni i rivendosjes nuk mund të detyrohet ose të dërgojë mesazhe të padëshiruara për përdoruesit ose të përpiqet të përcaktojë ekzistencën e llogarive (gjë që, natyrisht, nuk do të jetë e mundur nëse ndiqni këshillat në seksionin mbi verifikimin e identiteteve).
Sigurisht, vetë CAPTCHA nuk është perfekt; Ka shumë precedentë për "hakimin" e softuerit të tij dhe arritjen e niveleve të mjaftueshme të suksesit (60-70%). Për më tepër, ekziston një zgjidhje e treguar në postimin tim rreth , ku mund t'i paguani njerëzve fraksione të një centi për të zgjidhur çdo CAPTCHA dhe për të arritur një shkallë suksesi prej 94%. Kjo do të thotë, është e pambrojtur, por (pak) ngre pengesën e hyrjes.
Le të hedhim një vështrim në shembullin e PayPal:
Në këtë rast, procesi i rivendosjes thjesht nuk mund të fillojë derisa të zgjidhet CAPTCHA, kështu që teorikisht është e pamundur të automatizosh procesin. Në teori.
Megjithatë, për shumicën e aplikacioneve në internet kjo do të jetë e tepërt dhe absolutisht e drejtë përfaqëson një ulje të përdorshmërisë - njerëzve thjesht nuk u pëlqen CAPTCHA! Përveç kësaj, CAPTCHA është diçka që mund t'i riktheheni lehtësisht nëse është e nevojshme. Nëse shërbimi fillon të sulmohet (ky është vendi ku regjistrimi është i dobishëm, por më shumë për këtë më vonë), atëherë shtimi i një CAPTCHA nuk mund të jetë më i lehtë.
Pyetje dhe përgjigje sekrete
Me të gjitha metodat që kemi shqyrtuar, ne ishim në gjendje të rivendosnim fjalëkalimin vetëm duke pasur akses në llogarinë e emailit. Unë them "vetëm", por, natyrisht, është e paligjshme të fitosh akses në llogarinë e emailit të dikujt tjetër. duhet të jetë një proces kompleks. Megjithatë .
Në fakt, lidhja e mësipërme për hakimin e Yahoo-së së Sarah Palin! shërben për dy qëllime; së pari, ilustron se sa e lehtë është të hakosh (disa) llogari të postës elektronike, dhe së dyti, tregon se si pyetjet e këqija të sigurisë mund të përdoren me qëllime keqdashëse. Por ne do t'i kthehemi kësaj më vonë.
Problemi me rivendosjen XNUMX% të fjalëkalimit të bazuar në email është se integriteti i llogarisë për faqen që po përpiqeni të rivendosni bëhet XNUMX% i varur nga integriteti i llogarisë së emailit. Kushdo që ka qasje në emailin tuaj ka qasje në çdo llogari që mund të rivendoset thjesht duke marrë një email. Për llogari të tilla, emaili është "çelësi për të gjitha dyert" e jetës tuaj në internet.
Një mënyrë për të reduktuar këtë rrezik është zbatimi i një modeli pyetjesh dhe përgjigjesh të sigurisë. Pa dyshim që i keni parë tashmë: zgjidhni një pyetje që vetëm ju mund t'i përgjigjeni kam dijeni përgjigjen dhe më pas kur të rivendosni fjalëkalimin tuaj do t'ju kërkohet. Kjo shton besimin se personi që përpiqet të rivendosë është me të vërtetë pronari i llogarisë.
Kthehu te Sarah Palin: gabimi ishte se përgjigjet për pyetjet/pyetjet e saj të sigurisë mund të gjendeshin lehtësisht. Veçanërisht kur jeni një personazh kaq i rëndësishëm publik, informacioni për mbiemrin e vajzërisë së nënës suaj, historinë e arsimit ose se ku dikush mund të ketë jetuar në të kaluarën nuk është dhe aq sekret. Në fakt, shumica e tij mund të gjendet nga pothuajse kushdo. Ja çfarë i ndodhi Sarës:
Hakeri David Kernell fitoi akses në llogarinë e Palin duke gjetur detaje rreth prejardhjes së saj, si universiteti dhe data e lindjes, dhe më pas duke përdorur funksionin e rikuperimit të fjalëkalimit të harruar të Yahoo!.
Para së gjithash, ky është një gabim dizajnimi nga ana e Yahoo! — Duke specifikuar pyetje kaq të thjeshta, kompania në thelb sabotoi vlerën e pyetjes së sigurisë, dhe rrjedhimisht mbrojtjen e sistemit të saj. Sigurisht, rivendosja e fjalëkalimeve për një llogari emaili është gjithmonë më e vështirë pasi nuk mund ta vërtetosh pronësinë duke i dërguar një email pronarit (pa pasur një adresë të dytë), por për fat të mirë nuk ka shumë përdorime për krijimin e një sistemi të tillë sot.
Le të kthehemi te pyetjet e sigurisë - ekziston një mundësi për të lejuar përdoruesin të krijojë pyetjet e veta. Problemi është se kjo do të rezultojë në pyetje tmerrësisht të qarta:
Çfarë ngjyre ka qielli?
Pyetje që i bëjnë njerëzit të ndihen rehat kur një pyetje sigurie përdoret për të identifikuar человек (për shembull, në një qendër thirrjesh):
Me kë kam fjetur në Krishtlindje?
Ose pyetje sinqerisht budallaqe:
Si e shqiptoni "fjalëkalimin"?
Kur bëhet fjalë për pyetjet e sigurisë, përdoruesit duhet të ruhen nga vetja! Me fjalë të tjera, pyetja e sigurisë duhet të përcaktohet nga vetë faqja, ose më mirë akoma, të bëhet seri pyetjet e sigurisë nga të cilat përdoruesi mund të zgjedhë. Dhe nuk është e lehtë të zgjedhësh një; Në mënyrë ideale, përdoruesi duhet të zgjedhë dy ose më shumë pyetje sigurie në momentin e regjistrimit të llogarisë, i cili më pas do të përdoret si kanal i dytë identifikimi. Të kesh pyetje të shumta rrit besimin në procesin e verifikimit, dhe gjithashtu ofron mundësinë për të shtuar rastësi (jo gjithmonë duke treguar të njëjtën pyetje), plus ofron pak tepricë në rast se përdoruesi aktual ka harruar fjalëkalimin.
Cila është një pyetje e mirë sigurie? Kjo ndikohet nga disa faktorë:
- Ajo duhet të jetë i shkurtër — pyetja duhet të jetë e qartë dhe e paqartë.
- Përgjigja duhet të jetë specifike - Nuk kemi nevojë për një pyetje që një person mund t'i përgjigjet ndryshe
- Përgjigjet e mundshme duhet të jenë të ndryshme - pyetja për ngjyrën e preferuar të dikujt jep një nëngrup shumë të vogël përgjigjesh të mundshme
- Kërko përgjigja duhet të jetë komplekse - nëse përgjigja mund të gjendet lehtësisht ndonjë (kujtoni njerëzit në pozita të larta), atëherë ai është i keq
- Përgjigja duhet të jetë i përhershëm në kohë - nëse pyetni filmin e preferuar të dikujt, atëherë një vit më vonë përgjigjja mund të jetë e ndryshme
Siç ndodh, ekziston një faqe interneti e dedikuar për të bërë pyetje të mira . Disa nga pyetjet duken mjaft të mira, të tjerat nuk i kalojnë disa nga testet e përshkruara më sipër, veçanërisht testin e "lehtësisë së kërkimit".
Më lejoni të demonstroj se si PayPal zbaton pyetjet e sigurisë dhe, në veçanti, përpjekjen që bën faqja për vërtetimin. Më sipër pamë faqen për të filluar procesin (me një CAPTCHA), dhe këtu do të tregojmë se çfarë ndodh pasi të futni adresën tuaj të emailit dhe të zgjidhni CAPTCHA:
Si rezultat, përdoruesi merr letrën e mëposhtme:
Deri më tani gjithçka është mjaft normale, por ja çfarë fshihet pas kësaj URL-je të rivendosur:
Pra, pyetjet e sigurisë hyjnë në lojë. Në fakt, PayPal ju lejon gjithashtu të rivendosni fjalëkalimin tuaj duke verifikuar numrin e kartës suaj të kreditit, kështu që ekziston një kanal shtesë në të cilin shumë sajte nuk kanë qasje. Unë thjesht nuk mund ta ndryshoj fjalëkalimin tim pa u përgjigjur të dy pyetje sigurie (ose mosnjohje e numrit të kartës). Edhe nëse dikush rrëmbeu emailin tim, nuk do të ishte në gjendje të rivendoste fjalëkalimin e llogarisë time PayPal nëse nuk dinte pak më shumë informacion personal për mua. Çfarë informacioni? Këtu janë opsionet e pyetjeve të sigurisë që ofron PayPal:
Pyetja e shkollës dhe e spitalit mund të jetë pak e ngathët për sa i përket lehtësisë së kërkimit, por të tjerat nuk janë shumë të këqija. Megjithatë, për të rritur sigurinë, PayPal kërkon identifikim shtesë për Ndryshimet përgjigje për pyetjet e sigurisë:
PayPal është një shembull mjaft utopik i rivendosjes së sigurt të fjalëkalimit: ai zbaton një CAPTCHA për të zvogëluar rrezikun e sulmeve me forcë brutale, kërkon dy pyetje sigurie dhe më pas kërkon një lloj tjetër identifikimi krejtësisht të ndryshëm vetëm për të ndryshuar përgjigjet - dhe kjo pasi përdoruesi tashmë është regjistruar. Sigurisht, kjo është pikërisht ajo që ne pritet nga PayPal; është një institucion financiar që merret me shuma të mëdha parash. Kjo nuk do të thotë që çdo rivendosje e fjalëkalimit duhet të ndjekë këto hapa—shumicën e kohës është e tepruar—por është një shembull i mirë për rastet kur siguria është punë serioze.
Komoditeti i sistemit të pyetjeve të sigurisë është që nëse nuk e keni zbatuar menjëherë, mund ta shtoni më vonë nëse niveli i mbrojtjes së burimeve e kërkon. Një shembull i mirë i kësaj është Apple, e cila vetëm kohët e fundit e zbatoi këtë mekanizëm [artikulli i shkruar në 2012]. Sapo fillova përditësimin e aplikacionit në iPad tim, pashë kërkesën e mëposhtme:
Pastaj pashë një ekran ku mund të zgjidhja disa palë pyetje dhe përgjigje sigurie, si dhe një adresë emaili shpëtimi:
Sa i përket PayPal-it, pyetjet janë të parazgjedhura dhe disa prej tyre në fakt janë mjaft të mira:
Secila prej tre çifteve pyetje/përgjigje përfaqëson një grup të ndryshëm pyetjesh të mundshme, kështu që ka shumë mënyra për të konfiguruar një llogari.
Një aspekt tjetër për t'u marrë parasysh në lidhje me përgjigjen e pyetjes suaj të sigurisë është ruajtja. Të kesh një bazë të dhënash me tekst të thjeshtë në bazën e të dhënave paraqet pothuajse të njëjtat kërcënime si një fjalëkalim, domethënë se ekspozimi i bazës së të dhënave zbulon në çast vlerën dhe vë në rrezik jo vetëm aplikacionin, por aplikacione potencialisht krejtësisht të ndryshme që përdorin të njëjtat pyetje sigurie (aty përsëri ). Një opsion është hashimi i sigurt (një algoritëm i fortë dhe një kripë e rastësishme kriptografike), por ndryshe nga shumica e rasteve të ruajtjes së fjalëkalimeve, mund të ketë një arsye të mirë që përgjigja të jetë e dukshme si tekst i thjeshtë. Një skenar tipik është verifikimi i identitetit nga një operator telefonik i drejtpërdrejtë. Natyrisht, hashimi është gjithashtu i zbatueshëm në këtë rast (operatori thjesht mund të fusë përgjigjen e emërtuar nga klienti), por në rastin më të keq, përgjigja sekrete duhet të jetë e vendosur në një nivel të ruajtjes kriptografike, edhe nëse është thjesht kriptim simetrik. . Përmblidhni: trajtoji sekretet si sekrete!
Një aspekt i fundit i pyetjeve dhe përgjigjeve të sigurisë është se ato janë më të prekshme ndaj inxhinierisë sociale. Përpjekja për të nxjerrë drejtpërdrejt fjalëkalimin në llogarinë e dikujt tjetër është një gjë, por fillimi i një bisede për formimin e tij (një pyetje popullore sigurie) është krejtësisht ndryshe. Në fakt, ju mund të komunikoni shumë mirë me dikë për shumë aspekte të jetës së tyre që mund të paraqesin një pyetje sekrete pa ngjallur dyshime. Sigurisht, thelbi i një pyetjeje sigurie është se ajo lidhet me përvojën e jetës së dikujt, kështu që është e paharrueshme, dhe këtu qëndron problemi - njerëzve u pëlqen të flasin për përvojat e tyre të jetës! Ju mund të bëni pak për këtë, vetëm nëse zgjidhni opsione të tilla të pyetjeve të sigurisë në mënyrë që ato të jenë më pak ndoshta mund të tërhiqej nga inxhinieria sociale.
[Vazhdon.]Për të Drejtat e Reklamimit
VDSina ofron të besueshme , çdo server është i lidhur me një kanal interneti prej 500 Megabitësh dhe mbrohet nga sulmet DDoS falas!
Burimi: www.habr.com