Twa-faktor autentikaasje
Alles wat jo yn lêze oanbelangjende identifikaasje op basis dat de oanfreger wit. Hy wit syn e-mailadres, hy wit hoe't er tagong krije kin (dat wol sizze, hy wit syn e-postwachtwurd), en hy wit de antwurden op syn feiligensfragen.
"Kennis" wurdt beskôge as ien autentikaasjefaktor; twa oare mienskiplike faktoaren binne wat jo hawwe, lykas in fysyk apparaat, en wa'sto bist, bygelyks, fingerprints of retina.
Yn 'e measte gefallen is it útfieren fan biologyske identifikaasje net mooglik, foaral as wy it hawwe oer webapplikaasjefeiligens, dus twa-faktor-ferifikaasje (2FA) brûkt normaal it twadde attribút - "wat jo hawwe". Ien populêre fariaasje fan dizze twadde faktor is in fysike token, bgl. :
It fysike token wurdt faak brûkt foar autentikaasje yn bedriuws-VPN's en finansjele tsjinsten. Om te ferifiearjen mei de tsjinst moatte jo sawol in wachtwurd as in koade brûke op it token (dy't faak feroaret) yn kombinaasje mei in PIN. Teoretysk, foar identifikaasje, moat in oanfaller it wachtwurd witte, in token hawwe, en ek de PIN fan it token witte. Yn in senario foar reset fan wachtwurden is it wachtwurd sels fansels ûnbekend, mar it besit fan it token kin brûkt wurde om it eigendom fan it akkount te bewizen. Fansels, lykas by elke ymplemintaasje fan feiligens, , mar perfoarst ferheget de barriêre foar yngong.
Ien fan 'e wichtichste problemen mei dizze oanpak is de kosten en logistyk fan útfiering; wy prate oer it oerjaan fan fysike apparaten oan elke klant en it learen fan har it nije proses. Derneist moatte brûkers it apparaat by har hawwe, wat net altyd it gefal is mei in fysike token. In oare opsje is om in twadde faktor fan autentikaasje te ymplementearjen mei SMS, dy't yn it gefal fan 2FA kin tsjinje as befêstiging dat de persoan dy't it resetproses útfiert, de mobile tillefoan fan 'e accounteigner hat. Hjir is hoe't Google it docht:
Jo moatte ek ynskeakelje , mar dit betsjut dat de folgjende kear as jo jo wachtwurd weromsette, jo mobile tillefoan in twadde autentikaasjefaktor wurde kin. Lit my dit demonstrearje mei myn iPhone om redenen dy't gau dúdlik wurde:
Nei it identifisearjen fan it e-postadres fan it akkount, bepaalt Google dat 2FA is ynskeakele en kinne wy it akkount weromsette mei ferifikaasje, dy't fia SMS wurdt stjoerd nei de mobile tillefoan fan 'e akkounteigner:
No moatte wy kieze om it resetproses te begjinnen:
Dizze aksje soarget derfoar dat in e-post ferstjoerd wurdt nei it registrearre adres:
Dizze e-post befettet de reset-URL:
As jo tagong krije ta de reset-URL, wurdt in SMS ferstjoerd en de webside freget jo om it yn te fieren:
Dit is de SMS:
Nei it ynfieren fan it yn 'e browser, binne wy werom yn it klassike territoarium foar reset fan wachtwurd:
Dit nei alle gedachten liket in bytsje lange-winded, en it is, mar it formulier befêstiget dat de persoan dy't docht de reset hat tagong ta it akkount eigner fan e-mailadres en mobile telefoan. Mar it kin njoggen kear feiliger wêze as jo wachtwurd allinich fia e-post weromsette. D'r binne lykwols problemen ...
It probleem is relatearre oan smartphones. It hjirûnder werjûn apparaat kin allinich ferifiearje mei ien faktor fan autentikaasje - it is yn steat om SMS te ûntfangen, mar gjin e-post:
Dit apparaat kin lykwols SMS ûntfange и e-mails foar weromsette wachtwurd ûntfange:
It probleem is dat wy e-post sjogge as de earste faktor fan autentikaasje en SMS (of sels in token-generearjende app) as de twadde, mar hjoed binne se kombineare yn ien apparaat. Fansels, dit betsjut dat as immen krijt syn hannen op jo smartphone, al dit gemak wurdt werombrocht ta it feit dat wy binne werom nei ien kanaal wer; dizze twadde faktor "dit, dat jo hawwe" betsjut dat jo ek hawwe de earste faktor. En dit alles wurdt beskerme troch ien fjouwer-sifers PIN ... as de telefoan hat sels in PIN и hy waard blokkearre.
Ja, de 2FA-funksje ymplementearre troch Google leveret grif ekstra beskerming, mar it is net foolproof, en it is wis net ôfhinklik fan twa folslein autonome kanalen.
Weromsette troch brûkersnamme vs weromsette troch e-postadres
Moat ik allinich weromsette per e-mailadres tastean? Of moat de brûker ek op namme weromsette kinne? It probleem mei weromsette troch brûkersnamme is dat d'r gjin manier is om de brûker te melden dat de brûkersnamme ferkeard is. sûnder iepenbiering dat immen oars in akkount mei dizze namme hawwe kin. Yn 'e foarige seksje soarge in e-postreset derfoar dat de rjochtmjittige eigner fan dy e-post altyd feedback soe ûntfange sûnder it bestean yn it systeem iepenbier te iepenbierjen. Dit kin net dien wurde mei allinich de brûkersnamme.
Dus it antwurd is koart: allinich e-post. As jo besykje in reset út te fieren mei allinich de brûkersnamme, sille d'r gefallen wêze wêr't de brûker him ôffreegje sil wat der bard is, of jo sille it bestean fan akkounts iepenbierje. Ja, it is gewoan in brûkersnamme, gjin e-mailadres, en ja, elkenien kin elke (beskikbere) brûkersnamme kieze, mar d'r is noch altyd in grutte kâns dat jo yndirekt de eigners fan akkounts iepenbierje fanwegen de oanstriid fan brûkers om nammen opnij te brûken.
Dus wat bart der as immen har brûkersnamme ferjit? Oannommen dat de brûkersnamme net daliks in e-mailadres is (wat faaks it gefal is), is it proses fergelykber mei hoe't in wachtwurd weromsette begjint - in e-mailadres ynfiere, en dan in berjocht nei dat adres ferstjoere sûnder it bestean te iepenbierjen. It ienige ferskil is dat dizze kear it berjocht allinich de brûkersnamme befettet en net de wachtwurd weromsette URL. Of dat, of de e-post sil sizze dat d'r gjin akkount is foar dit adres.
Identiteitsferifikaasje en krektens fan e-mailadres
In wichtich aspekt fan wachtwurd weromsette, en miskien sels it meast it wichtichste aspekt is it ferifiearjen fan de identiteit fan 'e persoan dy't de reset besykje. Is dit eins de legitime eigner fan it akkount, of is immen besiket te hack it of oerlêst de eigner?
Fansels is e-post it handichste en meast foarkommende kanaal foar identiteitsferifikaasje. It is net foolproof, en d'r binne in protte gefallen wêr't gewoan e-mails kinne ûntfange nei it adres fan 'e accounteigner net genôch is as in hege graad fan fertrouwen yn identifikaasje fereaske is (wêrtroch 2FA wurdt brûkt), mar it is hast altyd de begjinpunt reset proses.
As e-post in rol sil spylje by it jaan fan garânsje, is de earste stap om te soargjen dat it e-mailadres yn feite korrekt is. As immen it ferkearde symboal makke, dan sil fansels de reset net begjinne. It e-postferifikaasjeproses op it momint fan registraasje is in betroubere manier om de krektens fan it adres te ferifiearjen. Wy hawwe it allegear yn 'e praktyk sjoen: jo oanmelde, se stjoere jo in e-post mei in unike URL wêrop jo klikke, dy't befêstiget dat jo yndie de eigner binne fan dat e-postakkount. Net ynlogge kinne oant dit proses foltôge is, soarget derfoar dat jo motivearre binne om jo adres te ferifiearjen.
Lykas by in protte oare aspekten fan feiligens, kompromittearret dit model de brûkberens yn ruil foar it leverjen fan ferhege feiligens relatyf oan fertrouwen yn 'e identiteit fan' e brûker. Dit kin akseptabel wêze foar in side wêr't de brûker registraasje heech wurdearret en lokkich in oare stap yn it proses soe tafoegje (betelle tsjinsten, bankieren, ensfh.), Mar sokke dingen kinne de brûker útsette as hy it akkount as "wegwerpber" sjocht ” en brûkt , bygelyks, gewoan as in middel om te kommentearjen op in berjocht.
Identifisearje wa't it resetproses begon
Fansels binne d'r redenen foar kwea-aardich gebrûk fan 'e resetfunksje, en oanfallers kinne it op in protte ferskillende manieren brûke. Ien ienfâldige trúk dy't wy kinne brûke om de oarsprong fan in fersyk te ferifiearjen (dizze trúk meastentiids wurket) - dit wurdt tafoege oan in briefoanbod om it IP-adres fan de oanfreger te resetten. It leveret de ûntfanger guon ynformaasje om de boarne fan it fersyk te identifisearjen.
Hjir is in foarbyld fan 'e resetfunksje dy't ik op it stuit yn ASafaWeb bouwe:
De keppeling "Mear te finen" bringt de brûker nei de side , it rapportearjen fan ynformaasje lykas de lokaasje en organisaasje fan de reset-oanfreger:
Fansels hat elkenien dy't har identiteit wol ferbergje in protte manieren om har echte IP-adres te ferbergjen, mar dit is in handige manier om in part identifikaasje fan 'e oanfreger ta te foegjen, en measte gefallen sil dit jo in goed idee jaan fan wa't it fersyk foar reset fan wachtwurd sil foltôgje.
Notifikaasje fan feroaringen fia e-post
Dizze post is trochjûn mei ien tema - kommunikaasje; Fertel de accounteigner safolle mooglik oer wat der bart yn elke faze fan it proses, sûnder wat te iepenbierjen dat kwea-aardich brûkt wurde koe. Itselde jildt foar de situaasje wêr't it wachtwurd feitlik feroare is - meld dit oan de eigner!
D'r kinne twa redenen wêze foar it feroarjen fan it wachtwurd:
- Wachtwurd wizigje nei oanmelden om't brûker nij wachtwurd wol
- In wachtwurd weromsette sûnder oan te melden om't de brûker it fergetten is
Hoewol dit berjocht yn 't foarste plak giet oer it resetten, fermindert it ynformearjen fan 'e eardere it risiko dat immen it wachtwurd feroaret sûnder de kennis fan 'e rjochtmjittige eigner. Hoe kin dit barre? In hiel gewoan senario is dat it wachtwurd fan 'e rjochtmjittige eigner wurdt krigen (in werbrûkt wachtwurd dat út in oare boarne lekt is, in keylogged wachtwurd, in maklik te rieden wachtwurd, ensfh.) en dan beslút de oanfaller it te feroarjen, sadat de eigner útsletten wurdt. . Sûnder e-postnotifikaasje sil de echte eigner net witte oer de wiziging fan it wachtwurd.
Fansels, yn it gefal fan in wachtwurd weromsette, soe de eigner it proses sels al inisjearre hawwe (of de hjirboppe beskreaune identifikaasjecheckers omgean), sadat de feroaring soe net moatte kin in ferrassing foar him, mar in e-mail befêstiging sil wêze positive feedback en ekstra ferifikaasje. It leveret ek konsistinsje mei it boppesteande senario.
Oh, en as it net al dúdlik wie - Stjoer gjin nij wachtwurd per post! Dit kin guon minsken laitsje, mar :
Logs, logs, logs en wat mear logs
De funksje foar reset fan wachtwurden is oantreklik foar oanfallers: de oanfaller wol tagong krije ta it akkount fan in oare persoan, of gewoan oerlêst feroarsaakje foar de akkount/systeemeigner. In protte fan 'e hjirboppe beskreaune praktiken ferminderje de kâns op misbrûk, mar foarkomme it net, en se sille grif net foarkomme dat minsken besykje de funksje op ûnbedoelde manieren te brûken.
Om kwea-aardich gedrach te erkennen, is logging in absolút ûnskatbere praktyk, en ik bedoel tige detaillearre logging. Opnimme mislearre oanmeldpogingen, wachtwurd weromsette, wachtwurdwizigingen (dus as de brûker al oanmeld is) en hast alles dat jo helpe kin te begripen wat der bart; dit sil heul nuttich wêze yn 'e takomst. Log sels yndividueel dielen proses, bygelyks, in goede reset funksje moat omfetsje it inisjearjen fan in reset fia in webside (fange de reset fersyk en oanmeldpogingen mei in ferkearde brûkersnamme of e-post), capture webside besites oan de reset URL (ynklusyf besykjen om te brûken in ferkearde token), en log dan it sukses of mislearjen fan it antwurd op de feiligensfraach.
As ik praat oer logging, bedoel ik net allinich it feit dat in side wurdt laden, mar ek safolle mooglik ynformaasje sammelje, as it net fertroulik is. Jongens, skriuw asjebleaft gjin wachtwurden yn 'e logs! De logs moatte de identiteit fan 'e autorisearre brûker opnimme (hy sil autorisearre wurde as hy feroaringen besteande wachtwurd of besykje te resetten in oar syn wachtwurd nei it oanmelden), alle brûkersnammen of e-mailadressen dy't it besiket plus alle reset-tokens dy't it besiket. Mar it is ek de muoite wurdich om dingen lykas IP-adressen oan te melden en, as it mooglik is, sels kopteksten oan te freegjen. Hjirmei kinne jo net allinich opnij oanmeitsje dat de brûker (of oanfaller) besiket te dwaan, mar ek wa hy is sa'n.
Delegaasje fan ferantwurdlikens oan oare performers
As jo tinke dat dit allegear in enoarme hoemannichte wurk fertsjintwurdiget, binne jo net allinich. Yn feite is it bouwen fan in betrouber accountbehearsysteem gjin maklike taak. It is net dat it technysk lestich is, it hat gewoan in protte funksjes. It giet net allinich om weromsette, d'r is in folslein registraasjeproses, wachtwurden feilich opslaan, meardere mislearre oanmeldpogingen behannelje, ensfh., ensfh. Alhoewol , boppedat moat noch folle mear dien wurde.
Tsjintwurdich binne d'r in protte oanbieders fan tredden bliid om alle pine op te nimmen en it allegear te abstraheren yn ien beheare tsjinst. Sokke tsjinsten omfetsje OpenID, OAuth en sels Facebook. Guon minsken (OpenID hat yndie heul suksesfol west op Stack Overflow), mar oaren .
D'r is gjin twifel dat in tsjinst lykas OpenID in protte problemen oplost foar ûntwikkelders, mar it foeget sûnder mis ek nije ta. Hawwe se in rol? Ja, mar fansels sjogge wy gjin massale oanname fan providers fan autentikaasjetsjinsten. Banken, loftfeartmaatskippijen en sels winkels implementearje allegear har eigen autentikaasjemeganisme, en d'r binne fansels heul goede redenen foar dit.
Malicious reset
In wichtich aspekt fan elk fan 'e foarbylden hjirboppe is dat it âlde wachtwurd allinich as nutteloos beskôge wurdt nei it befêstigjen fan de identiteit fan 'e akkount eigner. Dit is wichtich, want as it akkount koe wurde reset до identifikaasje ferifikaasje, dit soe biede de mooglikheid foar alle soarten fan kweade aksjes.
Hjir is in foarbyld: immen biedt op in feilingside, en tichtby it ein fan it biedingsproses blokkearje se de konkurrinten troch in resetproses te begjinnen, en eliminearje se sa fan 'e biedingen. Fansels, as in min ûntworpen resetfunksje kin wurde misbrûkt, kin it liede ta serieuze negative resultaten. It is de muoite wurdich op te merken dat account lockouts fanwege ûnjildige oanmeldpogingen in ferlykbere situaasje binne, mar dat is in ûnderwerp foar in oare post.
Lykas ik hjirboppe sei, as jo anonime brûkers de mooglikheid jouwe om it wachtwurd fan elk akkount werom te setten troch gewoan har e-mailadres te kennen, dan is dit in ripe situaasje foar in denial-of-service-oanfal. Dit kin net de iene .
De swakste skeakel
Ut it eachpunt fan it beskermjen fan in inkeld akkount is alles hjirboppe skreaun geweldich, mar jo moatte altyd bewust wêze fan it ekosysteem om it akkount dat jo beskermje. Lit my dy in foarbyld jaan:
ASafaWeb wurdt host op in geweldige tsjinst levere troch AppHarbor. It proses fan it resetten fan in hosting-akkount giet sa:
Fase 1:
Fase 2:
Fase 3:
Fase 4:
Nei it lêzen fan alle foargeande ynformaasje is it al maklik te begripen hokker aspekten yn in ideale wrâld wy in bytsje oars sille útfiere. Wat ik hjir lykwols sis is dat as ik in side lykas ASafaWeb publisearje op AppHarbor, en dan mei geweldige befeiligingsfragen en antwurden kom, in twadde autentikaasjefaktor tafoegje en al it oare dwaan neffens de regels, dan feroaret dit net it feit dat de swakste skeakel yn it hiele proses by steat wêze sil om it allegear te brekken. As immen mei súkses autentisearret yn AppHarbor mei myn ynformaasje, dan kinne se it wachtwurd foar elk ASafaWeb-akkount feroarje nei dejinge dy't se nedich binne!
It punt is dat de sterkte fan in befeiligingsimplementaasje holistysk beskôge wurde moat: de bedriging fan elk yngongspunt yn it systeem moat modeleare wurde, sels as it in oerflakkich proses is, lykas ynlogge yn it AppHarbor-systeem. Dit soe my in goed idee jaan moatte fan hoefolle muoite ik moat stekke yn it proses foar reset fan ASafaWeb-wachtwurd.
It alles byinoar sette
Dizze post befettet in protte ynformaasje, dus ik wol it kondinsearje yn in ienfâldige fisuele skets:
Unthâld in log sa detaillearre mooglik foar elk fan dizze items. Dat is it, it is ienfâldich!
Resultaten
Myn post liket wiidweidich te wêzen, lykwols is d'r in protte ekstra materiaal dat ik koe befetsje mar besletten net om 'e wille fan' e koarte: de rol fan in rêding e-mailadres, de situaasje wêryn jo ferlieze tagong ta de e-mail ferbûn mei jo akkount (Bygelyks, jo quit dyn baan), ensafuorthinne. Lykas ik earder sei, is de resetfunksje net sa yngewikkeld, mar d'r binne in protte manieren om it te sjen.
Ek al is de reset net sa yngewikkeld, wurdt it faak ferkeard ymplementearre. Hjirboppe seagen wy in pear foarbylden doe't de ymplemintaasje kin liede ta problemen, en der binne folle mear precedinten dêr't in ferkearde reset echt problemen feroarsake. Koartlyn die bliken dat . Dit is in serieus negatyf resultaat!
Dus wês foarsichtich mei jo resetfunksjes, op ferskate punten, en by it ûntwerpen fan in funksje, net nimme út dyn swarte hoed, want der is in goede chance in oar sil sette it op!
Oer de rjochten fan 'e advertinsje
VDSina biedt goedkeap mei deistige betelling is elke tsjinner ferbûn mei in ynternetkanaal fan 500 Megabits en wurdt fergees beskerme tsjin DDoS-oanfallen!
Boarne: www.habr.com