Dvostopenjska avtentikacija
Vse, kar preberete v zadevala identifikacijo podlagi tega prosilec ve. Pozna svoj e-poštni naslov, ve, kako do njega dostopati (tj. pozna svoje e-poštno geslo) in pozna odgovore na svoja varnostna vprašanja.
"Znanje" velja za enega od dejavnikov avtentikacije; še dva pogosta dejavnika sta kar imaš, kot je fizična naprava, in kdo si, na primer prstni odtisi ali mrežnica.
V večini primerov izvedba biološke identifikacije ni izvedljiva, še posebej, ko govorimo o varnosti spletnih aplikacij, zato dvofaktorska avtentikacija (2FA) običajno uporablja drugi atribut - "kaj imaš". Ena priljubljena različica tega drugega faktorja je fizični žeton, npr. :
Fizični žeton se pogosto uporablja za avtentikacijo v podjetniških VPN in finančnih storitvah. Za preverjanje pristnosti s storitvijo morate uporabiti tako geslo kot kodo na žetonu (ki se pogosto spreminja) v kombinaciji s kodo PIN. Teoretično mora napadalec za identifikacijo poznati geslo, imeti žeton in poznati PIN žetona. V scenariju ponastavitve gesla je samo geslo očitno neznano, vendar se lahko posedovanje žetona uporabi za dokazovanje lastništva računa. Seveda, kot pri vsaki varnostni izvedbi, , vendar vsekakor dvigne oviro za vstop.
Ena od glavnih težav tega pristopa so stroški in logistika izvajanja; govorimo o predaji fizičnih naprav vsaki stranki in jih naučimo novega postopka. Poleg tega morajo imeti uporabniki napravo pri sebi, kar pa ne velja vedno za fizični žeton. Druga možnost je implementacija drugega dejavnika avtentikacije s pomočjo SMS-a, ki lahko v primeru 2FA služi kot potrditev, da ima oseba, ki izvaja postopek ponastavitve, mobilni telefon lastnika računa. Google to počne tako:
Prav tako morate omogočiti , vendar to pomeni, da bo vaš mobilni telefon naslednjič, ko ponastavite geslo, morda postal drugi dejavnik preverjanja pristnosti. Naj to pokažem s svojim iPhoneom iz razlogov, ki bodo kmalu jasni:
Po identifikaciji e-poštnega naslova računa Google ugotovi, da je 2FA omogočen in lahko ponastavimo račun s preverjanjem, ki je poslano prek SMS-a na mobilni telefon lastnika računa:
Zdaj moramo izbrati začetek postopka ponastavitve:
To dejanje povzroči, da se e-poštno sporočilo pošlje na registriran naslov:
To e-poštno sporočilo vsebuje URL za ponastavitev:
Ko dostopate do URL-ja za ponastavitev, se pošlje SMS in spletno mesto vas prosi, da ga vnesete:
To je SMS:
Ko ga vnesemo v brskalnik, smo spet na območju klasične ponastavitve gesla:
To se verjetno zdi malo dolgovezno in tudi je, vendar obrazec potrjuje, da ima oseba, ki izvaja ponastavitev, dostop do e-poštnega naslova in mobilnega telefona lastnika računa. Lahko pa je devetkrat bolj varno kot ponastavitev gesla samo po e-pošti. Vendar pa obstajajo težave ...
Težava je povezana s pametnimi telefoni. Naprava, prikazana spodaj, lahko preverja pristnost samo z enim faktorjem preverjanja pristnosti – zmožna je prejemati sporočila SMS, ne pa e-pošte:
Vendar pa ta naprava lahko prejema SMS и prejemanje e-poštnih sporočil za ponastavitev gesla:
Težava je v tem, da na e-pošto gledamo kot na prvi dejavnik avtentikacije, na SMS (ali celo aplikacijo za ustvarjanje žetonov) pa kot na drugega, vendar sta danes združena v eno napravo. Seveda to pomeni, da če kdo dobi v roke vaš pametni telefon, bo vse to udobje zmanjšano na dejstvo, da smo spet nazaj na enem kanalu; ta drugi faktor "to, kar imaš" pomeni, da imaš tudi prvi faktor. In vse to je zaščiteno z enim štirimestnim PIN-om...če telefon PIN sploh ima и bil je blokiran.
Da, funkcija 2FA, ki jo izvaja Google, zagotovo zagotavlja dodatno zaščito, vendar ni zanesljiva in zagotovo ni odvisna od dveh popolnoma avtonomnih kanalov.
Ponastavitev po uporabniškem imenu proti ponastavitvi po e-poštnem naslovu
Ali naj dovolim samo ponastavitve po e-poštnem naslovu? Ali pa bi moral uporabnik imeti možnost ponastaviti tudi po imenu? Težava pri ponastavitvi z uporabniškim imenom je, da uporabnika ni mogoče obvestiti, da je uporabniško ime napačno. brez razkritja da ima lahko nekdo drug račun s tem imenom. V prejšnjem razdelku je ponastavitev e-pošte zagotovila, da bo pravi lastnik te e-pošte vedno prejel povratne informacije, ne da bi javno razkril obstoj te e-pošte v sistemu. Tega ni mogoče storiti samo z uporabniškim imenom.
Odgovor je torej kratek: samo e-pošta. Če poskušate ponastaviti samo z uporabniškim imenom, se bo v nekaterih primerih uporabnik spraševal, kaj se je zgodilo, ali boste razkrili obstoj računov. Da, to je samo uporabniško ime, ne e-poštni naslov, in da, vsak lahko izbere katero koli (razpoložljivo) uporabniško ime, vendar še vedno obstaja velika verjetnost, da boste posredno razkrili lastnike računa zaradi nagnjenosti uporabnikov k ponovni uporabi imena.
Kaj se torej zgodi, ko nekdo pozabi svoje uporabniško ime? Ob predpostavki, da uporabniško ime ni takoj e-poštni naslov (kar je pogosto), je postopek podoben, kot se začne ponastavitev gesla – vnos e-poštnega naslova in nato pošiljanje sporočila na ta naslov, ne da bi razkrili njegov obstoj. Edina razlika je, da tokrat sporočilo vsebuje le uporabniško ime in ne URL-ja za ponastavitev gesla. Ali to, ali pa bo v e-pošti pisalo, da za ta naslov ni računa.
Preverjanje identitete in točnost elektronskega naslova
Ključni vidik ponastavitve gesla in morda celo večina ključni vidik je preverjanje identitete osebe, ki poskuša ponastaviti. Ali je to dejansko zakoniti lastnik računa ali ga nekdo poskuša vdreti ali povzročati neprijetnosti lastniku?
Očitno je e-pošta najprimernejši in najpogostejši kanal za preverjanje identitete. Ni varen in obstaja veliko primerov, ko preprosto prejemanje e-poštnih sporočil na naslov lastnika računa ni dovolj, če je potrebna visoka stopnja zaupanja v identifikacijo (zato se uporablja 2FA), vendar je skoraj vedno postopek ponastavitve začetne točke.
Če bo e-pošta igrala vlogo pri zagotavljanju zagotovila, je prvi korak zagotoviti, da je e-poštni naslov dejansko pravilen. Če je nekdo naredil napačen simbol, se ponastavitev očitno ne bo začela. Postopek preverjanja elektronske pošte ob registraciji je zanesljiv način za preverjanje pravilnosti naslova. Vsi smo to videli v praksi: prijavite se, pošljejo vam e-poštno sporočilo z edinstvenim URL-jem, na katerega kliknete, kar potrjuje, da ste dejansko lastnik tega e-poštnega računa. Če se ne morete prijaviti, dokler ta postopek ni končan, zagotavlja, da ste motivirani, da potrdite svoj naslov.
Kot pri mnogih drugih vidikih varnosti tudi ta model ogroža uporabnost v zameno za zagotavljanje povečane varnosti glede na zaupanje v identiteto uporabnika. To je morda sprejemljivo za spletno mesto, kjer uporabnik visoko ceni registracijo in bi z veseljem dodal še en korak v procesu (plačljive storitve, bančništvo itd.), vendar lahko takšne stvari uporabnika odvrnejo, če dojema račun kot »za enkratno uporabo«. ” in uporablja na primer preprosto kot sredstvo za komentiranje objave.
Prepoznavanje, kdo je sprožil postopek ponastavitve
Očitno obstajajo razlogi za zlonamerno uporabo funkcije ponastavitve in napadalci jo lahko uporabljajo na veliko različnih načinov. En preprost trik, s katerim lahko pomagamo preveriti izvor zahteve (ta trik Običajno deluje) - to je dodano pismu, ki ponuja ponastavitev naslova IP vlagatelja zahteve. Dobavlja prejemniku nekaj informacije za identifikacijo vira zahteve.
Tukaj je primer funkcije ponastavitve, ki jo trenutno vgrajujem v ASafaWeb:
Povezava »izvedi več« vodi uporabnika na spletno mesto , poročanje informacij, kot sta lokacija in organizacija zahtevka za ponastavitev:
Seveda ima vsakdo, ki želi skriti svojo identiteto, veliko načinov, kako prikriti svoj resnični naslov IP, vendar je to priročen način za dodajanje delne identifikacije prosilca in večina primerih boste tako dobili dobro predstavo o tem, kdo bo izpolnil zahtevo za ponastavitev gesla.
Obveščanje o spremembah po elektronski pošti
Ta objava je prežeta z eno temo – komunikacijo; Povejte lastniku računa čim več o tem, kaj se dogaja na vsaki stopnji postopka, ne da bi razkrili karkoli, kar bi lahko zlonamerno uporabili. Enako velja za situacijo, ko je geslo dejansko spremenjeno - prijavi to lastniku!
Za spremembo gesla sta lahko dva razloga:
- Spreminjanje gesla po prijavi, ker uporabnik želi novo geslo
- Ponastavitev gesla brez prijave, ker ga je uporabnik pozabil
Čeprav ta objava govori predvsem o ponastavitvi, obveščanje prvega zmanjša tveganje, da bi nekdo spremenil geslo brez vednosti pravega lastnika. Kako se to lahko zgodi? Zelo pogost scenarij je, da se pridobi geslo pravega lastnika (ponovno uporabljeno geslo, ki je pricurljalo iz drugega vira, geslo, zapisano s tipkovnico, geslo, ki ga je enostavno uganiti itd.), nato pa se napadalec odloči, da ga spremeni in tako zaklene lastnika. . Brez obvestila po e-pošti pravi lastnik ne bo vedel za spremembo gesla.
Seveda bi v primeru ponastavitve gesla lastnik že sprožil postopek sam (ali zaobšel zgoraj opisane preverjalnike identifikacije), zato sprememba ne bi smel morda bo zanj presenečenje, vendar bo potrditev po elektronski pošti pozitivna povratna informacija in dodatno preverjanje. Zagotavlja tudi skladnost z zgornjim scenarijem.
Oh, in če že ni bilo očitno - Ne pošiljajte novega gesla po pošti! Morda bo to koga nasmejalo, vendar :
Polena, polena, polena in še nekaj polen
Funkcija ponastavitve gesla je privlačna za napadalce: napadalec želi pridobiti dostop do računa druge osebe ali preprosto povzročiti nevšečnosti lastniku računa/sistema. Številne zgoraj opisane prakse zmanjšajo verjetnost zlorabe, vendar je ne preprečijo in prav gotovo ne bodo preprečile ljudem, da bi to funkcijo poskušali uporabiti na nenameren način.
Za prepoznavanje zlonamernega vedenja je beleženje absolutno neprecenljiva praksa, in mislim zelo podrobno beleženje. Beležite neuspele poskuse prijave, ponastavitve gesla, spremembe gesla (tj. ko je uporabnik že prijavljen) in skoraj vse, kar vam lahko pomaga razumeti, kaj se dogaja; to bo zelo koristno v prihodnosti. Prijavite se celo posameznika deli postopek, na primer, dobra funkcija ponastavitve bi morala vključevati sprožitev ponastavitve prek spletnega mesta (zajemi zahtevo za ponastavitev in poskuse prijave z napačnim uporabniškim imenom ali e-pošto), zajeti obiske spletnega mesta na URL za ponastavitev (vključno s poskusi uporabe nepravilnega žetona), in nato zabeležite uspeh ali neuspeh odgovora na varnostno vprašanje.
Ko govorim o beleženju, ne mislim samo na beleženje dejstva, da je stran naložena, ampak tudi na zbiranje čim več informacij, če ni zaupno. Fantje, prosim ne zapisujte gesel v dnevnike! Dnevniki morajo zabeležiti identiteto pooblaščenega uporabnika (ta bo pooblaščen, če bo spremembe obstoječe geslo ali poskus ponastavitve geslo nekoga drugega po prijavi), vsa uporabniška imena ali e-poštne naslove, ki jih poskusi, ter vse žetone za ponastavitev, ki jih poskusi. Vendar je vredno beležiti tudi stvari, kot so naslovi IP in, če je mogoče, celo glave zahtev. To vam omogoča poustvarjanje ne samo da uporabnik (ali napadalec) poskuša narediti, ampak tudi ki on je tak.
Prenos odgovornosti na druge izvajalce
Če mislite, da vse to predstavlja ogromno dela, niste edini. Pravzaprav izgradnja zanesljivega sistema za upravljanje računa ni lahka naloga. Ne gre za to, da je tehnično težko, le veliko funkcij ima. Ne gre samo za ponastavitev, obstaja celoten postopek registracije, varno shranjevanje gesel, obravnava več neuspelih poskusov prijave itd., itd. čeprav , poleg tega je treba storiti še veliko več.
Danes je veliko ponudnikov tretjih oseb, ki z veseljem prevzamejo vso bolečino in vse to abstrahirajo v eno upravljano storitev. Take storitve vključujejo OpenID, OAuth in celo Facebook. Nekateri ljudje (OpenID je bil res zelo uspešen pri Stack Overflowu), drugi pa .
Ni dvoma, da storitev, kot je OpenID, reši veliko težav za razvijalce, a nedvomno doda tudi nove. Ali imajo kakšno vlogo? Da, vendar očitno nismo priča množičnemu sprejemanju ponudnikov storitev preverjanja pristnosti. Banke, letalske družbe in celo trgovine izvajajo lastne mehanizme za preverjanje pristnosti in za to očitno obstajajo zelo dobri razlogi.
Zlonamerna ponastavitev
Pomemben vidik vsakega od zgornjih primerov je, da se staro geslo šteje za neuporabno po potrditvi identitete lastnika računa. To je pomembno, ker bi lahko račun ponastavili za preverjanje identifikacije, bi to omogočilo vse vrste zlonamernih dejanj.
Tukaj je primer: nekdo licitira na dražbenem mestu in proti koncu licitacijskega postopka blokira konkurente tako, da sproži postopek ponastavitve in jih tako izloči iz licitiranja. Očitno je, da lahko napačno zasnovana funkcija ponastavitve povzroči resne negativne rezultate. Omeniti velja, da so blokade računa zaradi neveljavnih poskusov prijave podobna situacija, vendar je to tema za drugo objavo.
Kot sem rekel zgoraj, če daste anonimnim uporabnikom možnost, da ponastavijo geslo katerega koli računa preprosto tako, da poznajo njihov e-poštni naslov, potem je to zrela situacija za napad z zavrnitvijo storitve. To morda ni ta , o katerem smo nekoč govorili, vendar ni hitrejšega načina za zaklepanje dostopa do računa kot uporaba slabo zasnovane funkcije za ponastavitev gesla.
Najšibkejši člen
Z vidika zaščite posameznega računa je vse zgoraj napisano super, vendar se morate vedno zavedati ekosistema okoli računa, ki ga varujete. Naj vam dam primer:
ASafaWeb gostuje v izjemni storitvi AppHarbor. Postopek ponastavitve računa gostovanja poteka takole:
1. faza:
2. faza:
3. faza:
4. faza:
Po branju vseh prejšnjih informacij je že enostavno razumeti, katere vidike bi v idealnem svetu implementirali nekoliko drugače. Vendar tukaj želim povedati, da če objavim spletno mesto, kot je ASafaWeb, na AppHarborju, in nato pripravim odlična varnostna vprašanja in odgovore, dodam drugi faktor preverjanja pristnosti in naredim vse ostalo v skladu s pravili, se to ne spremeni dejstvo, da bo najšibkejši člen v celotnem procesu sposoben zlomiti vse. Če se nekdo uspešno overi v AppHarborju z uporabo mojih podatkov, bo lahko spremenil geslo za kateri koli račun ASafaWeb v tisto, ki ga potrebuje!
Bistvo je, da je treba moč varnostne implementacije obravnavati celovito: grožnjo vsake vstopne točke v sistemu je treba modelirati, tudi če gre za površen proces, kot je prijava v sistem AppHarbor. To bi mi moralo dati dobro predstavo o tem, koliko truda moram vložiti v postopek ponastavitve gesla ASafaWeb.
Vse skupaj
Ta objava vsebuje veliko informacij, zato jo želim strniti v preprost vizualni oris:
Ne pozabite se čim bolj podrobno prijaviti za vsako od teh postavk. To je to, preprosto je!
Rezultati
Zdi se, da je moja objava izčrpna, vendar je veliko dodatnega gradiva, ki sem ga bi lahko vključujejo, vendar se zaradi jedrnatosti odločili, da ne bodo: vloga reševalnega e-poštnega naslova, situacija, v kateri izgubite dostop do e-pošte, povezane z vašim računom (na primer, date odpoved službe) itd. Kot sem že rekel, funkcija ponastavitve ni tako zapletena, vendar je nanjo mogoče gledati na veliko načinov.
Čeprav ponastavitev ni tako zapletena, je pogosto izvedena nepravilno. Zgoraj smo videli nekaj primerov izvedbe lahko povzročajo težave in obstaja veliko več primerov napačne ponastavitve res povzročal težave. Pred kratkim se je izkazalo, da . To je resen negativen rezultat!
Zato bodite previdni pri funkcijah ponastavitve, na različnih točkah, pri oblikovanju funkcije pa ne snemite črnega klobuka, saj obstaja velika verjetnost, da si ga bo nadel kdo drug!
O pravicah oglaševanja
VDSina ponuja poceni z dnevnim plačilom je vsak strežnik povezan z internetnim kanalom 500 megabitov in je brezplačno zaščiten pred DDoS napadi!
Vir: www.habr.com