Autentikimi me dy faktorë
Çdo gjë që keni lexuar në ka të bëjë me identifikimin në bazë të asaj që dijeni kërkuesi. Ai e di adresën e tij të emailit, di se si të qaccessojë atë (pra, di fjalëkalimin e tij të emailit) dhe di përgjigjet për pyetjet sekrete.
«Dija» konsiderohet si një faktor autentikimi; 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, printet e gishtërinjve ose irisit të syve.
Në shumicën e rasteve, realizimi i identifikimit biologjik është shumë i vështirë, veçanërisht kur flasim për sigurinë e aplikacioneve të internetit, prandaj në autentikimin me dy faktorë (two factor authentication, 2FA) zakonisht përdoret atributi i dytë — «ajo që keni». Një nga mundësitë e njohura të këtij faktori të dytë është tokeni fizik, për shembull, :
Tokenët fizikë përdoren shpesh për autentikimin në VPN-të korporative dhe shërbimet financiare. Për autentikimin në shërbim, njerëzit duhet të përdorin si fjalëkalimin ashtu edhe kodin në token (i cili shpesh ndryshon) së bashku me PIN-in. Teoretikisht, për identifikimin e sulmuesit, ai duhet të dijë fjalëkalimin, të ketë tokenin, si dhe të dijë PIN-in e tokenit. Në skenarin e rikthimit të fjalëkalimit, fjalëkalimi vetë sigurisht që nuk është i njohur, megjithatë, posedimi i tokenit mund të përdoret për të konfirmuar pronësinë e llogarisë. Natyrisht, siç ndodh me çdo implementim të mbrojtjes, , por padyshim rrit barrierën e hyrjes.
Një nga problemet kryesore të këtij qasjeje është kostoja dhe logjistika e implementimit; po flasim për shpërndarjen e pajisjeve fizike për çdo klient dhe për trajnimin e tyre në procesin e ri. Për më tepër, përdoruesit duhet të kenë pajisjen me vete, gjë që në rastin e tokenit fizik nuk ndodh gjithmonë. Një tjetër mundësi është të realizohet faktori i dytë i autentikimit përmes SMS-it, i cili në rastin e 2FA mund të shërbejë si konfirmim se personi që po përfiton procesin e rikthimit ka telefonin mobil të pronarit të llogarisë. Ja si e bën Google:
Gjithashtu është e nevojshme të aktivizohet , porosie se kjo do të thotë se gjatë rikthimit të ardhshëm të fjalëkalimit, telefoni juaj mobil mund të bëhet faktori i dytë i autentifikimit. Lejoni të ilustroj këtë me shembujnë e iPhone tim për arsye që do të bëhen të qarta së shpejti:
Pas identifikimit të adresës së emailit të llogarisë Google, përcaktohet se është aktivizuar 2FA dhe ne mund ta rikthejmë llogarinë me verifikimin që dërgohet përmes SMS në telefonin mobil të pronarit të llogarisë:
Tani na nevojitet të zgjedhim fillimin e procesit të rikthimit:
Ky veprim çon në dërgimin e një emaili në adresën e regjistruar:
Ky email përmban URL-në e rikthimit:
Kur merret akses në URL-në e rikthimit, një SMS dërgohet dhe faqja e internetit kërkon ta fusni atë:
Ja ky SMS:
Pas futjes së tij në shfletues, ne kthehemi në territorin e rikthimit klasik të fjalëkalimit:
Ndoshta kjo duket pak e gjatë, dhe ka të drejtë, por forma konfirmon se ai që bën rikthimin ka akses në adresën e emailit dhe telefonin mobil të pronarit të llogarisë. Por kjo mund të jetë në nëntë herë më e sigurt se rikthimi i fjalëkalimit vetëm përmes emailit. Sidoqoftë, ekzistojnë probleme...
Problemi lidhet me smartfonët. Pajisja e treguar më poshtë mund të verifikojë vetëm një faktor autentifikimi - ajo është në gjendje të marrë SMS, por jo email:
Megjithatë, kjo pajisje mund të marrë SMS dhe të marrë email për rikthimin e fjalëkalimit:
Problemi është se ne e shqyrtojmë emailin si faktor të parë të autentifikimit, dhe SMS (ose madje aplikacionin që gjeneron tokene) 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, e gjithë kjo lehtësi do të reduktohej në një kanal; ky faktor i dytë ‘ajo që keni’ do të thotë se keni edhe faktorin e parë. Dhe e gjithë kjo mbrohet me një PIN prej katër numrash... nëse telefoni ka ndonjëherë një PIN dhe ai ishte bllokuar.
Po, funksioni 2FA i implementuar nga Google sigurisht që ofron mbrojtje të shtuar, por ai nuk është i mbrojtur ‘nga budallallëku’, dhe sigurisht që nuk mbështetet në dy kanale krejtësisht autonome.
Rikthimi mbi emrin e përdoruesit përballë rikthimit mbi adresën e emailit
A duhet lejuar rikthimi vetëm përmes adresës elektronike? Apo përdoruesi duhet të ketë mundësinë të bëjë rikthimin edhe përmes emrit? Problemi me rikthimin përmes emrit të përdoruesit ë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, rikthimi përmes emailit garantonte që pronari legjitim i kësaj adrese elektroni të merrte gjithmonë informacion pa zbuluar publikisht ekzistencën e tij në sistem. Me vetëm emrin e përdoruesit, kjo është e pamundur.
Prandaj, përgjigja është e qartë: vetëm përmes emailit. Nëse provoni të bëni rikthimin vetëm me emrin e përdoruesit, do të ketë raste kur përdoruesi do të pyesë se çfarë ka ndodhur, ose ju do të zbuloni ekzistencën e llogarive. Po, është vetëm një emër përdoruesi, e jo një adresë emaili dhe po, çdo person mund të zgjedhë një emër përdoruesi (të disponueshëm), por gjithsesi ka një probabilitet të madh që do të zbuloni pronarët e llogarive për shkak të tendencës së përdoruesve për të ricikluar emrin.
Pra, çfarë ndodh kur dikush harron emrin e tij të përdoruesit? Nëse supozoni se emri i përdoruesit nuk është menjëherë një adresë emaili (dhe kjo ndodh shpesh), procesi është i ngjashëm me se si fillon rikthimi i fjalëkalimit - shkruajmë adresën e emailit, pastaj dërgojmë një mesazh në atë adresë, pa zbuluar ekzistencën e saj. Diferenca e vetme është se këtë herë mesazhi përmban vetëm emrin e përdoruesit, dhe jo URL-në e rikthimit të fjalëkalimit. Ose, ose në email do të thuhet se nuk ka llogari për këtë adresë.
Verifikimi i identitetit dhe saktësia e adresave të emailit
Një aspekt kyç i rikthimit të fjalëkalimeve, dhe, ndoshta, aspekti më kyç është verifikimi i identitetit të personit që përpiqet të bëjë rikthimin. A është vërtet pronari legjitim i llogarisë, apo dikush po përpiqet ta thyejë atë ose t'i shkaktojë shqetësime pronarit?
Është evidente se ajo që është e-maili është kanali më i njohur dhe më i përdorur për verifikimin e identitetit. Ai nuk është i mbrojtur nga përdorimi i keq («nga budallai»), dhe ekzistojnë shumë raste kur thjesht mundësia për të pranuar mesazhe në adresën e pronarit të llogarisë nuk është e mjaftueshme, kur kërkohet një nivel i lartë besueshmërie në identifikim (për këtë arsye përdoret 2FA), megjithatë, pothuajse gjithmonë është pika fillestare e procesit të rivendosjes.
Nëse e-maili do të luajë një rol në sigurimin e besueshmërisë, atëherë hapi i parë është të sigurohemi se adresa e e-mailit është në të vërtetë e saktë. Nëse dikush ka gabuar një simbol, qartë, rivendosja nuk do të fillojë. Procesi i verifikimit të e-mailit në momentin e regjistrimit është një mënyrë e besueshme për të kontrolluar saktësinë e adresës. Të gjithë e kemi parë këtë në praktikë: regjistroheni, ju dërgohet një e-mail me një URL unik, mbi të cilin duhet të klikoni, që konfirmon se ju jeni me të vërtetë pronari i kësaj llogarie e-maili. Pamundësia për të hyrë në sistem përpara se të përfundojë ky proces garanton motivimin për të konfirmuar adresën.
Ashtu si në shumë aspekte të tjera të sigurisë, një model i tillë zvogëlon lehtësinë e përdorimit në këmbim të sigurisë më të lartë në lidhje me besueshmërinë e identitetit të përdoruesit. Kjo mund të jetë e pranueshme për një uebfaqe që përdoruesi e vlerëson shumë dhe me kënaqësi do të shtonte një hap tjetër në proces (shërbime të paguara, banking, etj.), por gjëra të tilla mund të tundojnë përdoruesin nëse e percepton llogarinë si "njëherësh" dhe e përdor vetëm si një mjet për të komentuar një postim.
Identifikimi i atij që e nisi procesin e rivendosjes
Është evidente se ka arsye për përdorimin e keq të funksionit të rivendosjes, dhe hakerat 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ë shtimi i IP-adresës kërkuese në e-mailin me ofertën për rivendosje. Kjo i jep marrësit disa informacione për identifikimin e burimit të kërkesës.
Ja një shembull nga funksioni i rivendosjes që unë po e integroj tani në ASafaWeb:
Link ‘find out more’ ('Mëso më shumë') redirects the user to the site , informing about details such as location and organization of the requesting reset:
Of course, anyone wanting to conceal their identity has numerous ways to obfuscate their real IP address, but this provides a convenient means of adding partial identification of the requester, and in most cases it will give you a sufficient insight into who is executing the password reset request. Email change notification
This post is imbued with one theme — communication; inform the account owner as much as possible about what is happening at each stage of the process, without revealing anything that could be used maliciously. The same applies to the situation where the password has indeed changed —
inform the owner about it! The reasons for changing the password may stem from two sources:
Password change after logging in because the user wants a new password
- Password reset without logging in because the user forgot it
- Although this post primarily addresses resets, notification in the first case reduces the risk of someone changing the password without the lawful owner's knowledge. How can this happen? A common scenario is when the legitimate owner's password is obtained (a reused password, leaked from another source; a password obtained through keylogging; an easily guessable password, etc.), after which the attacker decides to change it, thereby blocking the owner. Without email notification, the rightful owner will be unaware of the password change.
Certainly, in the case of a password reset, the owner should have already initiated the process themselves (or circumvented the above-described identity verification means), so the change
should not come as a surprise to them, but confirmation via email would provide positive feedback and an additional verification. Moreover, it ensures consistency with the aforementioned scenario. Oh, and in case this is not already obvious —
do not send the new password by email! Some might find this amusing, but such things happen :
Log, log, log dhe pak më shumë log
Funcioni e rikthimit të fjalëkalimit është erësishme për sulmuesit: ata duan të hyjnë në llogarinë e dikujt tjetër, ose thjesht të shkaktojnë shqetësime për pronarin e llogarisë/sistemit. Shumica e praktikave të përmendura më sipër lejojnë të zvogëlohet probabiliteti i abuzimeve, por nuk e parandalojnë atë, dhe ato me siguri nuk do të ndalojnë njerëzit të provojnë të përdorin funksionin në mënyrë të paautorizuar.
Për të njohur sjelljet e dëmshme, një praktikë e çmuar është logimi, dhe unë flas për logimin shumë të detajuar.Regjistroni përpjekjet e dështuara për të hyrë në sistem, rikthimet e fjalëkalimeve, ndryshimet e fjalëkalimeve (dmth. kur përdoruesi tashmë është i hyrë) dhe praktikisht gjithçka që mund të ndihmojë në kuptimin e asaj që ka ndodhur; kjo do të jetë shumë e dobishme në të ardhmen. Regjistroni madje edhe pjesët e procesit, për shembull, një funksion i mirë rikthimi duhet të përfshijë iniciimin e rikthimit përmes uebfaqes (regjistroni kërkesën dhe përpjekjet e hyrjes për rikthim me emra përdoruesi ose adresa elektronike të gabuara), regjistroni vizitën në uebfaqe për URL-në e rikthimit (përfshirë përpjekjet për të përdorur një token të gabuar), dhe pastaj regjistroni suksesin ose dështimin e përgjigjes ndaj pyetjes sekrete. Kur flas për logimin, unë nuk përfshij vetëm regjistrimin e faktit të ngarkimit të faqes, por edhe grumbullimin e sa më shumë informacioni të mundshëm,
nëse nuk është konfidencial. Djem,ju lutem, mos regjistroni fjalëkalimet në loge! Në loge 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ë rikthejë fjalëkalimin e dikujt tjetër pas hyrjes në sistem), çdo emër përdoruesi ose adresë elektronike që ai përpiqet të përdorë, plus çdo token rikthimi që ai përpiqet të përdorë. Por gjithashtu ia vlen të regjistrohen në loge aspekte të tilla si adresat IP dhe, nëse është e mundur, madje edhe titujt e kërkesave. Kjo ju lejon të rikrijoni jo vetëm çfarë përdoruesi (ose sulmuesi) përpiqet të bëjë, por gjithashtu nuk shkon, dhe gjithashtu ka një ide për atë që ndodh në shërbimet përreth, për të kuptuar, ai është i tillë. kush Delegimi i përgjegjësive te ekzekutues të tjerë.
Delegimi i përgjegjësive te ekzekutues të tjerë.
Nëse mendoni se të gjitha këto paraqesin një ngarkesë të madhe pune, nuk jeni të vetmit. Në të vërtetë, ndërtimi i një sistemi të besueshëm për menaxhimin e llogarive është një detyrë e ndërlikuar. Problemi nuk është se ai është teknikisht i vështirë, por se ka shumë veçori që duhet të merren parasysh. Kjo përfshin jo vetëm rikuperimin e fjalëkalimeve, por gjithashtu një proces të plotë regjistrimi, ruajtjen e sigurt të fjalëkalimeve, trajtimin e shumë përpjekjeve të pasuksesshme për t'u kyçur, etj. , përveç saj, ka shumë më tepër për të bërë.
Sot ka shumë ofrues të palëve të treta, që e pranojnë me gëzim të gjithë dhimbjen dhe e abstrahojnë atë në një shërbim të menaxhuar. Në mesin e këtyre shërbimeve janë OpenID, OAuth dhe madje edhe Facebook. Disa njerëz (OpenID në të vërtetë ishte shumë i suksesshëm në Stack Overflow), megjithatë, disa të others .
Pa dyshim, një shërbim si OpenID zgjidh një numër problemesh për zhvilluesit, megjithatë, gjithashtu është e qartë se ai sjell të reja. A kanë ata ndonjë rol? Po, por duket se nuk po shohim përdorim masiv të shërbimeve të ofruesve të autentifikimit. Bankat, kompanitë ajrore dhe madje dyqanet - të gjitha ata implementojnë mekanizma të vetë autentifikimit, dhe është e qartë se ka arsye shumë të forta për këtë.
Rikuperimi i keq
Një aspekt i rëndësishëm i çdo një prej shembujve të përmendur më lart është se fjalëkalimi i vjetër konsiderohet i pavlerë vetëm pas konfirmimit të identitetit të pronarit të llogarisë. Kjo është e rëndësishme, sepse sikur llogaria të mund të rikuperohej në pa kontrollimin e identitetit, kjo do të lejonte veprime të ndryshme të këqija.
Ja një shembuj: dikush merr pjesë në ankande në një faqe ankandi, dhe afër fundi të procesit të ankandeve ai bllokon konkurentët duke nismuar procesin e rikuperimit, duke eliminuar kështu ata nga ankandi. Është evidente se, nëse një funksion i dobët i rikuperimit mund të keqinterpretohet, kjo mund të çojë në pasoja të rënda negative. Vlen të theksohet se bllokimi i llogarive përmes përpjekjeve të pasuksesshme për t'u kyçur është një situatë e ngjashme, por kjo është një temë për një post tjetër.
Si e thashë më lart, nëse u jepni përdoruesve anonimë mundësinë për të rikuperuar fjalëkalimin e çdo llogarie vetëm me e-mailin, atëherë krijoni një situatë ideale për sulme të tipit "moçali". Kjo mund të mos jetë ajo , për 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 të keqplanifikuar për rikuperimin e fjalëkalimit.
Pika më e dobët
Nga perspektiva e mbrojtjes së një llogarie, gjithçka e shkruar më sipër është e shkëlqyer, megjithatë, duhet gjithmonë të mbani në mend ekosistemin përreth llogarisë që po e mbrojmë. Le të jap një shembull:
ASafaWeb është hostuar në një shërbim të mrekullueshëm që ofrohet nga AppHarbor. Procesi i rikuperimit të llogarisë së hostimit ndodh kështu:
Hapi 1:
Hapi 2:
Hapi 3:
Hapi 4:
Pas lehtësimit të gjithë informacionit të mëparshëm, është e lehtë të kuptosh se cilat aspekte në një botë ideale do t'i realizonim ndryshe. Megjithatë, këtu dua të them se nëse publikoj një faqe si ASafaWeb në shërbimin AppHarbor dhe pastaj krijoj pyetje dhe përgjigje sekrete të shkëlqyera, shtoj faktorin e dytë të autentifikimit dhe bëj gjithçka sipas rregullave, kjo nuk dëfton faktin se pika më e dobët e gjithë procesit do të jetë në gjendje ta thyejë këtë. Nëse dikush arrin të autentikohet me sukses në AppHarbor duke përdorur informacionin tim, atëherë ai do të jetë në gjendje të ndryshojë fjalëkalimin e çdo llogarie ASafaWeb në atë që do!
Thelbësore është se qëndrueshmëria e implementimit të mbrojtjes duhet të konsiderohet në tërësi: duhet të modeloni kërcënimet për çdo pikë hyrjeje të sistemit, madje edhe nëse është një proces sipërfaqësor si hyrja në sistemin AppHarbor. Kjo duhet të më japë një ide të mirë se sa përpjekje duhet të investoj në procesin e rikuperimit të fjalëkalimit të ASafaWeb.
Të gjitha së bashku
Ky post përmban një sasi të madhe informacioni, prandaj dua ta përqendroj atë në një diagram të thjeshtë vizual:
Mbani mend se duhet të bëni regjistrimin më të detajuar të secilit nga këto pika. Këtu jemi, është aq e thjeshtë!
Përfundime
Posti im duket i gjithanshëm, megjithatë ekzistojnë shumë materiale të tjera që unë mund të ta përfshijë në të, por vendosi të duket nga kjo për shkak të shkurtësisë: roli i adresës së emergjencës elektronike, situata ku humbni aksesin në emailin e lidhur me llogarinë (për shembull, keni ikur nga puna) dhe kështu me radhë. Siç thashë më parë, funksioni i rikuperimit nuk është aq i komplikuar, ka vetëm shumë pikëpamje për të.
Edhe pse rikuperimi nuk është aq i vështirë, shpesh implementohet gabimisht. Më sipër kemi parë disa shembuj kur implementimi mund çon në probleme, dhe ka shumë më tepër raste kur rikuperimi i gabuar vërtetë ka shkaktuar probleme. Së fundmi doli në pah se Kjo është një rezultat negativ serioz!
Prandaj, jini të kujdesshëm me funksionet tuaja të rikuperimit, në pika të ndryshme, dhe gjatë projektimit të funksionit mos hiqni kapelën tuaj të zezë, sepse ka një mundësi të madhe që dikush tjetër do ta veshë atë!
SOF6
VDSina ofron çmime të ulëta me pagesë për ditë, çdo server është i lidhur me një kanal interneti prej 500 Megabit dhe është falas të mbrohet nga sulmet DDoS!
Burimi: habr.com
