Autentifikimi i dyfishtë
Gjithçka që keni lexuar në ka të bëjë me identifikimin në bazë të asaj që dikush di. Ai e di adresën e tij të postës elektronike, di si të hyjë në të (dmth. e di fjalëkalimin e tij për postën elektronike) dhe di përgjigjet e pyetjeve sekrete.
«Dija» konsiderohet një faktor autentifikimi; dy faktorët e tjerë të zakonshëm janë ajo që keni, për shembull, një pajisje fizike, dhe ajo që jeni, për shembull, gishti i dorës ose irisi i syrit.
Në shumicën e rasteve, kryerja e identifikimit biologjik është e pamundur, veçanërisht kur flasim për sigurinë e aplikacioneve në internet, prandaj në autentifikimin me dy faktorë (two factor authentication, 2FA) zakonisht përdoret atributi i dytë — «ajo që keni». Një nga opsionet e njohura të këtij faktori të dytë është një token fizik, për shembull, :
Të dhënat fizike shpesh përdoren për autentifikim në VPN-të korporative dhe shërbimet financiare. Për autentifikimin në shërbim, duhet të përdorni si fjalëkalimin ashtu edhe kodin në token (i cili shpesh ndryshon) në kombinim me PIN-in. Teoretikisht, për identifikimin, një sulmues duhet të dijë fjalëkalimin, të ketë tokenin dhe gjithashtu të dijë PIN-in e tokenit. Në skenarin e rikthimit të fjalëkalimit, vetë fjalëkalimi, është e qartë, nuk dihet, megjithatë posedimi i tokenit mund të përdoret për të konfirmuar pronësinë e llogarisë. Sigurisht, ashtu si në çdo implementim mbrojtës, , por padyshim rrit barrierën për hyrjen.
Një nga problemet kryesore të këtij qasje është kostoja dhe logjistika e zbatimit; po flasim për transferimin e pajisjeve fizike te çdo klient dhe për të mësuar ata me procesin e ri. Për më tepër, përdoruesit duhet të kenë një pajisje me vete, gjë që në rastin e një tokeni fizik nuk është gjithmonë e mundur. Një tjetër mundësi është të implementohet verifikimi i dyfishtë përmes SMS, i cili në rastin e 2FA mund të funksionojë si konfirmim se personi që kryen procesin e rikthimit ka telefonin mobil të pronarit të llogarisë. Kështu e bën Google:
Po ashtu është e nevojshme të përfshihet , por kjo do të thotë se kur të bëni rikthimin e ardhshëm të fjalëkalimit, telefoni juaj mobil mund të bëhet faktor i dytë i verifikimit. Më lejoni ta demonstroj këtë në shembullin tim të iPhone për shkak të arsyeve që do të bëhen të qarta së shpejti:
Pas identifikimit të adresës së postës elektronike të llogarisë Google, përcaktohet se 2FA është aktivizuar dhe ne mund të rikthejmë llogarinë përmes verifikimit, i cili dërgohet përmes SMS në telefonin mobil të pronarit të llogarisë:
Tani na nevojitet të zgjedhim fillimin e procesit të rikthimit:
Ky veprim sjell dërgimin e një emaili në adresën e regjistruar:
Ky email përmban URL-në e rikuperimit:
Kur qaseni në URL-në e rikuperimit, një SMS dërgohet dhe faqja kërcënon të kërkojë kodin:
Ja ky SMS:
Pas futjes së tij në shfletues, kthehemi në procesin klasik të rikuperimit të fjalëkalimit:
Mund të duket pak e tepërt, dhe në të vërtetë është, por forma konfirmon se personi që po rikuperon ka akses në adresën e emailit dhe numrin e telefonit të llogaridhënësit. Por kjo mund të jetë deri në nëntë herë më e sigurt se rikuperimi i fjalëkalimit vetëm përmes emailit. Megjithatë, ka disa probleme...
Problemi ka të bëjë me smartfonët. Pajisja e treguar më poshtë mund të verifikojë vetëm një faktor autentikimi - ajo mund të marrë SMS, por jo email:
Megjithatë, kjo pajisje mund të marrë SMS dhe të marrë email për rikuperimin e fjalëkalimit:
Problemi është se ne e shohim emailin si faktor të parë të autentifikimit, dhe SMS (apo edhe një aplikacion që gjeneron kode) si të dytë, por sot ato janë të bashkuara në një pajisje. Natyrisht, kjo do të thotë se nëse dikush arrin të hyjë në smartfonin tuaj, atëherë të gjitha këto lehtësi do të kthehen në një kanal; ky faktor i dytë "çfarë keni" do të thotë gjithashtu se ju e keni edhe faktorin e parë. Dhe gjithçka është e mbrojtur nga një PIN prej katër shifrash... nëse telefoni ka ndonjëherë një PIN. dhe ai është bllokuar.
Po, funksioni 2FA i realizuar nga Google sigurisht që ofron mbrojtje shtesë, por ai nuk është i mbrojtur "nga budallai", dhe me siguri nuk varet nga dy kanale të plota dhe autonom.
Rivendosja me emër të përdoruesit përballë rivendosjes me adresë emaili.
A duhet të lejohet rivendosja vetëm me adresë emaili? Apo përdoruesi duhet të ketë mundësinë të kryejë rivendosje dhe përmes emrit? Problemi me rivendosjen me emër përdoruesi është se nuk ka asnjë mënyrë për të njoftuar përdoruesin për emrin e gabuar të përdoruesit, pa zbuluar se dikush tjetër mund të ketë një llogari me këtë emër. Në seksionin e mëparshëm, riciklimi përmes emailit garantonte që pronari legjitim i këtij emaili do të merrte gjithmonë përgjigje pa e zbuluar publikisht ekzistencën e tij në sistem. Me ndihmën e vetëm emrit të përdoruesit, kjo nuk është e mundur.
Prandaj, përgjigjja është e shkurtër: vetëm emaili. Nëse përpiqeni të kryeni riciklimin vetëm me emrin e përdoruesit, do të kenë ndodhur raste kur përdoruesi do të mbetet në konfuzion se çfarë ka ndodhur. ose do të zbulojnë ekzistencën e llogarive. Po, është vetëm emri i përdoruesit, jo adresa e emailit dhe po, çdo person mund të zgjedhë ndonjë emër përdoruesi (të disponueshëm), por përsëri ekziston një mundësi e madhe që do të zbulojnë indirekt pronarët e llogarive për shkak të prirjes së përdoruesve për të përdorur përsëritëshem emrin.
Cili është procesi, kur dikush harron emrin e përdoruesit? Nëse supozojmë se emri i përdoruesit nuk është menjëherë adresa e-mail (dhe kjo ndodh shpesh), procesi është siç fillon një riaktive e fjalëkalimit — ne shkruajmë adresën e emailit dhe më pas dërgojmë një mesazh në atë adresë, pa zbuluar ekzistencën e saj. Ndryshimi i vetem është se kësaj here mesazhi përmban vetëm emrin e përdoruesit, dhe jo URL-në e riaktivizimit të fjalëkalimit. Ose do të ketë një mesazh në email që tregon se nuk ekziston një llogari për këtë adresë.
Verifikimi i identitetit dhe saktësia e adresave të e-mailit
Një aspekt kyç i riaktiveve të fjalëkalimeve, dhe madje ndoshta aspekti më i rëndësishëm është verifikimi i identitetit të personit që përpiqet të bëjë riaktivizimin. A është vërtet pronari legjitim i llogarisë, apo dikush po përpiqet ta thyejë atë ose t'i shkaktojë probleme pronarit?
Evident se se-maili është kanali më i përshtatshëm dhe më i përhapur për verifikimin e identitetit. Ai nuk është i mbrojtur nga keqpërdorimi i paqartë ("nga budallai"), dhe ekziston një numër i madh rastesh kur thjesht mundësia për të marrënë emaile në adresën e pronarit të llogarisë nuk është e mjaftueshme, nëse kërkohet një siguri më e lartë për identifikim (prandaj përdoret 2FA), megjithatë pothuajse gjithmonë është pika fillestare e procesit të rikuperimit.
Nëse emaili do të luajë një rol në sigurimin e besueshmërisë, atëherë e para që duhet të bëni është të siguroheni që adresa e emailit të jetë vërtet e saktë. Nëse dikush gabon një simbol, është e qartë se rikuperimi nuk do të fillojë. Procesi i verifikimit të emailit në momentin e regjistrimit është një mënyrë e besueshme për të verifikuar saktësinë e adresës. Të gjithë e kemi parë këtë në praktikë: regjistroheni, ju dërgohet një email me një URL unik, në të cilin duhet të klikoni, i cili konfirmon se ju jeni me të vërtetë pronari i këtij llogarie emaili. Pamundësia për të hyrë në sistem deri sa të përfundojë ky proces siguron një motivim për të konfirmuar adresën.
Si në rastin e shumë aspekteve të tjera të sigurisë, një model i tillë ul përdorshmërinë në këmbim të ofrimit të një niveli të shtuar sigurie në lidhje me identitetin e përdoruesit. Kjo mund të jetë e pranueshme për një faqe që përdoruesi e vlerëson shumë dhe do të ishte i gatshëm të shtonte një hap tjetër në proces (shërbime me pagesë, bankari, etj.), por gjëra të tilla mund ta ndalin përdoruesin nëse e percepton llogarinë si 'të përkohshme' dhe e përdor, për shembull, thjesht si një mjet për të komentuar një postim.
Identifikimi i atij që iniciuan procesin e rikthimit
Mund të ketë sigurisht arsye për përdorim të keq të funksionit të rikthimit, dhe keqbërësit mund ta përdorin atë në shumë mënyra të ndryshme. Një truk i thjeshtë që mund të përdorim për të ndihmuar në konfirmimin e burimit të kërkesës (ky truk zakonisht funksionon) — është të shtojmë në emailin me ofertën për rikthim IP-në e adresës që kërkon. Kjo i ofron marrësit disa informacione për identifikimin e burimit të kërkesës.
Ja një shembull nga funksioni i rikthimit që po integroj tani në ASafaWeb:
Linku «find out more» («Mëso më shumë») e çon përdoruesin në faqen , e cila raporton informacion si vendndodhjen dhe organizatën e kërkuesit për rikuperim:
Natyrisht, çdo kush që do të fshehë identitetin e tij ka shumë mënyra për të mashtuar IP-në e tij të vërtetë, megjithatë kjo është një mënyrë e lehtë për të shtuar një identifikim të pjesshëm të kërkuesit, dhe në shumicën të rasteve kjo do t'ju japë një ide të mjaftueshme se kush do të kryejë kërkesën për rikuperimin e fjalëkalimit.
Njoftimi për ndryshime nëpërmjet postës elektronike
Ky post është i mbushur me një temë — komunikimi; informoni pronarin e llogarisë sa më shumë për atë që ndodh në çdo hap të procesit, pa zbuluar ndonjë gjë që mund të përdoret për qëllime të këqija. E njëjta gjë vlen edhe për situaten kur fjalëkalimi në të vërtetë është ndryshuar — informoni pronarin!
Arsyet për ndryshimin e fjalëkalimit mund të jenë dy burime:
- Ndryshimi i fjalëkalimit pas hyrjes në sistem, sepse përdoruesi dëshiron një fjalëkalim të ri
- Rikuperimi i fjalëkalimit pa hyrje në sistem, sepse përdoruesi e ka harruar atë
Megjithëse ky post është në tërësi i fokusuar te rikthimi i fjalëkalimit, njoftimi në rastin e parë zvogëlon rrezikun që dikush të ndryshojë fjalëkalimin pa dijeninë e pronarit të ligjshëm. Si mund të ndodhë kjo? Një skenar mjaft i zakonshëm është marrja e fjalëkalimit të pronarit të ligjshëm (një fjalëkalim i ribërë nga një burim tjetër; një fjalëkalim i marrë përmes keylogging; një fjalëkalim i lehtë për t'u gjetur, etj.), pas së cilës sulmuesi vendos ta ndryshojë atë, kështu që duke e bllokuar pronarin. Pa një njoftim me email, pronari aktual nuk do të dijë për ndryshimin e fjalëkalimit.
Sigurisht, në rastin e rikthimit të fjalëkalimit, pronari tashmë duhet ta ketë iniciuar procesin vetë (ose të ketë anashkaluar mjetet e verifikimit të identitetit të përmendura më sipër), kështu që ndërrimi nuk duhet mund të jetë një surprizë për të, megjithatë konfirmimi me email do të jetë një reagim pozitiv dhe një kontroll shtesë. Për më tepër, kjo siguron njësi me skenarin e përshkruar më lart.
O, dhe për rastin nëse kjo nuk është ende e qartë — mos e dërgoni një fjalëkalim të ri përmes postës! Dikush mund të qeshë për këtë, por :
Logë, logë, logë dhe pak më shumë logë
Funksioni i rivendosjes së fjalëkalimit është tërheqës për sulmuesit: një sulmues dëshiron të ketë qasje në llogarinë e një personi tjetër ose thjesht të shkaktojë shqetësim për pronarin e llogarisë/sistemit. Shumë nga praktikat e përmendura më sipër lejojnë reduktimin e mundësive për abuzim, por nuk parandalojnë ato dhe me siguri nuk do të ndalin njerëzit nga përpjekja për të përdorur funksionin në mënyrë të papërshtatshme.
Për të njohur sjelljen keqdashëse, një praktikë e çmuar është regjistrimi, dhe kam në mendje regjistrimin shumë të detajuar. Regjistroni përpjekjet e dështuara për të hyrë në sistem, rivendosjet e fjalëkalimeve, ndryshimin e fjalëkalimeve (dmth. kur përdoruesi është tashmë i lidhur) dhe praktikisht gjithçka që mund të ndihmojë në kuptimin e asaj që po ndodh; kjo do t'ju ndihmojë shumë në të ardhmen. Regjistroni në log të paktën pjesë procesit, për shembull, një funksion i mirë riaktivizimi duhet të përfshijë iniciimin e riaktivizimit përmes faqes së internetit (regjistroni kërkesat dhe përpjekjet e kyçjes për riaktivizimin me emrin e përdoruesit ose emailin e gabuar), regjistroni vizitën në faqen e internetit për URL-në e riaktivizimit (duke përfshirë përpjekjet për të përdorur një token të pavlefshëm), dhe më pas regjistroni në log suksesin ose dështimin e përgjigjes ndaj pyetjes sekrete.
Kur flas për regjistrimin, kam parasysh jo vetëm regjistrimin e faktit të ngarkesës së faqes, por edhe mbledhjen e sa më shumë informacioni, nëse nuk është konfidencial. Djem, ju lutem, mos e regjistroni fjalëkalimin në log! Në log duhet të regjistrohet identiteti i përdoruesit të autorizuar (ai do të jetë i autorizuar nëse ai ndryshon fjalëkalimin ekzistues ose përpiqet të riaktivizojë fjalëkalimin e të tjerëve pas kyçjes në sistem), çfarëdo emrash përdoruesish ose adresash emaili që ai provon plus çdo token riaktivizimi që ai përpiqet të përdorë. Por gjithashtu ia vlen të regjistrohen në log aspekte të tilla si adresat IP dhe, nëse është e mundur, madje edhe titujt e kërkesave. Kjo ju lejon të rivendosni jo vetëm çfarë përdoruesi (ose sulmuesi) përpiqet të bëjë, por edhe kush ai është i tillë.
Delegimi i përgjegjësisë te ekzekutorë të tjerë
Nëse mendoni se të gjitha këto paraqesin një volum të madh pune, nuk jeni të vetmuar. Në të vërtetë, ndërtimi i një sistemi të besueshëm për menaxhimin e llogarive është një detyrë e vështirë. Problemi nuk është se është shumë teknik, thjesht ka shumë nuanca. Nuk përfshin vetëm rivendosjen e fjalëkalimeve, ekziston një proces i plotë regjistrimi, ruajtja e sigurt e fjalëkalimeve, përpunimi i përpjekjeve të shumta të gabuara për të hyrë në sistem etj., etj. , përveç saj, duhet bërë shumë më tepër.
Sot ekzistojnë shumë ofrues të jashtëm, të cilët me kënaqësi marrin përsipër të gjitha mundimet dhe hipotetizojnë të gjitha këto në një shërbim të menaxhuar. Mes këtyre shërbimeve janë OpenID, OAuth dhe madje edhe Facebook. Disa njerëz (OpenID në të vërtetë ka qenë shumë i suksesshëm në Stack Overflow), megjithatë të tjerë .
Pa dyshim, një shërbim si OpenID zgjidh shumë probleme për zhvilluesit, por gjithashtu, pa dyshim, shton të reja. A kanë ata ndonjë rol? Po, por është evidente se nuk po shohim një përdorim masiv të shërbimeve të ofruesve të autentifikimit. Bankat, linjat ajrore dhe madje edhe dyqanet — të gjitha realizojnë mekanizma të tyre të autentifikimit, dhe është e qartë se ka arsye shumë të forta për këtë.
Rivendosja e keqe
Një aspekt i rëndësishëm i çdo një nga shembujt e mësipërm është se fjalëkalimi i vjetër konsiderohet i padobishëm vetëm pas konfirmimit të identitetit të pronarit të llogarisë. Kjo është e rëndësishme, sepse po të ishte e mundur të rivendosej llogaria deri te pa verifikimin e identifikimit, do të jepte mundësi për veprime të ndryshme të keqia.
Ja një shembull: dikush merr pjesë në ankande në një faqe ankandi, dhe afër fundit të procesit të ankandeve ai bllokon konkurrentët, duke iniciuar procesin e rivendosjes, duke eliminuar kështu ata nga ankandi. Sigurisht, nëse një funksion rivendosjeje i dizajnuar keq mund të keqpërdoret, kjo mund të çojë në rezultate serioze negative. Duhet të vëreni se bllokimi i llogarive përmes përpjekjeve të gabuara për t'u kyçur është një situatë e ngjashme, por kjo është një temë për një postim tjetër.
Siç e përmenda më sipër, nëse u jepet përdoruesve anonim mundësia për të rivendosur fjalëkalimin e çdo llogarije, thjesht duke e ditur adresën e saj të postës elektronike, atëherë kjo është një situatë ideale për një sulm të tipit "refuzim shërbimi". Kjo mund të mos jetë ajo , me të cilën jemi mësuar të flasim, por nuk ka mënyrë më të shpejtë për të bllokuar aksesin në një llogari sesa me një funksion rivendosjeje fjalëkalimi të menduar keq.
Pika më e dobët
Nga pikëpamja e mbrojtjes së një llogarie, gjithçka e shkruajtur më sipër është e shkëlqyer, megjithatë duhet gjithmonë të mbani mend ekosistemin që rrethon llogarinë që po e mbrojmë. Le të japim një shembull:
ASafaWeb është hostuar në një shërbim fantastik të ofruar nga AppHarbor. Procesi i rikthimit të llogarisë së hostimit zhvillohet si në vijim:
Hapi 1:
Hapi 2:
Hapi 3:
Hapi 4:
Pas leximit të gjithë informacionit të mëparshëm, është e lehtë të kuptohet se cilat aspekte do t’i realizonim ndryshe në një botë të përkryer. megjithatë, këtu dua të them se nëse publikohem një site si ASafaWeb në shërbimin AppHarbor, dhe pastaj shpik disa pyetje dhe përgjigje sekrete të shkëlqyera, shtoj një faktor të dytë të autentikimit dhe bëj gjithçka sipas rregullave, kjo nuk e anashkalon faktin se pika më e dobët e të gjithë procesit do të jetë në gjendje ta prishë atë. Nëse dikush arrin të autentikohet në AppHarbor duke përdorur informacionin tim, ai do të mund të ndryshojë fjalëkalimin për çdo llogari ASafaWeb në mënyrën që dëshiron!
Kuptimi është se qëndrueshmëria e implementimit të mbrojtjes duhet të shqyrtohet në mënyrë holistike: duhet të modelojmë kërcënimet për çdo pikë hyrjeje të sistemit, edhe nëse është një proces i sipërfaqshëm, siç është hyrja në sistemin AppHarbor. Kjo duhet të më japë një ide të mirë se sa përpjekje duhet të investoj në procesin e rikthimit të fjalëkalimit ASafaWeb.
Lidhim gjithçka së bashku
Ky post përmban një sasi të madhe informacioni, prandaj dua ta përmbledh në një diagramë vizuale të thjeshtë:
Mos harroni se duhet të bëni loggimin sa më të detajuar të secilit nga këto pika. Kjo është gjithçka, është e thjeshtë!
Përfundimet
Posti im duket gjithëpërfshirës, megjithatë ekzistojnë shumë materiale shtesë që mund të i përfshija në të, por vendosa të heq dorë nga kjo për shkak të shkurtësisë: roli i adresës së emailit të ndihmës, situata kur humbni qasje në emailin e lidhur me llogarinë (p.sh., kur e lëni punën), dhe shumë të tjera. Siç thashë më parë, funksioni i rinovimit nuk është kaq i komplikuar, thjesht ka shumë këndvështrime mbi të.
Edhe pse rinovimi nuk është kaq i vështirë, shpesh implementohet gabimisht. Më lart ne pamë disa shembuj kur implementimi mund ka sjellë probleme, dhe ka shumë më tepër raste kur një rinovim i gabuar vërtet ka shkaktuar probleme. Së fundmi u zbulua se Ky është një rezultat shumë negativ!
Prandaj, jini të kujdesshëm me funksionet tuaja të rinovimit, në pika të ndryshme, dhe gjatë projektimit të funksioneve mos hiqni kapelen tuaj të zezë, sepse ka një mundësi të madhe që dikush tjetër ta vendosë atë!
Si reklamë
VDSina ofron servera të lirë me pagesë ditore, çdo server i lidhur me një lidhje interneti prej 500 Megabit dhe i mbrojtur falas nga sulmet DDoS!
Burimi: habr.com
