Dvofaktorska autentifikacija
Sve što ste pročitali u vezano je uz identifikaciju na osnovu onoga što zna osoba koja traži. Ona zna svoju adresu e-pošte, zna kako doći do nje (tj. zna svoju lozinku za e-poštu) i zna odgovore na tajna pitanja.
"Znanje" se smatra jednim od faktora autentifikacije; dva druga uobičajena faktora su ono što imate, na primjer, fizički uređaj, i ono tko ste, na primjer, otisci prstiju ili mrežnica oka.
U većini slučajeva, provođenje biološke identifikacije je malo realizabilno, posebno kada govorimo o sigurnosti web aplikacija, stoga se prilikom dvofaktorske autentifikacije (two factor authentication, 2FA) obično koristi drugi atribut — "ono što imate". Jedna od popularnih opcija ovog drugog faktora je fizički token, primjerice, :
Fizički token se često koristi za autentifikaciju u korporativnim VPN-ima i financijskim uslugama. Za autentifikaciju u servisu potrebno je koristiti i lozinku i kod na tokenu (koji se često mijenja) u kombinaciji s PIN-om. Teoretski, za identifikaciju napadača mora znati lozinku, imati token, kao i znati PIN tokena. U scenariju vraćanja lozinke sama lozinka očito nije poznata, međutim posjedovanje tokena može se iskoristiti za potvrdu vlasništva nad računom. Naravno, kao i kod svake implementacije zaštite, , ali svakako povećava ulaznu barijeru.
Jedan od glavnih problema ovog pristupa je cijena i logistika implementacije; govorimo o isporuci fizičkih uređaja svakom klijentu i o obuci o novom postupku. Osim toga, korisnici moraju imati sa sobom uređaj, što u slučaju fizičkog tokena nije uvijek moguće. Još jedna opcija je implementirati drugi faktor autentifikacije putem SMS-a, koji u slučaju 2FA može služiti kao potvrda da osoba koja provodi proces vraćanja ima mobilni telefon vlasnika računa. Evo kako to radi Google:
Također je potrebno uključiti , ali to znači da bi vaš mobilni telefon mogao postati drugi faktor autentifikacije prilikom sljedećeg resetiranja lozinke. Dopustite mi da to demonstriram na primjeru svog iPhonea zbog razloga koji će uskoro postati jasni:
Nakon identifikacije adrese e-pošte, Googleov račun utvrđuje da je omogućena 2FA i možemo resetirati račun putem verifikacije koja se šalje SMS-om na mobilni telefon vlasnika računa:
Sada trebamo odabrati početak procesa resetiranja:
Ova radnja dovodi do slanja e-pošte na registriranu adresu:
Ova e-pošta sadrži URL za resetiranje:
Prilikom pristupa URL-u za resetiranje, šalje se SMS i web stranica traži njegov unos:
Evo tog SMS-a:
Nakon unosa u preglednik vraćamo se na područje klasičnog resetiranja lozinke:
Vjerojatno se čini pomalo opsceno, i tako jest, ali obrazac potvrđuje da osoba koja izvršava resetiranje ima pristup adresi e-pošte i mobilnom telefonu vlasnika računa. No, to može biti devet puta sigurnije od resetiranja lozinke isključivo putem e-pošte. Međutim, postoje problemi...
Problem se odnosi na pametne telefone. Prikazani uređaj može potvrditi samo jedan faktor autentifikacije — može primati SMS, ali ne i e-poštu:
Međutim, ovaj uređaj može primati SMS i primati poruke o resetiranju lozinke:
Problem je u tome što smatramo e-poštu prvim faktorom autentifikacije, a SMS (ili čak aplikaciju koja generira tokene) drugim, ali danas su svi spojeni u jedan uređaj. Naravno, to znači da ako netko dođe do vašeg pametnog telefona, sav taj udobnost smanjit će se na to da se ponovno vraćamo na jedan kanal; ovaj drugi faktor „to, što imate“ znači da imate i prvi faktor. A sve to je zaštićeno jednim PIN-om od četiri cifre… ako telefon uopće ima PIN i bio je zaključan.
Da, implementirana Googleova funkcija 2FA zasigurno osigurava dodatnu zaštitu, ali nije zaštićena „od budale“ i potpuno ne ovisi o dva potpuno autonomna kanala.
Resetiranje putem korisničkog imena nasuprot resetiranju putem adrese e-pošte
Treba li omogućiti resetiranje samo putem e-pošte? Ili bi korisnik trebao imati mogućnost resetiranja i prema imenu? Problem resetiranja prema korisničkom imenu je taj što nema načina da se obavijesti korisnik o pogrešnom korisničkom imenu, ne otkrivajući to da netko drugi može imati račun s tim imenom. U prethodnom odjeljku, resetiranje putem e-pošte jamčilo je da će zakoniti vlasnik te e-pošte uvijek primiti povratne informacije bez javnog otkrivanja njegovog postojanja u sustavu. Samo uporabom korisničkog imena to nije moguće.
Stoga je odgovor kratak: samo e-pošta. Ako pokušate izvršiti resetiranje samo pomoću korisničkog imena, doći će do situacija u kojima će korisnik biti zbunjen oko toga što se događa, ili otkrit ćete postojanje računa. Da, to je samo korisničko ime, a ne adresa e-pošte, i da, bilo tko može odabrati bilo koje (dostupno) korisničko ime, ali i dalje postoji velika vjerojatnost da ćete neizravno otkriti vlasnike računa zbog sklonosti korisnika višestrukom korištenju istog imena.
Što se događa kada netko zaboravi svoje korisničko ime? Ako pretpostavimo da korisničko ime nije odmah adresa e-pošte (a to se često događa), postupak je sličan onome kako počinje resetiranje lozinke — unosimo adresu e-pošte, a zatim šaljemo poruku na tu adresu, ne otkrivajući njezino postojanje. Jedina razlika je u tome što ovaj put poruka sadrži samo korisničko ime, a ne URL za resetiranje lozinke. Ili to, ili će u e-pošti pisati da za tu adresu nema računa.
Provjera identiteta i točnost adresa e-pošte
Ključni aspekt resetiranja lozinki, i, čak, vjerojatno, najvažniji aspekt je provjera identiteta osobe koja pokušava izvršiti resetiranje. Je li zaista to zakoniti vlasnik računa, ili netko pokušava hakirati ili uzrokovati neugodnosti vlasniku?
Očigledno je da je e-pošta najpraktičniji i najrašireniji kanal za provjeru identiteta. Nije zaštićena od nepromišljenog korištenja („od glupaka“), a ima mnogo slučajeva kada jednostavna mogućnost primanja poruka na adresu vlasnika računa nije dovoljna kada je potrebna visoka razina sigurnosti u identifikaciji (zbog toga se koristi 2FA), međutim, gotovo uvijek je to početna točka procesa resetiranja.
Ako e-pošta igra ulogu u osiguranju sigurnosti, prvo treba osigurati da je adresa e-pošte zapravo ispravna. Ako netko pogriješi u znaku, očigledno, resetiranje se neće započeti. Proces verifikacije e-pošte prilikom registracije je pouzdan način provjere ispravnosti adrese. Svi smo to vidjeli u praksi: registrujete se, šalju vam e-poruku s jedinstvenim URL-om na koji treba kliknuti, što potvrđuje da ste vi zaista vlasnik te adrese e-pošte. Nemogućnost prijave u sustav prije završetka ovog procesa garantira motivaciju za potvrdu adrese.
Kao i u mnogim drugim aspektima sigurnosti, takav model smanjuje korisničku pogodnost u zamjenu za povećanje razine sigurnosti u pogledu identiteta korisnika. To može biti prihvatljivo za web stranicu koju korisnik visoko cijeni i rado će dodati još jedan korak u procesu (plaćene usluge, bankarstvo itd.), ali takve stvari mogu odbiti korisnika ako smatra da je račun „jednokratni“ i koristi ga, na primjer, samo kao sredstvo za komentiranje objava.
Identifikacija onoga tko je pokrenuo proces resetiranja
Očigledno je da postoje razlozi za zlonamjernu upotrebu funkcije resetiranja, i napadači je mogu koristiti na mnogo različitih načina. Jedan jednostavan trik koji možemo koristiti kao pomoć u potvrdi izvora zahtjeva (ovaj trik obično funkcionira) je dodavanje IP adrese tražitelja u e-poruku o mogućnosti resetiranja. To daje primatelju neku informaciju za identifikaciju izvora zahtjeva.
Evo primjera iz funkcije resetiranja koju trenutno implementiram u ASafaWeb:
Veza „find out more“ („Saznajte više“) preusmjerava korisnika na stranicu , koji pruža informacije kao što su lokacija i organizacija koja traži resetiranje:
Naravno, svatko tko želi sakriti svoj identitet ima mnoštvo načina za obfuscaciju svog stvarnog IP adresa, no ovo je prikladan način dodavanja djelomične identifikacije podnositelja zahtjeva, i većini u nekim slučajevima će vam dati dovoljno informacija o tome tko će izvršiti zahtjev za resetiranje lozinke.
Obavijest o promjenama putem e-pošte
Ovaj post je prožet jednom temom — komunikacijom; obavještavajte vlasnika računa što je više moguće o tome što se događa u svakom koraku procesa, ne otkrivajući ništa što bi moglo biti korišteno u zlu. Isto se odnosi na situaciju kada je lozinka zapravo promijenjena — obavijestite vlasnika!
Razlozi za promjenu lozinke mogu imati dva izvora:
- Promjena lozinke nakon prijave, jer korisnik želi novu lozinku
- Resetiranje lozinke bez prijave, jer je korisnik zaboravio svoju lozinku
Iako je ovaj post uglavnom posvećen resetiranju, obavijest u prvom slučaju smanjuje rizik od toga da netko promijeni lozinku bez znanja zakonitog vlasnika. Kako se to može dogoditi? Vrlo čest scenarij je dobivanje lozinke zakonitog vlasnika (ponovo korištena lozinka, procurila s drugog mjesta; lozinka dobijena keyloggingom; lako pogađana lozinka itd.), nakon čega decidirano napadač odluči promijeniti, tako onemogućivši vlasnika. Bez obavijesti putem e-pošte, stvarni vlasnik neće znati za promjenu lozinke.
Naravno, u slučaju resetiranja lozinke, vlasnik bi već trebao sam pokrenuti proces (ili zaobići navedene provjere identiteta), stoga promjena ne bi trebao ne bi trebala biti iznenađenje, međutim, potvrda putem e-pošte bila bi pozitivna povratna informacija i dodatna provjera. Osim toga, to omogućava dosljednost s ranije opisanim scenarijem.
Oh, i u slučaju da to još nije očito — ne šaljite novu lozinku putem e-pošte! Neki bi se mogli nasmijati na to, ali :
Logovi, logovi, logovi i još malo logova
Funkcija resetiranja lozinke privlači napadače: napadač želi dobiti pristup nečijem računu ili jednostavno stvoriti neugodnosti vlasniku računa/sustava. Mnoge od gore navedenih praksi smanjuju vjerojatnost zloupotreba, ali ih ne sprječavaju i sigurno neće spriječiti ljude da pokušavaju koristiti funkciju na nepredviđen način.
Za prepoznavanje zlonamjernog ponašanja izuzetno je dragocjena praksa logiranje, a mislim na vrlo detaljno logiranje. Zabilježite neuspješne prijave u sustav, ponovna postavljanja lozinki, promjene lozinki (tj. kada je korisnik već prijavljen) i gotovo sve što može pomoći razumijevanju onoga što se događa; to će biti vrlo korisno u budućnosti. Zabilježite u logovima čak i pojedine dijelove procesa, primjerice, dobra funkcija resetiranja trebala bi uključivati započinjanje resetiranja putem web stranice (zabilježite zahtjev i pokušaje prijave za resetiranje s neispravnim korisničkim imenom ili e-poštom), zabilježite posjet web stranici putem URL-a za resetiranje (uključujući pokušaje korištenja neispravnog tokena), a zatim zabilježite uspješnost ili neuspjeh odgovora na tajni pitanje.
Kada govorim o logiranju, mislim ne samo na zabilježbu učitavanja stranice, već i na prikupljanje što je moguće više informacija, ako nisu povjerljive. Momci, molim vas, nemojte zapisivati lozinke u logove! U logovima treba zabilježiti identitet autoriziranog korisnika (bit će autoriziran ako mijenja postojeću lozinku ili pokušava resetirati nečiju lozinku nakon prijave), bilo koja pokušana korisnička imena ili adrese e-pošte uz bilo koje tokene resetiranja koje pokušava koristiti. No, također vrijedi zabilježiti u logovima i takve aspekte, kao što su IP adrese i, ako je moguće, čak i zaglavlja upita. To vam omogućava da rekreirate ne samo šta što korisnik (ili napadač) pokušava učiniti, već i ko tko je on.
Delegiranje odgovornosti drugim izvršiteljima
Ako mislite da je to opsežan posao, niste sami. Uistinu, izgradnja pouzdane sustava za upravljanje nalozima nije lagan zadatak. Nije riječ samo o tehničkoj složenosti, već i o mnogim specifičnostima. To uključuje ne samo resetiranje, već čitav proces registracije, sigurno pohranjivanje lozinki, obrada višestrukih neuspješnih pokušaja prijave itd. i sl. ali osim toga, potrebno je učiniti još mnogo toga.
Danas postoji mnogo vanjskih pružatelja koji rado preuzimaju sve nedaće i apsktiraju sve to u jedan upravljani servis. Među takvim servisima su OpenID, OAuth pa čak i Facebook. Neki ljudi (OpenID se doista pokazao vrlo uspješnim na Stack Overflow), međutim, drugi .
Bez sumnje, servis poput OpenID rješava mnoge probleme programerima, no također je neosporno da dodaje nove. Imaju li neku ulogu? Da, ali očito je da ne vidimo masovno korištenje usluga pružatelja autentifikacije. Banke, aviokompanije i čak prodavaonice — svi implementiraju vlastiti mehanizam autentifikacije, i očito postoji vrlo ozbiljan razlog za to.
Zlonamjerno resetiranje
Važan aspekt svakog od gore navedenih primjera je da stara lozinka postaje beskorisna samo nakon potvrde identiteta vlasnika računa.To je važno, jer kad bi se račun mogao resetirati do bez provjere identifikacije, to bi omogućilo razne zlonamjerne radnje.
Evo primjera: netko sudjeluje u aukciji, a bliže kraju procesa licitacije blokira konkurente pokretanjem procesa resetiranja, zapravo ih uklanjajući iz aukcije. Očito, ako se loše dizajnirana funkcija resetiranja može iskoristiti neispravno, to može dovesti do ozbiljnih negativnih posljedica. Treba napomenuti da blokiranje računa putem neispravnih pokušaja prijave predstavlja sličnu situaciju, ali to je već tema za drugu objavu.
Kao što sam spomenuo ranije, ako se anonimnim korisnicima dopusti resetiranje lozinke bilo kojeg računa samo znanjem adrese e-pošte, to je savršena situacija za napad tipa "usluge odbijanja". To možda nije ono , o kojem smo navikli govoriti, ali ne postoji brži način da se blokira pristup računu nego kroz loše osmišljenu funkciju resetiranja lozinke.
Najslabija karika
Iz perspektive zaštite jednog računa, sve gore navedeno je fenomenalno, međutim uvijek trebate imati na umu ekosustav koji okružuje račun koji štitite. Dopustite mi da navedem primjer:
ASafaWeb se hosta na nevjerojatnoj usluzi koju pruža AppHarbor. Proces resetiranja računa hostinga ide ovako:
Korak 1:
Korak 2:
Korak 3:
Korak 4:
Nakon što ste pročitali sve prethodne informacije, lako je razumjeti koje aspekte bismo u idealnom svijetu realizirali malo drugačije. Međutim, ovdje želim reći da ako objavim stranicu poput ASafaWeb na usluzi AppHarbor i zatim smišljam odlična tajna pitanja i odgovore, dodam drugi faktor autentifikacije i učinim sve ostalo po pravilima, to ne ukida činjenicu da će najslabija karika cijelog procesa biti sposobna sve to slomiti. Ako se netko uspješno autentificira na AppHarbor koristeći moje informacije, moći će promijeniti lozinku bilo kojeg ASafaWeb računa na ono što želi!
Bit je u tome da otpornost implementacije zaštite treba razmatrati cjelovito: potrebno je simulirati prijetnje svake ulazne točke sustava, čak i ako je to površinski proces, poput prijave na AppHarbor. To bi mi trebalo dati dobru predstavu o tome koliko truda trebam uložiti u proces resetiranja lozinke ASafaWeb.
Sve povezujemo
Ova objava sadrži veliki volumen informacija, pa želim koncentrirati to u jednostavnu vizualnu shemu:
Zapamtite da je potrebno provesti maksimalno detaljno logiranje svake od ovih stavki. To je to, jednostavno!
Zaključci
Moj post izgleda sveobuhvatno, međutim postoji mnogo dodatnih materijala koje mogu mogao uključiti u njega, ali odlučio sam se od njega odvojiti radi sažetka: uloga adrese e-pošte za oporavak, situacija u kojoj gubite pristup e-pošti povezanoj s računom (na primjer, kada ste napustili posao) i tako dalje. Kao što sam ranije rekao, funkcija resetiranja nije toliko složena, ali postoje brojni pogledi na nju.
Čak iako resetiranje nije tako teško, često se pogrešno implementira. Gore smo vidjeli nekoliko primjera kada implementacija može može dovesti do problema, a postoji mnogo više presedana kada pogrešno resetiranje zaista uzrokuje probleme. Nedavno se otkrilo da . To je ozbiljna negativna posljedica!
Zato budite oprezni sa svojim funkcijama resetiranja, na različitim točkama, a prilikom dizajniranja funkcije ne skidajte svoju crnu kapu, jer postoji velika vjerojatnost da će je netko drugi staviti!
U okviru reklame
VDSina nudi povoljne na dnevnoj osnovi, svaki poslužitelj je povezan s internet kanalom od 500 megabita i besplatno je zaštićen od DDoS napada!
Izvor: habr.com
