Kõik, mida soovisite teada paroolide turvalisest lähtestamisest. Osa 2

Kaksifaktoriline autentimine

Kõik, mida olete lugenud esimeses osas puudutas tuvastamist selle põhjal, mida teab taotleja. Ta teab oma e-posti aadressi, teab, kuidas sellele juurde pääseda (st teab oma e-posti parooli) ja teab saladusküsimustele vastuseid.

«Teadmine» loetakse üheks autentimise teguriks; kaks muud levinud tegurit on see, mis teil on, näiteks füüsiline seade, ja see, kes te olete, näiteks sõrmejäljed või silma iirised.

Enamasti on bioloogilise tuvastamise rakendamine keeruline, eriti kui räägime veebirakenduste turvalisusest, seetõttu kasutatakse kaksifaktorilisel autentimisel (two factor authentication, 2FA) tavaliselt teist attribuuti — «see, mis teil on». Üks populaarne variant sellest teisest tegurist on füüsiline token, näiteks, RSA SecurID:

Füüsilist tokenit kasutatakse sageli autentimiseks ettevõtte VPN-ides ja rahandusteenustes. Teenuses autentimiseks tuleb kasutada nii parooli kui ka kodeeritud tokenit (mis tihti muutub) koos PIN-iga. Teoreetiliselt peab ründaja isiku tuvastamiseks teadma parooli, omama tokenit ja teadma ka tokeni PIN-koodi. Parooli lähtestamise stsenaariumi puhul on parool ilmselgelt teadmata, kuid tokeni omamine võib kinnitada konto omamist. Loomulikult, nagu iga kaitse rakenduse puhul, see ei paku "idiootide kaitset", kuid kindlasti tõstab sisenemise takistust.

Üks peamisi selle lähenemise probleeme on hind ja rakenduse logistika; me räägime füüsiliste seadmete edastamisest igale kliendile ja nende uue protsessiga tutvumisest. Lisaks peab kasutajal olema seade kaasas, mida füüsilise tokeni puhul ei pruugi alati olla. Teine võimalus on rakendada teine autentimise tegur SMS-i kaudu, mis 2FA korral võib kinnitada, et isik, kes protseduuri käivitab, omab konto omaniku mobiiltelefoni. Nii teeb seda Google:

Samuti tuleb aktiveerida kaheastmeline autentimine, kuid see tähendab, et järgmise parooli lähtestamise korral võib teie mobiiltelefon saada teiseks autentimise teguriks. Las ma demonstreerin seda oma iPhone'i näitel, põhjuseid, mis varsti selguvad:

Pärast Google'i konto e-posti aadressi tuvastamist selgub, et 2FA on aktiveeritud, ja me saame konto lähtestada verifitseerimise abil, mis edastatakse SMS-iga konto omaniku mobiiltelefonile:

Nüüd peame valima lähtestamisprotsessi alguse:

See tegevus saadab e-kirja registreeritud aadressile:

See kiri sisaldab parooli lähtestamise URL-i:

Parooli lähtestamise URL-i kasutamise korral saadetakse SMS ja veebisait palub selle sisestada:

Siin on see SMS:

Pärast selle sisestamist brauserisse naaseme klassikalisse parooli lähtestamise protsessi:

See võib tunduda veidi keeruline, ja nii ongi, kuid vorm kinnitab, et parooli lähtestav isik pääseb juurde nii e-posti aadressile kui ka konto omaniku mobiiltelefonile. Kuid see võib olla kuni üheksa korda turvalisem kui parooli lähtestamine ainult e-posti kaudu. Siiski on mõned probleemid…

Probleem on seotud nutitelefonidega. Allpool näidatud seade suudab kinnitada ainult ühte autentimistegurit – see suudab saada SMS-e, kuid mitte e-kirju:

Kuid see seade suudab saada SMS-e ja saada parooli lähtestamise kirju:

