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

Kahefaktori autentimine

Kõik, mida olete lugenud esimeses osas puudutab tuvastamist selle alusel, mida teab küsija. Ta teab oma e-posti aadressi, teab, kuidas sellele juurde pääseda (st teab oma e-posti parooli) ja teab salajaste küsimuste 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 võrkkest.

Enamikul juhtudel on bioloogilise tuvastamise teostamine praktiliselt võimatu, eriti kui räägime veebirakenduste turvalisusest, seetõttu kasutatakse kahefaktorilises autentimises (two-factor authentication, 2FA) tavaliselt teist atribuuti — "see, mis teil on". Üks populaarne teine tegur on füüsiline token, näiteks RSA SecurID:

Füüsilist tokenit kasutatakse sageli autentimiseks ettevõtte VPN-ides ja finantsteenustes. Autentimiseks on vajalik kasutada nii parooli kui ka tokenil olevaid koode (mis sageli muutuvad) koos PIN-koodiga. Teoreetiliselt peab ründaja identifitseerimise jaoks teadma parooli, omama tokenit ja teadma ka tokeni PIN-koodi. Parooli lähtestamise stsenaariumis ei ole parool kindlasti teada, kuid tokeni omamine saab kasutada konto omandi kinnitamiseks. Muidugi, nagu iga kaitse rakendamise puhul, ei taga see "lollikaitset", kuid kindlasti tõstab sissepääsu takistust.

Üks peamisi selle lähenemise probleeme on rakendamise maksumus ja logistika; räägime füüsiliste seadmete jagamisest igale kliendile ja nende uue protsessi õpetamisest. Lisaks peavad kasutajad seadmeid endaga kaasas kandma, mis füüsilise tokeni puhul ei pruugi alati nii olla. Veel üks variant on rakendada teist autentimistegurit SMS-i kaudu, mis 2FA puhul võib tõendada, et parooli lähtestamise protsessi teostav isik omab konto omaniku mobiiltelefoni. Nii teeb seda Google:

Samuti tuleb lubada kahefaktoriline autentimine, kuid see tähendab, et järgmise parooli lähtestamise korral võib teie mobiiltelefon olla teine autentimise tegur. Las ma demonstreerin seda oma iPhone'i näitel, põhjused saavad peagi selgeks:

Pärast Google'i konto e-posti aadressi tuvastamist selgub, et 2FA on lubatud ja saame konto lähtestada kinnitamisega, mis saadetakse SMS-iga konto omaniku mobiiltelefonile:

Nüüd peame valima lähtestamisprotsessi alguse:

See tegevus toob kaasa e-kirja saatmise registreeritud aadressile:

See kiri sisaldab lähtestamise URL-i:

Pärast lähtestamise URL-i avamist saadetakse SMS ja veebisait palub selle sisestada:

Siin on see SMS:

Pärast selle sisestamist brauserisse naaseme klassikalise parooli lähtestamise territoriumi:

Tõenäoliselt tundub see veidi sõnasõnaline, ja nii see ongi, kuid vorm kinnitab, et lähtestamise teostaja pääseb ligi nii konto omaniku e-posti aadressile kui ka mobiiltelefonile. Kuid see võib olla kuni üheksa korda turvalisem kui parooli lähtestamine ainult e-posti kaudu. Kuid probleemid on siiski olemas...

Probleemi juured on nutitelefonides. Allolev seade suudab kinnitada vaid ühte autentimise tegurit — see suudab vastu võtta SMS-e, kuid mitte e-kirju:

Kuid see seade suudab vastu võtta SMS-e ja vastu võtta parooli lähtestamise kirju:

