Kahefaktoriline autentimine
Kõik, mida sa sisse loed seotud tuvastamisega selle põhjal, et taotleja teab. Ta teab oma e-posti aadressi, teab, kuidas sellele juurde pääseda (st teab oma e-posti parooli) ja teab vastuseid turvaküsimustele.
"Teadmisi" peetakse üheks autentimisteguriks; kaks muud levinud tegurit on mis teil on, näiteks füüsiline seade ja kes sa olednäiteks sõrmejäljed või võrkkesta.
Enamikul juhtudel ei ole bioloogiline tuvastamine teostatav, eriti kui räägime veebirakenduste turvalisusest, seega kasutab kahefaktoriline autentimine (2FA) tavaliselt teist atribuuti - "mis teil on". Selle teise teguri üheks populaarseks variandiks on füüsiline märk, nt. :
Füüsilist tunnust kasutatakse sageli autentimiseks ettevõtete VPN-ides ja finantsteenustes. Teenusega autentimiseks peate kasutama nii parooli kui ka koodi (mis muutub sageli) koos PIN-koodiga. Teoreetiliselt peab ründaja tuvastamiseks teadma parooli, omama tunnust ja teadma ka tokeni PIN-koodi. Parooli lähtestamise stsenaariumi korral on parool ise ilmselgelt tundmatu, kuid märgi omamist saab kasutada konto omandiõiguse tõendamiseks. Muidugi, nagu iga turvarakenduse puhul, , kuid tõstab kindlasti sisenemisbarjääri.
Selle lähenemisviisi üks peamisi probleeme on rakendamise maksumus ja logistika; räägime füüsiliste seadmete igale kliendile üleandmisest ja uue protsessi õpetamisest. Lisaks peab kasutajatel olema kaasas seade, mis füüsilise märgi puhul alati nii ei ole. Teine võimalus on rakendada SMS-i abil autentimise teist tegurit, mis 2FA puhul võib olla kinnituseks, et lähtestamisprotsessi teostajal on konto omaniku mobiiltelefon. Google seda teeb järgmiselt.
Samuti peate lubama , kuid see tähendab, et järgmine kord, kui parooli lähtestate, võib teie mobiiltelefonist saada teine autentimisfaktor. Lubage mul demonstreerida seda oma iPhone'iga põhjustel, mis peagi selgeks saavad:
Pärast konto e-posti aadressi tuvastamist teeb Google kindlaks, et 2FA on lubatud ja saame konto lähtestada kinnituse abil, mis saadetakse SMS-iga konto omaniku mobiiltelefonile:
Nüüd peame valima lähtestamisprotsessi alustamise:
See toiming põhjustab meili saatmise registreeritud aadressile:
See meil sisaldab lähtestatud URL-i:
Kui avate lähtestatud URL-i, saadetakse SMS ja veebisait palub teil see sisestada:
See on SMS:
Pärast selle brauserisse sisestamist oleme tagasi klassikalisel parooli lähtestamise territooriumil:
Tõenäoliselt kõlab see pisut paljusõnaliselt ja nii see on, kuid vorm kinnitab, et lähtestamise teostajal on juurdepääs kontoomaniku meiliaadressile ja mobiiltelefonile. Kuid see võib olla üheksa korda turvalisem kui parooli lähtestamine ainuüksi meili teel. Siiski on probleeme...
Probleem on seotud nutitelefonidega. Allpool näidatud seade saab autentida ainult ühe autentimisteguriga – see on võimeline vastu võtma SMS-e, kuid mitte e-kirju:
Selle seadmega saab aga SMS-e vastu võtta и saada parooli lähtestamise e-kirju:
Probleem on selles, et me käsitleme autentimise esimeseks teguriks e-posti ja teiseks SMS-i (või isegi märgi genereerivat rakendust), kuid tänapäeval on need ühendatud ühes seadmes. See tähendab muidugi seda, et kui keegi jõuab sinu nutitelefonini, siis kogu see mugavus taandub sellele, et oleme jälle sama kanali juures tagasi; see teine tegur "mis teil on" tähendab, et teil on ka esimene tegur. Ja see kõik on kaitstud ühe neljakohalise PIN-koodiga...kui telefonil üldse PIN-kood on. и ta oli blokeeritud.
Jah, Google'i 2FA funktsioon pakub kindlasti lisakaitset, kuid see pole lollikindel ja kindlasti ei sõltu see kahest täiesti autonoomsest kanalist.
Lähtestamine kasutajanime järgi vs lähtestamine e-posti aadressi järgi
Kas ma peaksin lubama lähtestamist ainult meiliaadressi järgi? Või peaks kasutaja saama ka nime järgi lähtestada? Kasutajanime järgi lähtestamise probleem seisneb selles, et kasutajat ei ole võimalik kehtetust kasutajanimest teavitada, ilma paljastamata et kellelgi teisel võib olla sellenimeline konto. Eelmises jaotises tagas meili lähtestamine, et selle meili õigustatud omanik saab alati tagasisidet ilma oma olemasolu süsteemis avalikult avaldamata. Seda ei saa teha ainult kasutajanimega.
Seega on vastus lühike: ainult meili teel. Kui proovite lähtestada ainult kasutajanime kasutades, tekib juhtumeid, kus kasutaja imestab, mis juhtus, või avaldate kontode olemasolu. Jah, see on lihtsalt kasutajanimi, mitte e-posti aadress, ja jah, igaüks saab valida mis tahes (saadaoleva) kasutajanime, kuid siiski on suur võimalus, et avaldate kaudselt kontoomanikke, kuna kasutajad kalduvad nime uuesti kasutama.
Mis juhtub siis, kui keegi unustab oma kasutajanime? Eeldades, et kasutajanimi ei ole kohe e-posti aadress (mis sageli nii on), sarnaneb protsess parooli lähtestamise algusega – sisestage e-posti aadress ja seejärel saatke sellele aadressile sõnum ilma selle olemasolu avaldamata. Ainus erinevus on see, et seekord sisaldab sõnum ainult kasutajanime, mitte parooli lähtestamise URL-i. Kas see või meilis öeldakse, et sellel aadressil pole kontot.
Identiteedi kinnitamine ja e-posti aadresside täpsus
Paroolide lähtestamise põhiaspekt ja võib-olla isegi kõige rohkem Peamine aspekt on lähtestamist üritava isiku identiteedi kontrollimine. Kas see on tegelikult konto seaduslik omanik või üritab keegi seda sisse häkkida või omanikule ebamugavusi tekitada?
Ilmselgelt on e-post kõige mugavam ja levinum identiteedi kinnitamise kanal. See ei ole lollikindel ja on palju juhtumeid, kus lihtsalt konto omaniku aadressil e-kirjade vastuvõtmisest ei piisa, kui on vaja suurt identifitseerimiskindlust (sellepärast kasutatakse 2FA-d), kuid see on peaaegu alati lähtepunkt. lähtestamisprotsess.
Kui e-post mängib kindlustunde tagamisel rolli, siis esimene samm on veenduda, et meiliaadress on tegelikult õige. Kui keegi tegi sümboliga vea, siis ilmselgelt lähtestamine ei alga. E-posti kinnitamise protsess registreerimisel on usaldusväärne viis aadressi õigsuse kontrollimiseks. Oleme kõik näinud seda toimimas: registreerumisel saadetakse teile e-kiri kordumatu URL-iga, millel klõpsata, mis kinnitab, et olete selle meilikonto tegelik omanik. Kui te ei saa sisse logida enne, kui see protsess on lõpule jõudnud, siis on olemas motivatsioon aadressi kinnitamiseks.
Nagu paljude muude turvaaspektide puhul, vähendab see mudel kasutatavust vastutasuks kasutaja identiteedi kindlustundega võrreldes suurema turvalisuse pakkumise eest. See võib olla vastuvõetav saidi puhul, kus kasutaja hindab registreerimist kõrgelt ja lisab hea meelega protsessi veel ühe etapi (tasulised teenused, pangandus jne), kuid sellised asjad võivad kasutajat tõrjuda, kui ta tajub kontot kui "ühe- aeg” ja kasutab näiteks lihtsalt postituse kommenteerimise vahendina.
Lähtestamisprotsessi algataja tuvastamine
Ilmselgelt on lähtestamisfunktsiooni pahatahtlikul kasutamisel põhjused ja ründajad saavad seda kasutada mitmel erineval viisil. Üks lihtne nipp, mida saame kasutada päringu päritolu kontrollimiseks (see trikk tavaliselt töötab) - see lisatakse kirjale, mis pakub taotleja IP-aadressi lähtestamist. See varustab saajat mõned teave päringu allika tuvastamiseks.
Siin on näide lähtestamisfunktsioonist, mida ma praegu ASafaWebi ehitan:
Link "Lisateavet" viib kasutaja saidile , mis sisaldab sellist teavet nagu lähtestamise taotleja asukoht ja organisatsioon:
Muidugi on kõigil, kes soovivad oma identiteeti varjata, palju võimalusi oma tegeliku IP-aadressi häguseks muutmiseks, kuid see on mugav viis taotleja osalise identifitseerimise lisamiseks ja enamus juhtudel annab see teile hea ülevaate sellest, kes parooli lähtestamise taotluse täidab.
E-posti muutmise teatis
See postitus on läbi imbunud ühest teemast – suhtlemine; Rääkige konto omanikule võimalikult palju protsessi igas etapis toimuvast, paljastamata midagi, mida saaks pahatahtlikult kasutada. Sama kehtib ka olukorra kohta, kus parool on tegelikult muutunud − teavita omanikku!
Parooli muutmisel võib olla kaks põhjust:
- Parooli muutmine pärast sisselogimist, kuna kasutaja soovib uut parooli
- Parooli lähtestamine ilma sisse logimata, kuna kasutaja unustas selle
Kui see postitus puudutab peamiselt lähtestamist, siis esimesele teatamine vähendab ohtu, et keegi muudab parooli õigusjärgse omaniku teadmata. Kuidas see juhtuda saab? Väga levinud stsenaarium on see, et hankitakse õige omaniku parool (teisest allikast lekkinud taaskasutatud parool, klahvilogitud parool, kergesti äraarvatav parool jne) ning seejärel otsustab ründaja selle ära muuta, lukustades sellega omaniku. . Ilma meiliteateta ei saa tegelik omanik paroolivahetusest teada.
Loomulikult oleks parooli lähtestamise korral omanik protsessi juba ise algatanud (või eelkirjeldatud identifitseerimiskontrollidest mööda hiilinud), nii et muudatus ei peaks võib olla talle üllatus, kuid meilikinnitus on positiivne tagasiside ja täiendav kinnitus. See tagab ka kooskõla ülaltoodud stsenaariumiga.
Oh, ja kui see poleks juba ilmne - Ärge saatke uut parooli posti teel! See võib mõne inimese naerma ajada, aga :
Palgid, palgid, palgid ja veel mõned palgid
Parooli lähtestamise funktsioon on ründajate jaoks atraktiivne: ründaja soovib saada juurdepääsu teise inimese kontole või tekitab konto/süsteemi omanikule lihtsalt ebamugavusi. Paljud ülalkirjeldatud tavad vähendavad kuritarvitamise võimalust, kuid ei hoia seda ära ning kindlasti ei takista need inimesi üritamast funktsiooni soovimatul viisil kasutada.
Pahatahtliku käitumise tuvastamiseks on logimine täiesti hindamatu tava, ja ma mõtlen väga üksikasjalik logimine. Jäädvustage ebaõnnestunud sisselogimiskatsed, paroolide lähtestamine, paroolide muutmine (st kui kasutaja on juba sisse logitud) ja peaaegu kõike, mis aitab teil toimuvast aru saada; sellest on tulevikus palju kasu. Kinnitage logid isegi üksikult osad protsess, näiteks hea lähtestamisfunktsioon peaks hõlmama lähtestamise algatamist veebisaidi kaudu (lähtestamistaotluse ja sisselogimiskatsete jäädvustamine vale kasutajanime või e-posti aadressiga), veebisaidi külastuste jäädvustamist lähtestamise URL-ile (sealhulgas katsed kasutada vale luba), ja seejärel logige turvaküsimuse vastuse õnnestumine või ebaõnnestumine.
Kui ma räägin logimisest, ei pea ma silmas mitte ainult lehe laadimise fakti salvestamist, vaid ka võimalikult suure teabe kogumist, kui see pole konfidentsiaalne. Poisid, palun ärge kirjutage logidesse paroole! Logid peavad registreerima volitatud kasutaja identiteedi (ta volitatakse, kui ta muudatused olemasolevat parooli või proovite lähtestada kellegi teise parool pärast sisselogimist) kõik kasutajanimed või e-posti aadressid, mida ta proovib, ning kõik lähtestamismärgid, mida ta proovib kasutada. Kuid tasub logida ka selliseid asju nagu IP-aadressid ja võimalusel isegi päringu päised. See võimaldab teil uuesti luua mitte ainult et kasutaja (või ründaja) üritab seda teha, aga ka kes ta on selline.
Vastutuse delegeerimine teistele esinejatele
Kui arvate, et see kõik tähendab tohutut tööd, pole te üksi. Tegelikult pole usaldusväärse kontohaldussüsteemi loomine lihtne ülesanne. Asi pole selles, et see oleks tehniliselt keeruline, vaid sellel on lihtsalt palju funktsioone. See ei puuduta ainult lähtestamist, vaid terve registreerimisprotsess, paroolide turvaline salvestamine, mitme ebaõnnestunud sisselogimiskatse käsitlemine jne jne. Kuigi , peale selle tuleb veel palju ära teha.
Tänapäeval on palju kolmandatest osapooltest tarnijaid, kes võtavad hea meelega valu maha ja koondavad selle kõik üheks hallatavaks teenuseks. Nende teenuste hulka kuuluvad OpenID, OAuth ja isegi Facebook. Mõned inimesed (OpenID on Stack Overflow’s tõepoolest väga edukas olnud), aga teised .
Pole kahtlust, et selline teenus nagu OpenID lahendab arendajate jaoks palju probleeme, kuid kahtlemata lisab see ka uusi. Kas neil on mingi roll? Jah, kuid ilmselgelt ei näe me autentimisteenuste pakkujate massilist kasutuselevõttu. Pangad, lennufirmad ja isegi kauplused rakendavad kõik oma autentimismehhanismi ja sellel on ilmselgelt väga head põhjused.
Pahatahtlik lähtestamine
Kõigi ülaltoodud näidete oluline aspekt on see, et vana parooli peetakse ainult kasutuks pärast konto omaniku isiku kinnitamist. See on oluline, sest kui konto saab lähtestada kuni identifitseerimise kontrollimine, annaks see võimaluse kõikvõimalikeks pahatahtlikeks tegevusteks.
Siin on näide: keegi teeb oksjonisaidil pakkumist ja pakkumisprotsessi lõpus blokeerib ta konkurendid lähtestamisprotsessi algatamisega, kõrvaldades nad seega pakkumisest. Ilmselgelt võib halvasti kavandatud lähtestamisfunktsiooni väärkasutamine põhjustada tõsiseid negatiivseid tulemusi. Väärib märkimist, et konto lukustamine kehtetute sisselogimiskatsete tõttu on sarnane olukord, kuid see on mõne teise postituse teema.
Nagu ma eespool ütlesin, kui annate anonüümsetele kasutajatele võimaluse lähtestada mis tahes konto parool lihtsalt nende e-posti aadressi teades, on see teenuse keelamise rünnaku jaoks valmis olukord. See ei pruugi olla see üks , millest me varem rääkisime, kuid pole kiiremat võimalust kontole juurdepääsu blokeerimiseks kui halvasti läbimõeldud parooli lähtestamise funktsioon.
Kõige nõrgem lüli
Ühe konto kaitsmise seisukohast on kõik ülalkirjeldatu suurepärane, kuid alati tuleb meeles pidada ökosüsteemi, mis ümbritseb kaitstavat kontot. Lubage mul tuua teile näide:
ASafaWeb on hostitud suurepärases teenuses, mida pakub AppHarbor. Hostingikonto lähtestamise protsess käib järgmiselt:
1. etapp:
2. etapp:
3. etapp:
4. etapp:
Pärast kogu eelneva info lugemist on juba lihtne aru saada, milliseid aspekte me ideaalmaailmas veidi teisiti rakendaksime. Kuid ma ütlen siin seda, et kui ma avaldan AppHarboris sellise saidi nagu ASafaWeb ja esitan seejärel suurepäraseid turvaküsimusi ja vastuseid, lisan teise autentimisfaktori ja teen kõike muud reeglite kohaselt, siis see ei muutu. asjaolu, et kogu protsessi nõrgim lüli suudab selle kõik murda. Kui keegi autentib AppHarboris edukalt minu teavet kasutades, saab ta muuta mis tahes ASafaWebi konto parooli vajalikuks!
Asi on selles, et turberakenduse tugevust tuleks käsitleda terviklikult: iga süsteemi sisenemispunkti ohtu tuleb modelleerida, isegi kui see on pealiskaudne protsess, näiteks AppHarbori süsteemi sisselogimine. See peaks andma mulle hea ettekujutuse sellest, kui palju vaeva ma pean ASafaWebi parooli lähtestamise protsessiga tegema.
Kõike kokku panema
See postitus sisaldab palju teavet, nii et ma tahan selle koondada lihtsasse visuaalsesse ülevaatesse:
Pidage meeles, et peaksite kõigi nende üksuste kohta kõige üksikasjalikumalt logima. See on kõik, see on lihtne!
Tulemused
Minu postitus näib olevat kõikehõlmav, kuid minu jaoks on palju lisamaterjali võiks sisaldama, kuid otsustasin seda lühiduse huvides mitte teha: pääste-e-posti aadressi roll, olukord, kus kaotate juurdepääsu oma kontoga seotud meilile (näiteks lahkute töölt) ja nii edasi. Nagu ma varem ütlesin, pole lähtestamise funktsioon nii keeruline, kuid selle vaatamiseks on palju võimalusi.
Kuigi lähtestamine pole nii keeruline, rakendatakse seda sageli valesti. Eespool nägime paari näidet, kus rakendamine võib põhjustada probleeme ja vale lähtestamise korral on palju rohkem pretsedente tegelikult tekitanud probleeme. Hiljuti selgus, et . See on tõsine negatiivne tulemus!
Nii et olge lähtestamisfunktsioonidega ettevaatlik, erinevates punktides ja funktsiooni kujundamisel ära võta musta mütsi peast, sest on suur võimalus, et keegi teine paneb selle pähe!
Reklaamide õiguste kohta
VDSina pakub odavalt igapäevase maksega on iga server ühendatud 500 megabitise Interneti-kanaliga ja on tasuta kaitstud DDoS-i rünnakute eest!
Allikas: www.habr.com