Probleem on selles, et me peame e-posti esimeseks autentimise teguriks ja SMS-i (või isegi toote kasutusnime genereeriva rakenduse) teiseks, kuid täna on need ühendatud ühte seadmesse. Loomulikult tähendab see, et kui keegi pääseb juurde teie nutitelefonile, siis kõik see mugavus viib tagasi ühte kanalisse; see teine faktor „millega teil on“ tähendab, et teil on ka esimene tegur. Ja kõik see on kaitstud neljakohalise PIN-koodiga… kui telefonil üldse on PIN. ja ta on lukustatud.

Jah, Google'i rakendatud 2FA funktsioon pakub tõepoolest täiendavat kaitset, kuid see ei kaitse „idiotide” eest ja kindlasti ei sõltu see kahest täiesti autonoomsest kanalist.

Kasutajanime kaudu lähtestamine versus e-posti aadressi kaudu lähtestamine

Kas on vaja lubada lähtestamine ainult e-posti aadressi kaudu? Või peaks kasutaja olema võimeline lähtestama ka kasutajanime kaudu? Probleem kasutajanime kaudu lähtestamisega on see, et ei ole mingit võimalust kasutajat vale kasutajanime eest teavitada, ei paljastades keegi teine võib sellise nimega konto omada. Eelnevas osas tagas e-posti kaudu lähtestamine, et seaduslik omanik saab alati tagasiotsingu ilma oma olemasolu süsteemis avalikustamiseta. Ainult kasutajanimega seda teha ei saa.

Seetõttu on vastus lühike: ainult e-post. Kui proovite lähtestamist teha ainult kasutajanime abil, tekivad olukorrad, kus kasutaja ei saa aru, mis toimub. või te paljastate kontode olemasolu. Jah, see on lihtsalt kasutajanimi, mitte e-posti aadress, ja jah, igaüks võib valida mistahes (saadaval) kasutajanime, kuid siiski on suur tõenäosus, et paljastate konto omanike identiteete, kuna kasutajatel on kalduvus kasutada sama nime mitu korda.

Mida aga juhtub, kui keegi unustab oma kasutajanime? Eeldades, et kasutajanimi ei ole kohe e-posti aadress (mis juhtub sageli), on protsess sarnane parooli lähtestamise algusele — sisestame e-posti aadressi ja saadame siis teate sellele aadressile, paljastamata selle olemasolu. Ainus erinevus on see, et seekord sisaldab teade ainult kasutajanime, mitte parooli lähtestamise URL-i. Või siis on e-kirjas kirjas, et selle aadressiga ei ole kontot.

Isiku tuvastamine ja e-posti aadresside täpsus

Paroolide lähtestamise võtmeküsimus, ja tõenäoliselt isegi kõige võtmeküsimus on selle isiku tuvastamine, kes püüab lähtestamist sooritada. Kas see on tõeliselt konto seaduslik omanik või üritab keegi seda häkkida või omanikule ebamugavust tekitada?

Ilma leiab, et e-post on kõige mugavam ja levinum isikutuvastamise kanal. See ei ole kaitstud oskamatute käimiste eest („nagu tolad”), ja on palju juhuseid, kui lihtne võimalus saada kirju konto omaniku aadressile ei piisa, kui nõutakse kõrget kindlustunnet identifitseerimises (seetõttu kasutatakse ka 2FA). Kuid enamasti on see siiski protsessi taastamise alguspunkt.

Kui e-post mängib rolli usaldusväärsuse tagamisel, tuleb kõigepealt veenduda, et e-posti aadress on tõeliselt korrektne. Kui keegi teeb vea sümboliga, siis on ilmne, et taastamisprotsess ei alga. E-posti aadressi kontrollimise protsess registreerimise hetkel on usaldusväärne meetod aadressi õiguse kontrollimiseks. Oleme kõik seda praktikas näinud: teil on registreerimise ajal saadetud e-kiri ainulaadse URL-iga, millele tuleb vajutada, et kinnitada, et olete tõepoolest selle e-posti konto omanik. Sisse logimise vajaduse tagamine enne selle protsessi lõpuleviimist tagab motivatsiooni aadressi kinnitamiseks.