Probleem on selles, et käsitleme e-posti kui esimest autentimise tegurit ja SMS-i (või isegi tokenite genereerimise rakendust) kui teist, kuid tänapäeval on need ühendatud ühte seadmesse. Loomulikult tähendab see, et kui keegi pääseb teie nutitelefonile ligi, siis kõik see mugavus toob meid tagasi ühte kanalisse; see teine tegur 'mida teil on' tähendab, et teil on ka esimene tegur. Ja kõik see on kaitstud neljanumbrilise PIN-iga... kui telefonil tõesti on PIN. ja ta oli lukustatud.

Jah, Google'i 2FA funktsioon pakub kindlasti lisakaitset, kuid see ei ole 'idioti' vastu kaitstud ja ei sõltu kahest täiesti isese from kanalist.

Kasutajanime kaudu lähtestamine vs e-posti aadresse kaudu lähtestamine

Kas on vajalik lubada parooli lähtestamine ainult e-posti aadressi kaudu? Või peaks kasutajal olema võimalus lähtestada see ka nime kaudu? Probleem nime kaudu lähtestamisel on see, et pole mingit võimalust teavitada kasutajat vale nime olemasolust, ära avades et keegi teine võib omada kontot selle nimega. Eelmises osas tagas e-posti kaudu lähtestamine, et selle e-posti seaduslik omanik saab alati tagasisidet ilma avaliku teabe avalikustamiseta oma olemasolust süsteemis. Ainult kasutajanime kaudu on seda võimatu teha.

Seega on vastus lühike: ainult e-post. Kui proovite lähtestada ainult kasutajanime kaudu, esineb olukordi, kus kasutaja jääb segadusse, mis juhtus, või te avaldate olemasolevate kontode olemasolu. Jah, see on lihtsalt kasutajanimi, mitte e-posti aadress, ja jah, igaüks võib valida mistahes (saadaval oleva) kasutajanime, kuid siiski on suur tõenäosus, et te avate kaudselt konto omanike identiteeti kasutajate kalduvuse tõttu kasutada sama nime korduvalt.

Mis aga juhtub, kui keegi unustab oma kasutajanime? Eeldades, et kasutajanimi ei ole kohe e-posti aadress (ja see juhtub sageli), on protsess sarnane parooli lähtestamise algusega - sisestame e-posti aadressi ja seejärel saadame sellele aadressile teate, avalikustamata selle olemasolu. Ainus erinevus on see, et sel korral sisaldab teade ainult kasutajanime, mitte parooli lähtestamise URL-i. Kas see, või on e-kirjas märgitud, et selle aadressi jaoks ei ole kontot.

Isiku tuvastamine ja e-posti aadresside täpsus

Paroolide lähtestamise võtmeaspekt, ja isegi tõenäoliselt kõige olulisem aspekt on isiku tuvastamine, kes üritab lähtestada. Kas see on tõepoolest konto seaduslik omanik, või üritab keegi seda häkkida või tekitada omanikule ebamugavust?

On selge, et e-post on kõige lihtsam ja kõige levinum isikukontrolli kanal. See ei ole kaitstud oskamatu käitlemise eest („lollilt“), ja on palju juhtumeid, kus pelgalt võimalus saada kirju konto omanikule ei ole piisav, kui nõutakse kõrge kindlustunde taset identifitseerimisel (seetõttu kasutatakse ka 2FA), kuid peaaegu alati on see protsessi lähtestamise alguspunkt.

Kui e-post mängib rolli tõhususe tagamisel, tuleb kõigepealt kindlaks teha, et e-posti aadress on tõepoolest õige. Kui keegi eksib tähestikus, ei alga lähtestamine selgelt. E-posti verifitseerimise protsess registreerimise hetkel on usaldusväärne meetod aadressi õigsuse kontrollimiseks. Oleme kõik seda praktikas näinud: registreerides saadetakse sulle e-kiri unikaalse URL-iga, millele vajutada, et kinnitada, et sa tõepoolest oled selle e-posti konto omanik. Sisse logimise võimatus kuni selle protsessi lõpetamiseni tagab motivatsiooni aadressi kinnitamiseks.

