Autentificarea cu două factori
Tot ce ați citit în se referă la identificarea pe baza a ceea ce știe solicitantul. El știe adresa sa de e-mail, știe cum să acceseze aceasta (adică știe parola de e-mail) și știe răspunsurile la întrebările secret.
"Cunoașterea" este considerată un factor de autentificare; celelalte două factori frecvent întâlniți sunt ceea ce aveți, de exemplu, un dispozitiv fizic, și cine sunteți, de exemplu, amprentele digitale sau retina ochiului.
În cele mai multe cazuri, realizarea identificării biologice este greu de implementat, mai ales când vorbim despre securitatea aplicațiilor web, astfel că în cazul autentificării cu două factori (two factor authentication, 2FA) se folosește de obicei al doilea atribut — "ceea ce aveți". Una dintre opțiunile populare pentru acest al doilea factor este un token fizic, de exemplu, :
Tokenul fizic este adesea folosit pentru autentificare în VPN-uri de corporație și servicii financiare. Pentru autentificarea în serviciu trebuie să folosiți atât parola, cât și codul de pe token (care se schimbă adesea) în combinație cu un PIN. Teoretic, pentru identificarea atacatorului, acesta ar trebui să știe parola, să dețină tokenul și, de asemenea, să cunoască PIN-ul tokenului. În scenariul de resetare a parolei, parola însăși este, evident, necunoscută, dar deținerea tokenului poate fi folosită pentru a confirma proprietatea contului. Desigur, ca și în cazul oricărei implementări de protecție, , dar cu siguranță crește bariera de intrare.
Una dintre problemele de bază ale acestei abordări este costul și logistica implementării; vorbim despre furnizarea de dispozitive fizice fiecărui client și despre instruirea acestora în noul proces. În plus, utilizatorii trebuie să aibă dispozitivul cu ei, ceea ce în cazul unui token fizic nu este întotdeauna garantat. O altă opțiune este implementarea celui de-al doilea factor de autentificare prin SMS, care în cazul 2FA poate servi ca o confirmare că persoana care execută procesul de resetare are telefonul mobil al proprietarului contului. Iată cum face Google:
De asemenea, este necesar să activați , dar aceasta înseamnă că, la următoarea resetare a parolei, telefonul dumneavoastră mobil poate deveni al doilea factor de autentificare. Permiteți-mi să demonstrez acest lucru folosind iPhone-ul meu din motive care vor deveni clar evidente:
După identificarea adresei de e-mail a contului Google, se determină că 2FA a fost activat și putem reseta contul printr-o verificare care este trimisă prin SMS pe telefonul mobil al proprietarului contului:
Acum trebuie să alegem începutul procesului de resetare:
Această acțiune va trimite un e-mail la adresa înregistrată:
Acest e-mail conține un URL de resetare:
Când se accesează URL-ul de resetare, un SMS este trimis, iar site-ul web cere introducerea acestuia:
Iată SMS-ul:
După ce îl introducem în browser, revenim pe teritoriul resetării clasice a parolei:
Probabil că acesta pare puțin sibilin, și așa este, dar formularul confirmă că persoana care efectuează resetarea are acces la adresa de e-mail și telefonul mobil al proprietarului contului. Dar acesta poate fi de nouă ori mai sigur decât resetarea parolei doar prin e-mail. Totuși, există probleme...
Problema este legată de smartphone-uri. Dispozitivul afișat mai jos poate verifica doar un singur factor de autentificare — este capabil să primească SMS-uri, dar nu e-mailuri:
Însă acest dispozitiv poate primi SMS-uri și primește e-mailuri despre resetarea parolei:
Problema este că noi considerăm e-mailul ca primul factor de autentificare, iar SMS-ul (sau chiar o aplicație generatoare de token-uri) ca al doilea, dar astăzi ele sunt combinate într-un singur dispozitiv. Evident, acest lucru înseamnă că, dacă cineva obține acces la smartphone-ul dumneavoastră, toată această comoditate se reduce la a reveni la un singur canal; acest al doilea factor "ceva ce aveți" înseamnă că aveți și primul factor. Și toate acestea sunt protejate de un PIN de patru cifre… dacă telefonul are un PIN deloc. și a fost blocat.
Da, funcția 2FA implementată de Google oferă cu siguranță o protecție suplimentară, dar nu este protejată "împotriva prostiei" și nu depinde complet de două canale complet autonome.
Resetare prin numele utilizatorului vs. resetare prin adresă de e-mail
Este necesar să permiteți resetarea parolei doar pe baza adresei de email? Sau utilizatorul ar trebui să aibă posibilitatea de a face resetarea și în funcție de numele de utilizator? Problema resetării pe baza numelui de utilizator este că nu există nicio modalitate de a informa utilizatorul despre un nume de utilizator incorect, fără a dezvălui faptul că altcineva ar putea avea un cont cu acel nume. În secțiunea anterioară, resetarea prin email a garantat că proprietarul legitim al acestei adrese de email va primi întotdeauna feedback fără a dezvălui public existența sa în sistem. Folosind doar numele de utilizator, acest lucru nu este posibil.
Prin urmare, răspunsul este scurt: doar email. Dacă încercați să faceți resetarea doar cu ajutorul numelui de utilizator, vor exista situații în care utilizatorul se va întreba ce s-a întâmplat, sau veți dezvălui existența conturilor. Da, este doar un nume de utilizator, nu o adresă de email și da, oricine poate alege orice nume de utilizator (disponibil), dar există totuși o mare probabilitate că veți dezvălui indirect proprietarii conturilor din cauza tendinței utilizatorilor de a folosi numele în mod repetat.
Ce se întâmplă atunci când cineva își uită numele de utilizator? Să presupunem că numele de utilizator nu este imediat adresa de email (ceea ce se întâmplă adesea), procesul seamănă cu modul în care începe resetarea parolei – introducem adresa de email și apoi trimitem un mesaj către această adresă, fără a-i dezvălui existența. Singura diferență este că de această dată mesajul conține doar numele de utilizator, nu un URL de resetare a parolei. Ori aceasta, ori în email va fi menționat că nu există niciun cont pentru această adresă.
Verificarea identității și exactitatea adreselor de email
Un aspect cheie al resetării parolelor și, chiar, probabil, cel mai important aspect este verificarea identității persoanei care încearcă să efectueze resetarea. Este cu adevărat proprietarul legitim al contului sau cineva încearcă să-l spargă sau să-i cauzeze disconfort?
Este clar că emailul este canalul cel mai convenabil și cel mai răspândit pentru verificarea identității. Nu este protejat împotriva utilizării necorespunzătoare („din partea unei persoane nepricepute”), iar există numeroase cazuri în care simpla posibilitate de a primi mesaje pe adresa proprietarului contului nu este suficientă, dacă se cere un grad ridicat de certitudine în identificare (de aceea se folosește 2FA), totuși aproape întotdeauna reprezintă punctul de plecare în procesul de resetare.
Dacă emailul va juca un rol în asigurarea certitudinii, atunci primul pas este să ne asigurăm că adresa de email este într-adevăr corectă. Dacă cineva a greșit un simbol, este evident că resetarea nu va începe. Procesul de verificare a emailului în momentul înregistrării este o metodă sigură de a verifica corectitudinea adresei. Toți am văzut acest lucru în practică: te înregistrezi, ți se trimite un email cu un URL unic, pe care trebuie să dai clic, ceea ce confirmă că tu ești cu adevărat proprietarul acestui cont de email. Imposibilitatea de a te conecta la sistem până la finalizarea acestui proces garantează o motivație pentru confirmarea adresei.
La fel ca în multe alte aspecte ale securității, un astfel de model scade utilizabilitatea în schimbul asigurării unui grad mai ridicat de siguranță în ceea ce privește certitudinea identității utilizatorului. Acest lucru poate fi acceptabil pentru un site pe care utilizatorul îl consideră valoros și este dispus să adauge încă un pas în proces (servicii plătite, banking, etc.), dar astfel de cerințe pot alunga utilizatorii dacă aceștia percep contul ca fiind „de o folosire” și îl folosesc, de exemplu, doar ca un instrument pentru a comenta un post.
Identificarea celui care a inițiat procesul de resetare
Este evident că există motive pentru utilizarea dăunătoare a funcției de resetare, iar atacatorii pot să o folosească în multe moduri diferite. Un truc simplu pe care îl putem folosi pentru a ajuta confirmarea sursei solicitării (acest truc de obicei funcționează) este adăugarea adresei IP a solicitantului în emailul cu propunerea de resetare. Aceasta le oferă destinatari o anumită informație pentru identificarea sursei solicitării.
Iată un exemplu din funcția de resetare, pe care o integrez acum în ASafaWeb:
Link-ul „find out more” („Află mai multe”) duce utilizatorul pe site , care oferă informații precum locația și organizația care solicită resetarea:
Desigur, oricine dorește să își ascundă identitatea are numeroase metode de obfuscation a adresei sale IP reale, totuși, acesta este un mod convenabil de a adăuga o parte a identificării solicitantului și în majoritatea cazuri, aceasta îți va oferi o idee suficientă despre cine va face cererea de resetare a parolei.
Notificare de schimbare prin e-mail
Acest articol este pătruns de o temă - comunicația; informeați proprietarul contului cât mai mult despre ce se întâmplă în fiecare etapă a procesului, fără a dezvălui nimic care ar putea fi folosit în scopuri rău intenționate. Aceasta se aplică și situației când parola s-a schimbat efectiv - informați-l pe proprietar!
Cauzele schimbării parolei pot proveni din două surse:
- Schimbarea parolei după autentificare, deoarece utilizatorul dorește o parolă nouă
- Resetarea parolei fără autentificare, deoarece utilizatorul a uitat-o
Deși acest articol se concentrează în principal pe resetarea parolei, notificarea în primul caz reduce riscul ca cineva să schimbe parola fără știrea proprietarului legitim. Cum poate fi asta? Un scenariu foarte comun este obținerea parolei de la proprietarul legitim (parolă reutilizată, scursă dintr-o altă sursă; parolă obținută prin keylogging; parolă ușor de ghicit etc.), după care atacatorul decide să o schimbe, blocând astfel proprietarul. Fără notificarea prin e-mail, adevăratul proprietar nu va ști despre schimbarea parolei.
Desigur, în cazul resetării parolei, proprietarul ar fi trebuit să inițieze procesul (sau să ocolească mijloacele de verificare a identității menționate mai sus), astfel încât schimbarea nu ar trebui să fie o surpriză pentru el, totuși, confirmarea prin e-mail va fi un feedback pozitiv și o verificare suplimentară. În plus, acest lucru asigură coerența cu scenariul descris mai sus.
Oh, și în cazul în care nu este deja evident - nu trimiteți noua parolă pe e-mail! Unora, acest lucru li se poate părea amuzant, dar :
Jurnale, jurnale, jurnale și încă puțin din jurnale
Funcția de resetare a parolei este atrăgătoare pentru atacatori: un atacator vrea fie să acceseze contul altcuiva, fie pur și simplu să provoace neplăceri proprietarului contului/sistemului. Multe dintre practicile menționate mai sus pot reduce probabilitatea abuzurilor, dar nu le previn, iar ele cu siguranță nu vor împiedica oamenii să încerce să utilizeze funcția într-un mod neprevăzut.
Pentru recunoașterea comportamentului malițios, o practică absolut neprețuită este logarea și mă refer la logarea foarte detaliată.Înregistrați încercările nereușite de accesare a sistemului, resetările de parole, schimbarea parolilor (adică atunci când utilizatorul este deja conectat) și practic tot ce poate să vă ajute în înțelegerea a ceea ce se întâmplă; acest lucru va fi foarte util în viitor. Înregistrați în loguri chiar și părți separate ale procesului, de exemplu, o funcție bună de resetare ar trebui să includă inițierea resetării prin intermediul site-ului web (înregistrați solicitările și încercările de accesare pentru resetare cu un nume de utilizator sau o adresă de email greșită), înregistrați vizitele site-ului web prin URL-ul de resetare (inclusiv încercările de utilizare a unui token greșit) și apoi înregistrați în log succesul sau eșecul răspunsului la întrebarea secretă. Când vorbesc despre logare, mă refer nu doar la înregistrarea faptului de accesare a paginii, ci la colectarea cât mai multor informații,
dacă nu sunt confidențiale. Prietenii,vă rog, nu înregistrați parolele în loguri! În loguri trebuie să înregistrați identitatea utilizatorului autorizat (el va fi autorizat dacă schimbă parola existentă sau încearcă să reseteze parola altuia după ce a intrat în sistem), orice nume de utilizator sau adrese de email încercate și orice token-uri de resetare pe care încearcă să le folosească. Dar, de asemenea, este important să înregistrați în loguri aspecte precum adresele IP și, dacă este posibil, chiar și antetele cererilor. Aceasta vă permite să recreați nu doar ce utilizatorul (sau atacatorul) încearcă să facă, ci și cine este el. Delegarea responsabilității altor executanți.
Delegarea responsabilității către alți executanți
Dacă credeți că tot acest lucru reprezintă o cantitate imensă de muncă, nu sunteți singuri. În realitate, construirea unui sistem de gestionare a conturilor de încredere este o sarcină complexă. Nu este vorba doar de dificultatea tehnică; sunt multe subtilități implicate. Aceasta nu se limitează doar la resetare; există un întreg proces de înregistrare, stocarea în siguranță a parolelor, gestionarea mai multor încercări greșite de autentificare etc. , dar dincolo de aceasta, mai trebuie făcut mult.
Astăzi există numeroși furnizori externi, care își asumă cu bucurie toate neplăcerile și abstractizează totul într-un singur serviciu gestionat. Printre aceste servicii se numără OpenID, OAuth și chiar Facebook. Unii oameni (OpenID s-a dovedit a fi foarte de succes pe Stack Overflow), dar alții .
Fără îndoială, un serviciu precum OpenID rezolvă multe probleme pentru dezvoltatori, însă este, de asemenea, clar că adaugă noi provocări. Au ele vreo importanță? Da, dar este evident că nu observăm o utilizare pe scară largă a serviciilor furnizorilor de autentificare. Băncile, companiile aeriene și chiar magazinele – toate implementează propriile mecanisme de autentificare, iar motivele pentru aceasta sunt foarte întemeiate.
Resetare malițioasă
Un aspect important al fiecărui exemplu menționat mai sus este că vechea parolă este considerată inutilă doar după confirmarea identității proprietarului contului. Este important, deoarece dacă contul ar putea fi resetat la fără verificarea identității, ar permite o multitudine de acțiuni malițioase.
Iată un exemplu: cineva participă la o licitație pe un site de licitații, iar aproape de finalul procesului de licitație, el blochează concurenții, inițiind procesul de resetare, eliminându-i astfel din licitație. Este evident că, dacă o funcție de resetare prost concepută poate fi exploatată, aceasta poate duce la rezultate negative severe. Merită menționat că blocarea conturilor prin încercări greșite de autentificare reprezintă o situație similară, dar aceasta este deja o temă pentru un alt post.
Așa cum am spus mai devreme, dacă le oferi utilizatorilor anonimi posibilitatea de a reseta parola pentru orice cont, doar cunoscând adresa de email, aceasta devine o situație perfectă pentru un atac de tip „refuz de serviciu”. Acesta poate să nu fie tipul de atac de care suntem obișnuiți să vorbim, dar nu există o metodă mai rapidă de a bloca accesul la un cont decât printr-o funcție de resetare a parolei prost gândită. , despre care discutăm de obicei, dar nu există o modalitate mai rapidă de a restricționa accesul la un cont decât cu ajutorul unei funcții de resetare a parolei prost concepute.
Punctul cel mai slab
Din perspectivă de securitate a unui cont, tot ceea ce am scris mai sus este excelent, însă este întotdeauna important să ții cont de ecosistemul din jurul contului pe care îl protejezi. Permite-mi să dau un exemplu:
ASafaWeb este găzduit pe un serviciu uimitor oferit de AppHarbor. Procesul de resetare a contului de găzduire se desfășoară astfel:
Pasul 1:
Pasul 2:
Pasul 3:
Pasul 4:
După ce am citit toate informațiile anterioare, este deja ușor de înțeles ce aspecte am implementa puțin diferit într-o lume ideală. Cu toate acestea, vreau să subliniez că, dacă aș publica un site similar cu ASafaWeb pe serviciul AppHarbor, iar apoi aș crea întrebări și răspunsuri secrete excelente, aș adăuga un al doilea factor de autentificare și aș urma toate celelalte reguli, acest lucru nu va elimina faptul că punctul cel mai slab din întregul proces va putea să sfideze toate acestea. Dacă cineva reușește să se autentifice în AppHarbor folosind informațiile mele, va putea schimba parola oricărui cont ASafaWeb cu cea dorită!
Ideea este că rezistența implementării securității trebuie privită în ansamblu: este necesar să simulezi amenințările fiecărei puncte de intrare a sistemului, chiar dacă acesta este un proces superficial, cum ar fi logarea în AppHarbor. Aceasta ar trebui să îmi ofere o idee clară despre cât de mult efort trebuie să investesc în procesul de resetare a parolei ASafaWeb.
Conectăm totul
Acest post conține o cantitate mare de informații, așa că vreau să îl concentrez într-un simplu grafic vizual:
Nu uitați că ar trebui să efectuați un log detaliat pentru fiecare dintre aceste puncte. Asta e tot, este simplu!
Concluzii
Postarea mea pare cuprinzătoare, totuși există multe materiale suplimentare pe care le ar putea includă-l, dar am decis să mă abțin de la acest subiect pentru concizie: rolul adresei de e-mail de recuperare, situația în care pierdeți accesul la e-mailul asociat contului (de exemplu, v-ați dat demisia de la muncă) și așa mai departe. Așa cum am spus anterior, funcția de resetare nu este atât de complexă, doar că există multe perspective asupra acesteia.
Chiar dacă resetarea nu este atât de complicată, adesea este implementată greșit. Mai sus am văzut câteva exemple când implementarea poate a dus la probleme, și există mult mai multe cazuri când o resetare greșită cu adevărat a cauzat probleme. Recent s-a descoperit că . Aceasta este o consecință extrem de negativă!
Așadar, fiți mai atenți cu funcțiile voastre de resetare, în diferite puncte, și atunci când proiectați funcția, nu vă scoateți pălăria neagră, deoarece există o mare probabilitate ca cineva să o poarte!
În numele publicității
VDSina oferă servicii ieftine cu plată pe zi, fiecare server fiind conectat la un canal de internet de 500 Megabiți și protejat gratuit împotriva atacurilor DDoS!
Sursa: habr.com