Nagu paljude teiste turvaelementide puhul, vähendab see mudel kasutajakogemust, et tagada kõrgemat turvalisust seoses kasutaja identiteedi usaldusväärsusega. See võib olla vastuvõetav leheküljel, mille registreerimist kasutaja kõrgelt hindab ja on valmis lisama veel ühe sammu protsessile (makseteenused, pangandust jne), kuid sellised asjad võivad kasutajat eemale tõrjuda, kui ta näeb kontot ‘ühekordse’ vahendina, näiteks lihtsalt postituse kommenteerimiseks.

Identifitseerimine, kes algatas lähtestamisprotsessi

On ilmne, et lähtestamisfunktsiooni kuritarvitamiseks on põhjuseid ja ründajad võivad kasutada seda mitmeti. Üks lihtne nipp, mida saame kasutada päringu allika kinnitamiseks (see nipp tavaliselt toimib) — see on IP-aadressi lisamine lähtestamise pakkumise e-kirja. See varustab saajat mõningase teabega päringu allika tuvastamiseks.

Siin on näide lähtestamisfunktsioonist, mida praegu ASafaWeb'i sisse integreerin:

Link „find out more“ („Uuri lähemalt“) viib kasutaja saidile ip-adress.com, mis edastab sellist teavet nagu asukoht ja korraldaja, kes taotleb parooli taastamist:

Muidugi on igal, kes soovib oma isikupära varjata, palju viise oma tegeliku IP-aadressi peitmiseks, kuid see on mugav viis lisada osaline identifitseerimine taotlejale ning enamasti annab see teile piisava ülevaate sellest, kes taotleb parooli taastamist.

Teade muudatustest e-posti teel

See postitus on küllastunud ühe teema — kommunikatsiooni; teavitage konto omanikku võimalikult palju toimuvast igas protsessi etapis, paljastamata midagi, mida võiks kasutada kuritarvitamiseks. Sama kehtib ka olukorra puhul, kui parool on tegelikult muutunud — teatage sellest omanikule!

Parooli muutmise põhjuseks võivad olla kaks allikat:

1. Parooli muutmine pärast sisse logimist, kuna kasutaja soovib uut parooli
2. Parooli taastamine ilma sisse logimata, kuna kasutaja on selle unustanud

Kuigi see postitus keskendub peamiselt passiivsete paroolide taastamisele, vähendab esimesena saadud teavitus riski, et keegi muudab parooli ilma seadusliku omaniku teadmata. Kuidas see võib juhtuda? Üks levinumaid stsenaariume on seadusliku omaniku parooli hankimine (taaskasutatud parool, mille on lekitanud mõni teine allikas; parool, mille on saanud nuhkvara abil; kergesti arvatav parool jne), mille järel otsustavad kurjategijad selle muuta, blokeerides seeläbi omaniku. Ilma e-kirja teavitamata ei tea tõeline omanik parooli muutmisest.

Muidugi, parooli taastamise korral peab omanik juba olema protsessi ise algatanud (või ületama eespool kirjeldatud identiteedi kontrolli), seega muutmine kasutada swap-i üldse. Seega pole oluline, kus see asub. Me ei ela enam 95. aastal, ausalt öeldes! ei tohiks teda üllatada, kuid e-kirja kinnitus on positiivne tagasiside ja täiendav kontroll. Lisaks tagab see ühtsuse eespool kirjeldatud stsenaariumiga.

Oh, ja juhuks, kui see pole veel ilmne — ärge saatke uut parooli e-postiga! Mõni võib sellest naerda, kuid sellised asjad juhtuvad:

Logid, logid, logid ja veel mõned logid

Parooli taastamise funktsioon on ahvatlev kurjategijatele: ründaja tahab kas saada ligipääsu teise inimese kontole või lihtsalt tekitada ebamugavusi konto/süsteemi omanikule. Paljud eespool kirjeldatud praktikad aitavad vähendada kuritarvitamise tõenäosust, kuid ei takista seda täielikult ja nad ei takista kindlasti inimesi proovimast funktsiooni ebaõigesti kasutada.