Nagu paljude teiste turvakeerukuste puhul, vähendab see mudel kasutatavust, et tagada suurem turvalisuse tase kasutaja identiteedi usaldusväärsuse suhtes. See võib olla vastuvõetav saidile, mille registreerimist kasutaja kõrgelt hindab ja lisab hea meelega veel ühe sammu protsessi (tasulised teenused, pangandust jne), kuid sellised asjad võivad kasutajat peletada, kui ta näeb kontot „ühekordse“ vahendina, mida ta lihtsalt näiteks postituse kommenteerimiseks kasutab.

Tuletades meelde, kes algatas lähtestamisse protsessi

On selge, et on põhjuseid, miks lähtestamise funktsiooni võib kuritarvitada, ja kurjategijad võivad seda kasutada mitmeti. Üks lihtne nipp, mida saame kasutada taotluse allika kinnitamisel (see nipp tavaliselt toimib) — see on lisada lähtestamise pakkumise kirjale külastaja IP-aadress. See annab saajale teatud teavet taotluse allika tuvastamiseks.

Siin on näide lähtestamisfunktsioonist, mida ma praegu ASafaWebi integreerin:

Ling lii "find out more" viib kasutaja veebisaidile ip-adress.com, mis edastab sellist teavet nagu asukoht ja organisatsioon, kes taotles lähtestamist:

Muidugi on igal, kes soovib oma identiteeti varjata, mitmeid meetodeid, et varjata oma tõelist IP-aadressi, kuid see on mugav viis lisada osalist identifitseerimist taotlejalt, ja enamikul juhtudel annab see teile piisava ülevaate, kes taotleb parooli lähtestamist.

E-kirjaga muudatustest teavitamine

See postitus on tungivalt seotud ühe teema — suhtlemisega; teavitage konto omanikku võimalikult palju sellest, mis toimub iga etapi jooksul, paljastamata midagi, mida võiks kuritahtlikult kasutada. Sama kehtib ka siis, kui parool on tegelikult muutunud — teavitage sellest omaniku!

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

1. Parooli muutmine sisse logimise järel, sest kasutaja soovib uut parooli
2. Parooli lähtestamine ilma sisse logimata, sest kasutaja on selle unustanud

Kuigi see postitus käsitleb peamiselt lähtestamist, vähendab esimeses olukorras teavitamine riski, et keegi muudab parooli ilma seadusliku omaniku teadmiseta. Kuidas see võib juhtuda? Väga levinud stsenaarium on seadusliku omaniku parooli saamine (taaskasutatud parool, mille on lekitanud teine allikas; parool, mille on saanud nuhkvara abil; kergesti ära arvatav parool jne), mille järel ründaja otsustab selle muuta, blokeerides seeläbi omaniku. Ilma e-kirja teavitamiseta ei tea tõeline omanik parooli muutmisest.

Muidugi peab parooli lähtestamise korral omanik juba ise algatama protsessi (või mööduma eespool kirjeldatud tuvastamismeetmetest), seega ei tohi see olla talle üllatuseks, kuid e-kirjaga kinnitamine oleks positiivne tagasiside ja täiendav kontroll. Samuti tagab see ühtsuse eespool kirjeldatud stsenaariumi.

Ja juhuks, kui see pole veel ilmne — ärge saatke uut parooli e-kirjaga! See võib kedagi naerda ajada, kuid selline juhtub:

Logid, logid, logid ja veel mõned logid

Parooli lähtestamise funktsioon on ahvatlev kurjategijatele: ründaja soovib kas pääseda kellegi teise kontole või lihtsalt põhjustada vaeva konto/süsteemi omanikule. Paljud ülaltoodud praktikatest aitavad vähendada väärkasutamise tõenäosust, kuid ei takista seda täielikult ning need ei hoia inimesed tagasi proovima funktsiooni ettenähtud viisil mitte kasutama.