Kuritahtliku käitumise tuvastamiseks on äärmiselt väärtuslik praktika logimine, ja ma mõtlen väga detailsele logimisele. Salvestage ebaõnnestunud sisselogimise katsed, paroolide lähtestamised, paroolide muutmised (st kui kasutaja on juba sisse logitud) ja praktiliselt kõik, mis võib aidata teil mõista, mis toimub; see osutub tulevikus väga kasulikuks. Salvestage logides isegi üksikud osad protsessi, näiteks hea lähtestamisfunktsioon peaks sisaldama lähtestamise algatamist veebisaidi kaudu (salvestage päringud ja sisselogimisüritused vale kasutajanime või e-posti aadressiga), salvestage veebisaidi külastamine lähtestamise URL-i kaudu (sealhulgas vale tokeni kasutamise katsed) ja seejärel logige vastuse edukust või ebaõnnestumist salajasele küsimusele.

Kui ma räägin logimisest, siis mõistan ma mitte ainult lehe laadimise fakti salvestamist, vaid ka võimalikult palju teabe kogumist, kui see ei ole konfidentsiaalne.Poisid, palun ärge salvestage paroole logides! Logides tuleb registreerida autentitud kasutaja isik (ta on autentitud, kui ta muudab olemasolevat parooli või püüab lähtestada teise inimese parooli pärast süsteemi sisselogimist), kõik proovitud kasutajanimed või e-posti aadressid pluss kõik lähtestamis-tokenid, mida ta püüab kasutada. Samuti tasub logida selliseid aspekte nagu IP-aadressid ja, kui võimalik, isegi päringute päised. See võimaldab teil rekonstrueerida mitte ainult mida kasutaja (või ründaja) üritab teha, aga ka kes ta on selline.

Vastutuse delegeerimine teistele täitjatele

Kui arvate, et see kõik on tohutu töö, siis te ei ole üksi. Tegelikult on usaldusväärse konto haldamise süsteemi ülesehitamine keeruline ülesanne. See ei seisne ainult tehnilistes raskustes, vaid sisaldab ka mitmeid eripärasid. See hõlmab mitte ainult lähtestamist, vaid ka registreerimisprotsessi, paroolide turvalist salvestamist, mitmeid vale sisselogimise katseid jne. Kuigi ma propageerin valmiduse kasutamist nagu ASP.NET liikmesuse pakkuja, tuleb teha palju muud.

Tänapäeval on olemas palju kolmandate osapoolte teenusepakkujaid, kes on valmis võtma kõik vaevad enda kanda ja abistama seda ühes hallatavates teenustes. Selliste teenuste hulka kuuluvad OpenID, OAuth ja isegi Facebook. Mõned inimesed uskumatult usuvad sellesse mudelisse (OpenID osutus tõepoolest Stack Overflow'is väga edukaks), kuid teised peavad seda sõna otseses mõttes õuduseks..

Ilma kahtluseta lahendab OpenID sarnane teenus arendajate jaoks hulga probleeme, kuid kahtlemata toob see kaasa uusi. Kas nende roll on olemas? Jah, kuid on ilmne, et me ei näe autentimisteenuste pakkujate teenuste ulatuslikku kasutamist. Pangad, lennufirmad ja isegi poed — kõik nad rakendavad oma autentimismehhanisme ja on ilmne, et sellel on väga tugevad põhjused.

Halb kohe

Iga ülaltoodud näite oluline aspekt on see, et vana parool loetakse kasutu ainult pärast konto omaniku isiku tuvastamist. See on oluline, sest kui kontot saaks lähtestada kuni ilma identifitseerimise kontrollita, siis looks see võimalusi igasugustele pahatahtliketele tegevustele.

Näide: keegi osaleb oksjoniveebisaidil ja oksjoni lõpus blokeerib ta konkurente, käivitades lähtestamisprotsessi, eemaldades need seeläbi oksjonilt. Ilmselgelt, kui kehvalt kavandatud lähtestusfunktsiooni saab väärkasutada, võib see viia tõsiste negatiivsete tagajärgedeni. Tasub mainida, et kontode blokeerimine vale sisenemise katsete tõttu on sarnane olukord, kuid see on juba teema teiseks postituseks.

Nagu ma eelnevalt mainisin, kui anda anonüümsetele kasutajatele võimalus lähtestada mis tahes konto parool, lihtsalt tema e-posti aadressi teades, on see ideaalne olukord teenuse keelamise rünnaku jaoks. See ei pruugi olla see, millest me tavaliselt räägime, kuid ei ole kiiremat viisi konto juurdepääsu blokeerimiseks kui kehvalt läbi mõeldud parooli lähtestamise funktsiooni abil. DoS, millest me oleme harjunud rääkima, kuid ei ole kiiremat viisi konto juurdepääsu blokeerimiseks kui kehvalt läbi mõeldud parooli lähtestamise funktsiooni abil.

Kõige nõrgem lüli

Konto kaitse seisukohalt on kõik eelnev suurepärane, kuid peate alati meeles pidama ka teie kaitstava konto ökosüsteemi. Lubage mul tuua näide:

ASafaWeb on majandatud suurepärasel teenusel, mida pakub AppHarbor. Hostingu konto lähtestamise protsess toimub järgmiselt:

Samm 1:

Samm 2:

Samm 3:

Samm 4:

Kuna olen lugenud kogu eelnevat teavet, on nüüd lihtne mõista, milliseid aspekte võiksime ideaalsetes tingimustes pisut teisiti teostada. Siiski tahan öelda, et isegi kui avaldan sarnase saidi ASafaWeb AppHarboris, mõtlen välja suurepärased salajased küsimused ja vastused, lisan teise autentimise teguri ja teen kõik muud asjad õigesti, ei tühista see tõsiasja, et kogu protsessi nõrk link võib selle kõik lõhkuda. Kui keegi suudab AppHarboris autentimise edukalt läbi viia, kasutades minu andmeid, siis suudab ta ASafaWebi mis tahes konto parooli muuta soovitud parooliks!

Oluline on, et kaitse rakendamise vastupidavust tuleks vaadata tervikuna: tuleb modelleerida iga süsteemi sisenemispunkti ohte, isegi kui see on pinnapealne protsess, näiteks sisenemine AppHarborisse. See peaks andma mulle hea ülevaate sellest, kui palju energiat pean investeerima ASafaWebi parooli lähtestamise protsessi.

Seome kõik kokku

See post sisaldab suurt hulka teavet, seetõttu tahan selle koondada lihtsasse visuaalsesse skeemi:

Pidage meeles, et peaksite registreerima igasuguse teabe võimalikult üksikasjalikult. See ongi kõik, see on lihtne!

Kokkuvõte

Minu postitus tundub kõikehõlmav, kuid on palju täiendavaid materjale, mida ma võiks soovisin lisada, kuid otsustasin lühiduse huvides sellest loobuda: pääste-e-posti aadressi roll, olukord, kus kaotad juurdepääsu oma konto külge seotud e-posti (näiteks kui oled töölt lahkunud), ja nii edasi. Nagu ma varem ütlesin, pole lähtestamise funktsioon nii keeruline, lihtsalt on palju erinevaid vaatenurki sellele.

Isegi kui lähtestamine ei ole nii keeruline, tehakse seda tihti valesti. Ülalpool nägime paar näidet, kus kehv rakendamine suuteline võib põhjustada probleeme, ja on palju rohkem pretsedente, kus vale lähtestamine tõesti põhjustas probleeme. Hiljuti selgus, et lähtestamise funktsiooni kasutati 87 000 dollari väärtuses bitcoinide varastamiseks.See on tõsine negatiivne tulemus!

Seetõttu olge ettevaatlikud oma lähtestamise funktsioonide suhtes, modellige ohte. erinevates punktides, ja funktsioonide kavandamisel ärge eemaldage oma musta mütsi, sest on suur tõenäosus, et keegi teine paneb selle pähe!

Reklaami õigustes

VDSina pakub soodsaid servereid rendiks päevase maksmisega, iga server on ühendatud 500 Mbit/s internetikanaliga ja on tasuta kaitstud DDoS-rünnakute eest!

Allikas: habr.com