Kahjuliku käitumise tuvastamiseks on äärmiselt väärtuslik praktika logimine, ja ma mõtlen väga detailsele logimisele. Dokumenteerige ebaõnnestunud sisselogimisproovid, paroolide lähtestamised, paroolide muutmised (st kui kasutaja on juba sisse logitud) ja praktiliselt kõik, mis võib teid aidata arusaamisel, mis toimub; see tuleb tulevikus väga kasuks. Logige isegi eraldi osad protsessist, näiteks hea parooli lähtestamise funktsioon peaks sisaldama lähtestamise algatamist veebilehe kaudu (logige sisestus ja sisselogimiskatsed vale kasutajanime või e-posti aadressiga), logige sisse veebilehte lähtestamise URL-iga (sealhulgas vale tokeni kasutamise katsed) ning seejärel logige vastuse õigsus või vale vastus veebiküsimusele.

Kui ma räägin logimisest, siis ei tähenda ma ainult lehe laadimise fakti salvestamist, vaid ka võimalikult palju teabe kogumist, kui see ei ole konfidentsiaalne. Poisid, palun ärge salvestage logides parooli! Logides tuleb registreerida autoriseeritud kasutaja identiteet (ta on autoriseeritud, kui ta muudab olemasolevat parooli või püüab lähtestada teise isiku parooli pärast sisselogimist), kõik proovitud kasutajanime või e-posti aadressid ning kõik lähtestamise 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) püüab teha, vaid ka kes tema isik.

Kohustuste delegeerimine teistele teostajatele

Kui arvate, et see kõik on tohutu töö, siis te pole üksi. Tegelikult on usaldusväärse kontohalduse süsteemi loomine keeruline ülesanne. Asi ei ole ainult tehnilistes raskustes, vaid selles on mitmeid nüansse. See hõlmab mitte ainult parooli lähtestamist, vaid ka registreerimise protsessi, usaldusväärse paroolihalduse, mitmete vale sisselogimisürituste töötlemise jms. Kuigi ma toetan valmis lahenduste, näiteks ASP.NET membership provider'i kasutamist,, on lisaks sellele veel palju muud teha.

Tänapäeval on palju kolmanda osapoole pakkujaid, kes võtavad rõõmuga kõik vaevad enda kanda ja abstraheerivad selle ühe hallatava teenusena. Selliste teenuste hulka kuuluvad OpenID, OAuth ja isegi Facebook. Mõned inimesed usuvad piiramatu usuga sellesse mudelisse (OpenID on tõepoolest osutunud väga edukaks Stack Overflow's), kuid teised peavad seda sõna otseses mõttes õudusunenäoks..

Kahtlemata lahendab selline teenus nagu OpenID palju arendajate probleeme, kuid on kahtlemata, et see toob kaasa uusi. Kas neil on mingit rolli? Jah, kuid on ilmne, et me ei näe laialdast autentimist teenuste pakkujate teenuste kasutamist. Pangad, lennukompaniid ja isegi kauplused – kõik nad rakendavad oma autentimismehhanismi, ja see on ilmne, et sellel on väga kaalukaid põhjuseid.

Halvad parooli lähtestamised

Iga ülaltoodud näite oluline aspekt on see, et vana parool loetakse kasutuks vaid pärast konto omaniku tuvastamist.See on oluline, sest kui konto saaks lähtestada kuni ilma identiteedi kinnitamiseta, siis see looks võimalusi kõiksugu pahatahtlikeks tegevusteks.

Siin on näide: keegi osaleb oksjonisaidil ja oksjoniprotsessi lõpus blokeerib ta konkurente, algatades lähtestamisprotsessi, eemaldades seega nad oksjonilt. Ilmselgelt, kui halvasti kavandatud lähtestamisfunktsiooni saab kuritarvitada, võib see viia tõsiste negatiivsete tagajärgedeni. Tasub tähele panna, et kontode blokeerimine vale sisselogimise katsete kaudu on sarnane olukord, kuid see on juba teema teiseks postituseks.

Nagu ma ütlesin, kui anda anonüümsetele kasutajatele võimalus taastada parool igale kontole, teades lihtsalt selle e-posti aadressi, siis on see ideaalne võimalus teenuse katkestamise rünnaku jaoks. See ei pruugi olla see DoS, millest me tavaliselt räägime, kuid pole kiiremat viisi kontole juurdepääsu blokeerimiseks kui halvasti läbimõeldud parooli taastamise funktsiooni abil.

Nõrk lüli

Kaitse osas on kõik ülaltoodud tähelepanekud suurepärased, kuid peate alati meeles pidama ekosüsteemi, mis ümbritseb teie kaitstavat kontot. Toome näiteks:

ASafaWeb majutab suurepärast teenust, mille pakub AppHarbor. Konto taastamise protsess toimub järgmiselt:

Etapp 1:

Etapp 2:

Etapp 3:

Etapp 4:

Pärast kogu eelneva teabe lugemist on juba lihtne mõista, milliseid aspekte ideaalsetes tingimustes me veidi teisiti rakendaksime. Kuid siin tahan öelda, et isegi kui avaldaksin saidi nagu ASafaWeb AppHarboris ning lõin suurepärased salajased küsimused ja vastused, lisasin teise autentimise teguri ja tegin kõik muu reeglite järgi, ei muuda see fakti, et kogu protsessi nõrk lüli suudab selle kõik ära rikkuda. Kui keegi suudab AppHarboris autentimise edukalt läbi viia, kasutades minu andmeid, suudab ta asendada ASafaWebi mis tahes konto parooli, mille ta soovib!

Oluline on, et kaitse rakendamise tugevust tuleks pidada tervikuks: on vaja modelleerida ohte igasüsteemi sisenemispunktist, isegi kui see on pinnapealne protsess, näiteks sisselogimine AppHarborisse. See peaks andma mulle hea ülevaate sellest, kui palju pingutust pean ASafaWebi parooli taastamise protsessi panustama.

Seome kõik kokku

See postitus sisaldab suurt hulka teavet, seega soovin seda lihtsasse visuaalsesse skeemisse kokku võtta:

Pidage meeles, et peaksite iga nende punktide kohta võimalikult põhjalikku logimist tegema. Nii et see ongi kõik, see on lihtne!

Summary

Minu postitus näib olevat ammendav, kuid on olemas palju täiendavaid materjale, mida ma saaksin kaasama, kuid otsustas sellest lühiduse nimel loobuda: hädapostituse e-posti aadressi roll, olukord, kus kaotate juurdepääsu kontoga seotud e-posti aadressile (näiteks olete lahkunud tööst) jne. Nagu ma mainisin, ei ole parooli lähtestamise funktsioon nii keeruline, kuid selle suhtes on mitmeid vaatenurki.

Kuigi lähtestamine ei ole nii keeruline, rakendatakse seda tihti valesti. Üks neist näidetest, mida me varem vaatasime, oli rakendamine võib võib põhjustada probleeme ja neid vale lähtestamise juhtumeid on palju rohkem. tõeliselt põhjustanud probleeme. Hiljuti selgus, et parooli lähtestamist kasutati 87 tuhat dollarit bitcoini varastamiseks.See on tõsine negatiivne tulemus!

Seega olge ettevaatlikud oma lähtestamisfunktsioonide suhtes, modelleerige ohte erinevates punktides ning ärge eemaldage oma musta mütsi, kui disainite funktsiooni, sest on suur tõenäosus, et keegi teine paneb selle pähe!

Reklaami õigustes

VDSina pakub odavaid servereid üürimiseks päevase tasuga, iga server on ühendatud 500 Mbit internetikanaliga ja tasuta kaitstud DDoS-rünnakute eest!

Allikas: habr.com