{"id":97639,"date":"2020-10-20T02:42:56","date_gmt":"2020-10-20T00:42:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2"},"modified":"2020-10-20T02:42:56","modified_gmt":"2020-10-20T00:42:56","slug":"vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"K\u00f5ik, mida olete tahtnud teada paroolide turvalisest l\u00e4htestamisest. Osa 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kahefaktori autentimine<\/h2>\n

\nK\u00f5ik, mida olete lugenud esimeses osas<\/a><\/noindex> puudutab tuvastamist selle alusel, mida teab k\u00fcsija<\/em><\/strong>. Ta teab oma e-posti aadressi, teab, kuidas sellele juurde p\u00e4\u00e4seda (st teab oma e-posti parooli) ja teab salajaste k\u00fcsimuste vastuseid. <\/p>\n

\"Teadmine\" loetakse \u00fcheks autentimise teguriks; kaks muud levinud tegurit on see, mis teil on<\/em><\/strong>, n\u00e4iteks f\u00fc\u00fcsiline seade, ja see, kes te olete<\/em><\/strong>, n\u00e4iteks s\u00f5rmej\u00e4ljed v\u00f5i silma v\u00f5rkkest.<\/p>\n

\"K\u00f5ik,
\n<\/a><\/noindex>
\nEnamikul juhtudel on bioloogilise tuvastamise teostamine praktiliselt v\u00f5imatu, eriti kui r\u00e4\u00e4gime veebirakenduste turvalisusest, seet\u00f5ttu kasutatakse kahefaktorilises autentimises (two-factor authentication, 2FA) tavaliselt teist atribuuti \u2014 \"see, mis teil on\". \u00dcks populaarne teine tegur on f\u00fc\u00fcsiline token, n\u00e4iteks RSA SecurID<\/a><\/noindex>:<\/p>\n

\"K\u00f5ik,
\nF\u00fc\u00fcsilist tokenit kasutatakse sageli autentimiseks ettev\u00f5tte VPN-ides ja finantsteenustes. Autentimiseks on vajalik kasutada nii parooli kui ka tokenil olevaid koode (mis sageli muutuvad) koos PIN-koodiga. Teoreetiliselt peab r\u00fcndaja identifitseerimise jaoks teadma parooli, omama tokenit ja teadma ka tokeni PIN-koodi. Parooli l\u00e4htestamise stsenaariumis ei ole parool kindlasti teada, kuid tokeni omamine saab kasutada konto omandi kinnitamiseks. Muidugi, nagu iga kaitse rakendamise puhul, ei taga see \"lollikaitset\"<\/a><\/noindex>, kuid kindlasti t\u00f5stab sissep\u00e4\u00e4su takistust.<\/p>\n

\u00dcks peamisi selle l\u00e4henemise probleeme on rakendamise maksumus ja logistika; r\u00e4\u00e4gime f\u00fc\u00fcsiliste seadmete jagamisest igale kliendile ja nende uue protsessi \u00f5petamisest. Lisaks peavad kasutajad seadmeid endaga kaasas kandma, mis f\u00fc\u00fcsilise tokeni puhul ei pruugi alati nii olla. Veel \u00fcks variant on rakendada teist autentimistegurit SMS-i kaudu, mis 2FA puhul v\u00f5ib t\u00f5endada, et parooli l\u00e4htestamise protsessi teostav isik omab konto omaniku mobiiltelefoni. Nii teeb seda Google:<\/p>\n

\"K\u00f5ik,
\nSamuti tuleb lubada kahefaktoriline autentimine<\/a><\/noindex>, kuid see t\u00e4hendab, et j\u00e4rgmise parooli l\u00e4htestamise korral v\u00f5ib teie mobiiltelefon olla teine autentimise tegur. Las ma demonstreerin seda oma iPhone'i n\u00e4itel, p\u00f5hjused saavad peagi selgeks:<\/p>\n

\"K\u00f5ik,
\nP\u00e4rast Google'i konto e-posti aadressi tuvastamist selgub, et 2FA on lubatud ja saame konto l\u00e4htestada kinnitamisega, mis saadetakse SMS-iga konto omaniku mobiiltelefonile:<\/p>\n

\"K\u00f5ik,
\nN\u00fc\u00fcd peame valima l\u00e4htestamisprotsessi alguse:<\/p>\n

\"K\u00f5ik,
\nSee tegevus toob kaasa e-kirja saatmise registreeritud aadressile:<\/p>\n

\"K\u00f5ik,
\nSee kiri sisaldab l\u00e4htestamise URL-i:<\/p>\n

\"K\u00f5ik,
\nP\u00e4rast l\u00e4htestamise URL-i avamist saadetakse SMS ja veebisait palub selle sisestada:<\/p>\n

\"K\u00f5ik,
\nSiin on see SMS:<\/p>\n

\"K\u00f5ik,
\nP\u00e4rast selle sisestamist brauserisse naaseme klassikalise parooli l\u00e4htestamise territoriumi:<\/p>\n

\"K\u00f5ik,
\nT\u00f5en\u00e4oliselt tundub see veidi s\u00f5nas\u00f5naline, ja nii see ongi, kuid vorm kinnitab, et l\u00e4htestamise teostaja p\u00e4\u00e4seb ligi nii konto omaniku e-posti aadressile kui ka mobiiltelefonile. Kuid see v\u00f5ib olla kuni \u00fcheksa korda turvalisem kui parooli l\u00e4htestamine ainult e-posti kaudu. Kuid probleemid on siiski olemas...<\/p>\n

Probleemi juured on nutitelefonides. Allolev seade suudab kinnitada vaid \u00fchte autentimise tegurit \u2014 see suudab vastu v\u00f5tta SMS-e, kuid mitte e-kirju:<\/p>\n

\"K\u00f5ik,
\nKuid see seade suudab vastu v\u00f5tta SMS-e ja<\/em> vastu v\u00f5tta parooli l\u00e4htestamise kirju:<\/p>\n

\"K\u00f5ik,
\nProbleem on selles, et k\u00e4sitleme e-posti kui esimest autentimise tegurit ja SMS-i (v\u00f5i isegi tokenite genereerimise rakendust) kui teist, kuid t\u00e4nap\u00e4eval on need \u00fchendatud \u00fchte seadmesse. Loomulikult t\u00e4hendab see, et kui keegi p\u00e4\u00e4seb teie nutitelefonile ligi, siis k\u00f5ik see mugavus toob meid tagasi \u00fchte kanalisse; see teine tegur 'mida teil on' t\u00e4hendab, et teil on ka esimene tegur. Ja k\u00f5ik see on kaitstud neljanumbrilise PIN-iga... kui telefonil t\u00f5esti on PIN. ja<\/em> ta oli lukustatud.<\/p>\n

Jah, Google'i 2FA funktsioon pakub kindlasti lisakaitset, kuid see ei ole 'idioti' vastu kaitstud ja ei s\u00f5ltu kahest t\u00e4iesti isese from kanalist.<\/p>\n

Kasutajanime kaudu l\u00e4htestamine vs e-posti aadresse kaudu l\u00e4htestamine<\/h2>\n

\nKas on vajalik lubada parooli l\u00e4htestamine ainult e-posti aadressi kaudu? V\u00f5i peaks kasutajal olema v\u00f5imalus l\u00e4htestada see ka nime kaudu? Probleem nime kaudu l\u00e4htestamisel on see, et pole mingit v\u00f5imalust teavitada kasutajat vale nime olemasolust, \u00e4ra avades<\/em> et keegi teine v\u00f5ib omada kontot selle nimega. Eelmises osas tagas e-posti kaudu l\u00e4htestamine, et selle e-posti seaduslik omanik saab alati tagasisidet ilma avaliku teabe avalikustamiseta oma olemasolust s\u00fcsteemis. Ainult kasutajanime kaudu on seda v\u00f5imatu teha.<\/p>\n

Seega on vastus l\u00fchike: ainult e-post. Kui proovite l\u00e4htestada ainult kasutajanime kaudu, esineb olukordi, kus kasutaja j\u00e4\u00e4b segadusse, mis juhtus, v\u00f5i<\/em> te avaldate olemasolevate kontode olemasolu. Jah, see on lihtsalt kasutajanimi, mitte e-posti aadress, ja jah, iga\u00fcks v\u00f5ib valida mistahes (saadaval oleva) kasutajanime, kuid siiski on suur t\u00f5en\u00e4osus, et te avate kaudselt konto omanike identiteeti kasutajate kalduvuse t\u00f5ttu kasutada sama nime korduvalt.<\/p>\n

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\u00e4htestamise algusega - sisestame e-posti aadressi ja seej\u00e4rel saadame sellele aadressile teate, avalikustamata selle olemasolu. Ainus erinevus on see, et sel korral sisaldab teade ainult kasutajanime, mitte parooli l\u00e4htestamise URL-i. Kas see, v\u00f5i on e-kirjas m\u00e4rgitud, et selle aadressi jaoks ei ole kontot.<\/p>\n

Isiku tuvastamine ja e-posti aadresside t\u00e4psus<\/h2>\n

\nParoolide l\u00e4htestamise v\u00f5tmeaspekt, ja isegi t\u00f5en\u00e4oliselt k\u00f5ige<\/em> olulisem aspekt on isiku tuvastamine, kes \u00fcritab l\u00e4htestada. Kas see on t\u00f5epoolest konto seaduslik omanik, v\u00f5i \u00fcritab keegi seda h\u00e4kkida v\u00f5i tekitada omanikule ebamugavust?<\/p>\n

On selge, et e-post on k\u00f5ige lihtsam ja k\u00f5ige levinum isikukontrolli kanal. See ei ole kaitstud oskamatu k\u00e4itlemise eest (\u201elollilt\u201c), ja on palju juhtumeid, kus pelgalt v\u00f5imalus saada kirju konto omanikule ei ole piisav, kui n\u00f5utakse k\u00f5rge kindlustunde taset identifitseerimisel (seet\u00f5ttu kasutatakse ka 2FA), kuid peaaegu alati on see protsessi l\u00e4htestamise alguspunkt.<\/p>\n

Kui e-post m\u00e4ngib rolli t\u00f5hususe tagamisel, tuleb k\u00f5igepealt kindlaks teha, et e-posti aadress on t\u00f5epoolest \u00f5ige. Kui keegi eksib t\u00e4hestikus, ei alga l\u00e4htestamine selgelt. E-posti verifitseerimise protsess registreerimise hetkel on usaldusv\u00e4\u00e4rne meetod aadressi \u00f5igsuse kontrollimiseks. Oleme k\u00f5ik seda praktikas n\u00e4inud: registreerides saadetakse sulle e-kiri unikaalse URL-iga, millele vajutada, et kinnitada, et sa t\u00f5epoolest oled selle e-posti konto omanik. Sisse logimise v\u00f5imatus kuni selle protsessi l\u00f5petamiseni tagab motivatsiooni aadressi kinnitamiseks.<\/p>\n

Nagu paljude teiste turvakeerukuste puhul, v\u00e4hendab see mudel kasutatavust, et tagada suurem turvalisuse tase kasutaja identiteedi usaldusv\u00e4\u00e4rsuse suhtes. See v\u00f5ib olla vastuv\u00f5etav saidile, mille registreerimist kasutaja k\u00f5rgelt hindab ja lisab hea meelega veel \u00fche sammu protsessi (tasulised teenused, pangandust jne), kuid sellised asjad v\u00f5ivad kasutajat peletada, kui ta n\u00e4eb kontot \u201e\u00fchekordse\u201c vahendina, mida ta lihtsalt n\u00e4iteks postituse kommenteerimiseks kasutab.<\/p>\n

Tuletades meelde, kes algatas l\u00e4htestamisse protsessi<\/h2>\n

\nOn selge, et on p\u00f5hjuseid, miks l\u00e4htestamise funktsiooni v\u00f5ib kuritarvitada, ja kurjategijad v\u00f5ivad seda kasutada mitmeti. \u00dcks lihtne nipp, mida saame kasutada taotluse allika kinnitamisel (see nipp tavaliselt<\/em> toimib) \u2014 see on lisada l\u00e4htestamise pakkumise kirjale k\u00fclastaja IP-aadress. See annab saajale teatud<\/em> teavet taotluse allika tuvastamiseks.<\/p>\n

Siin on n\u00e4ide l\u00e4htestamisfunktsioonist, mida ma praegu ASafaWebi integreerin:<\/p>\n

\"K\u00f5ik,
\nLing lii \"find out more\" viib kasutaja veebisaidile ip-adress.com<\/a><\/noindex>, mis edastab sellist teavet nagu asukoht ja organisatsioon, kes taotles l\u00e4htestamist:<\/p>\n

\"K\u00f5ik,
\nMuidugi on igal, kes soovib oma identiteeti varjata, mitmeid meetodeid, et varjata oma t\u00f5elist IP-aadressi, kuid see on mugav viis lisada osalist identifitseerimist taotlejalt, ja enamikul<\/em> juhtudel annab see teile piisava \u00fclevaate, kes taotleb parooli l\u00e4htestamist.<\/p>\n

E-kirjaga muudatustest teavitamine<\/h2>\n

\nSee postitus on tungivalt seotud \u00fche teema \u2014 suhtlemisega; teavitage konto omanikku v\u00f5imalikult palju sellest, mis toimub iga etapi jooksul, paljastamata midagi, mida v\u00f5iks kuritahtlikult kasutada. Sama kehtib ka siis, kui parool on tegelikult muutunud \u2014 teavitage sellest omaniku!<\/em><\/strong><\/p>\n

Parooli muutmise p\u00f5hjuseks v\u00f5ivad olla kaks allikat:<\/p>\n

    \n
  1. Parooli muutmine sisse logimise j\u00e4rel, sest kasutaja soovib uut parooli<\/li>\n
  2. Parooli l\u00e4htestamine ilma sisse logimata, sest kasutaja on selle unustanud<\/li>\n<\/ol>\n

    \nKuigi see postitus k\u00e4sitleb peamiselt l\u00e4htestamist, v\u00e4hendab esimeses olukorras teavitamine riski, et keegi muudab parooli ilma seadusliku omaniku teadmiseta. Kuidas see v\u00f5ib juhtuda? V\u00e4ga levinud stsenaarium on seadusliku omaniku parooli saamine (taaskasutatud parool, mille on lekitanud teine allikas; parool, mille on saanud nuhkvara abil; kergesti \u00e4ra arvatav parool jne), mille j\u00e4rel r\u00fcndaja otsustab selle muuta, blokeerides seel\u00e4bi omaniku. Ilma e-kirja teavitamiseta ei tea t\u00f5eline omanik parooli muutmisest.<\/p>\n

    Muidugi peab parooli l\u00e4htestamise korral omanik juba ise algatama protsessi (v\u00f5i m\u00f6\u00f6duma eespool kirjeldatud tuvastamismeetmetest), seega ei tohi see<\/em> olla talle \u00fcllatuseks, kuid e-kirjaga kinnitamine oleks positiivne tagasiside ja t\u00e4iendav kontroll. Samuti tagab see \u00fchtsuse eespool kirjeldatud stsenaariumi.<\/p>\n

    Ja juhuks, kui see pole veel ilmne \u2014 \u00e4rge saatke uut parooli e-kirjaga!<\/em><\/strong> See v\u00f5ib kedagi naerda ajada, kuid selline juhtub<\/a><\/noindex>:<\/p>\n

    \"K\u00f5ik,<\/p>\n

    Logid, logid, logid ja veel m\u00f5ned logid<\/h2>\n

    \nParooli l\u00e4htestamise funktsioon on ahvatlev kurjategijatele: r\u00fcndaja soovib kas p\u00e4\u00e4seda kellegi teise kontole v\u00f5i lihtsalt p\u00f5hjustada vaeva konto\/s\u00fcsteemi omanikule. Paljud \u00fclaltoodud praktikatest aitavad v\u00e4hendada v\u00e4\u00e4rkasutamise t\u00f5en\u00e4osust, kuid ei takista seda t\u00e4ielikult ning need ei hoia inimesed tagasi proovima funktsiooni etten\u00e4htud viisil mitte kasutama.<\/p>\n

    Kahjuliku k\u00e4itumise tuvastamiseks on \u00e4\u00e4rmiselt v\u00e4\u00e4rtuslik praktika logimine, ja ma m\u00f5tlen v\u00e4ga detailsele logimisele<\/em><\/strong>. Dokumenteerige eba\u00f5nnestunud sisselogimisproovid, paroolide l\u00e4htestamised, paroolide muutmised (st kui kasutaja on juba sisse logitud) ja praktiliselt k\u00f5ik, mis v\u00f5ib teid aidata arusaamisel, mis toimub; see tuleb tulevikus v\u00e4ga kasuks. Logige isegi eraldi osad<\/em> protsessist, n\u00e4iteks hea parooli l\u00e4htestamise funktsioon peaks sisaldama l\u00e4htestamise algatamist veebilehe kaudu (logige sisestus ja sisselogimiskatsed vale kasutajanime v\u00f5i e-posti aadressiga), logige sisse veebilehte l\u00e4htestamise URL-iga (sealhulgas vale tokeni kasutamise katsed) ning seej\u00e4rel logige vastuse \u00f5igsus v\u00f5i vale vastus veebik\u00fcsimusele.<\/p>\n

    Kui ma r\u00e4\u00e4gin logimisest, siis ei t\u00e4henda ma ainult lehe laadimise fakti salvestamist, vaid ka v\u00f5imalikult palju teabe kogumist, kui see ei ole konfidentsiaalne<\/em><\/strong>. Poisid, palun \u00e4rge salvestage logides parooli!<\/em><\/strong> Logides tuleb registreerida autoriseeritud kasutaja identiteet (ta on autoriseeritud, kui ta muudab<\/em> olemasolevat parooli v\u00f5i p\u00fc\u00fcab l\u00e4htestada teise isiku parooli<\/em> p\u00e4rast sisselogimist), k\u00f5ik proovitud kasutajanime v\u00f5i e-posti aadressid ning k\u00f5ik l\u00e4htestamise tokenid, mida ta p\u00fc\u00fcab kasutada. Samuti tasub logida selliseid aspekte nagu IP-aadressid ja, kui v\u00f5imalik, isegi p\u00e4ringute p\u00e4ised. See v\u00f5imaldab teil rekonstrueerida mitte ainult mida<\/em> kasutaja (v\u00f5i r\u00fcndaja) p\u00fc\u00fcab teha, vaid ka kes<\/em> tema isik.<\/p>\n

    Kohustuste delegeerimine teistele teostajatele<\/h2>\n

    \nKui arvate, et see k\u00f5ik on tohutu t\u00f6\u00f6, siis te pole \u00fcksi. Tegelikult on usaldusv\u00e4\u00e4rse kontohalduse s\u00fcsteemi loomine keeruline \u00fclesanne. Asi ei ole ainult tehnilistes raskustes, vaid selles on mitmeid n\u00fcansse. See h\u00f5lmab mitte ainult parooli l\u00e4htestamist, vaid ka registreerimise protsessi, usaldusv\u00e4\u00e4rse paroolihalduse, mitmete vale sisselogimis\u00fcrituste t\u00f6\u00f6tlemise jms. Kuigi ma toetan valmis lahenduste, n\u00e4iteks ASP.NET membership provider'i kasutamist,<\/a><\/noindex>, on lisaks sellele veel palju muud teha.<\/p>\n

    T\u00e4nap\u00e4eval on palju kolmanda osapoole pakkujaid, kes v\u00f5tavad r\u00f5\u00f5muga k\u00f5ik vaevad enda kanda ja abstraheerivad selle \u00fche hallatava teenusena. Selliste teenuste hulka kuuluvad OpenID, OAuth ja isegi Facebook. M\u00f5ned inimesed usuvad piiramatu usuga sellesse mudelisse<\/a><\/noindex> (OpenID on t\u00f5epoolest osutunud v\u00e4ga edukaks Stack Overflow's), kuid teised peavad seda s\u00f5na otseses m\u00f5ttes \u00f5udusunen\u00e4oks.<\/a><\/noindex>.<\/p>\n

    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\u00e4e laialdast autentimist teenuste pakkujate teenuste kasutamist. Pangad, lennukompaniid ja isegi kauplused \u2013 k\u00f5ik nad rakendavad oma autentimismehhanismi, ja see on ilmne, et sellel on v\u00e4ga kaalukaid p\u00f5hjuseid.<\/p>\n

    Halvad parooli l\u00e4htestamised<\/h2>\n

    \nIga \u00fclaltoodud n\u00e4ite oluline aspekt on see, et vana parool loetakse kasutuks vaid p\u00e4rast konto omaniku tuvastamist.<\/em><\/strong>See on oluline, sest kui konto saaks l\u00e4htestada kuni<\/em> ilma identiteedi kinnitamiseta, siis see looks v\u00f5imalusi k\u00f5iksugu pahatahtlikeks tegevusteks.<\/p>\n

    Siin on n\u00e4ide: keegi osaleb oksjonisaidil ja oksjoniprotsessi l\u00f5pus blokeerib ta konkurente, algatades l\u00e4htestamisprotsessi, eemaldades seega nad oksjonilt. Ilmselgelt, kui halvasti kavandatud l\u00e4htestamisfunktsiooni saab kuritarvitada, v\u00f5ib see viia t\u00f5siste negatiivsete tagaj\u00e4rgedeni. Tasub t\u00e4hele panna, et kontode blokeerimine vale sisselogimise katsete kaudu on sarnane olukord, kuid see on juba teema teiseks postituseks.<\/p>\n

    Nagu ma \u00fctlesin, kui anda anon\u00fc\u00fcmsetele kasutajatele v\u00f5imalus taastada parool igale kontole, teades lihtsalt selle e-posti aadressi, siis on see ideaalne v\u00f5imalus teenuse katkestamise r\u00fcnnaku jaoks. See ei pruugi olla see DoS<\/a><\/noindex>, millest me tavaliselt r\u00e4\u00e4gime, kuid pole kiiremat viisi kontole juurdep\u00e4\u00e4su blokeerimiseks kui halvasti l\u00e4bim\u00f5eldud parooli taastamise funktsiooni abil.<\/p>\n

    N\u00f5rk l\u00fcli<\/h2>\n

    \nKaitse osas on k\u00f5ik \u00fclaltoodud t\u00e4helepanekud suurep\u00e4rased, kuid peate alati meeles pidama ekos\u00fcsteemi, mis \u00fcmbritseb teie kaitstavat kontot. Toome n\u00e4iteks:<\/p>\n

    ASafaWeb majutab suurep\u00e4rast teenust, mille pakub AppHarbor. Konto taastamise protsess toimub j\u00e4rgmiselt:<\/p>\n

    Etapp 1:<\/strong><\/p>\n

    \"K\u00f5ik,
    \nEtapp 2:<\/strong><\/p>\n

    \"K\u00f5ik,
    \nEtapp 3:<\/strong><\/p>\n

    \"K\u00f5ik,
    \nEtapp 4:<\/strong><\/p>\n

    \"K\u00f5ik,
    \nP\u00e4rast kogu eelneva teabe lugemist on juba lihtne m\u00f5ista, milliseid aspekte ideaalsetes tingimustes me veidi teisiti rakendaksime. Kuid siin tahan \u00f6elda, et isegi kui avaldaksin saidi nagu ASafaWeb AppHarboris ning l\u00f5in suurep\u00e4rased salajased k\u00fcsimused ja vastused, lisasin teise autentimise teguri ja tegin k\u00f5ik muu reeglite j\u00e4rgi, ei muuda see fakti, et kogu protsessi n\u00f5rk l\u00fcli suudab selle k\u00f5ik \u00e4ra rikkuda. Kui keegi suudab AppHarboris autentimise edukalt l\u00e4bi viia, kasutades minu andmeid, suudab ta asendada ASafaWebi mis tahes konto parooli, mille ta soovib!<\/p>\n

    Oluline on, et kaitse rakendamise tugevust tuleks pidada tervikuks: on vaja modelleerida ohte igas\u00fcsteemi sisenemispunktist, isegi kui see on pinnapealne protsess, n\u00e4iteks sisselogimine AppHarborisse. See peaks andma mulle hea \u00fclevaate sellest, kui palju pingutust pean ASafaWebi parooli taastamise protsessi panustama.<\/p>\n

    Seome k\u00f5ik kokku<\/h2>\n

    \nSee postitus sisaldab suurt hulka teavet, seega soovin seda lihtsasse visuaalsesse skeemisse kokku v\u00f5tta:<\/p>\n

    \"K\u00f5ik,
    \nPidage meeles, et peaksite iga nende punktide kohta v\u00f5imalikult p\u00f5hjalikku logimist tegema. Nii et see ongi k\u00f5ik, see on lihtne!<\/p>\n

    Summary<\/h2>\n

    \nMinu postitus n\u00e4ib olevat ammendav, kuid on olemas palju t\u00e4iendavaid materjale, mida ma saaksin<\/em> kaasama, kuid otsustas sellest l\u00fchiduse nimel loobuda: h\u00e4dapostituse e-posti aadressi roll, olukord, kus kaotate juurdep\u00e4\u00e4su kontoga seotud e-posti aadressile (n\u00e4iteks olete lahkunud t\u00f6\u00f6st) jne. Nagu ma mainisin, ei ole parooli l\u00e4htestamise funktsioon nii keeruline, kuid selle suhtes on mitmeid vaatenurki.<\/p>\n

    Kuigi l\u00e4htestamine ei ole nii keeruline, rakendatakse seda tihti valesti. \u00dcks neist n\u00e4idetest, mida me varem vaatasime, oli rakendamine v\u00f5ib<\/em> v\u00f5ib p\u00f5hjustada probleeme ja neid vale l\u00e4htestamise juhtumeid on palju rohkem. t\u00f5eliselt<\/em> p\u00f5hjustanud probleeme. Hiljuti selgus, et parooli l\u00e4htestamist kasutati 87 tuhat dollarit bitcoini varastamiseks.<\/a><\/noindex>See on t\u00f5sine negatiivne tulemus!<\/p>\n

    Seega olge ettevaatlikud oma l\u00e4htestamisfunktsioonide suhtes, modelleerige ohte<\/a><\/noindex> erinevates punktides ning \u00e4rge eemaldage oma musta m\u00fctsi, kui disainite funktsiooni, sest on suur t\u00f5en\u00e4osus, et keegi teine paneb selle p\u00e4he!<\/p>\n

    <\/p>\n

    Reklaami \u00f5igustes<\/h4>\n

    \nVDSina<\/b> pakub odavaid servereid \u00fc\u00fcrimiseks<\/a><\/noindex> p\u00e4evase tasuga, iga server on \u00fchendatud 500 Mbit internetikanaliga ja tasuta kaitstud DDoS-r\u00fcnnakute eest!<\/p>\n

    \"K\u00f5ik,<\/a><\/noindex>
    \n
    Allikas:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e \u0437\u043d\u0430\u0435\u0442 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u044e\u0449\u0438\u0439. \u041e\u043d \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b, \u0437\u043d\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a \u043d\u0435\u0439 \u0434\u043e\u0441\u0442\u0443\u043f (\u0442.\u0435. \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u043f\u0430\u0440\u043e\u043b\u044c \u043e\u0442 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b) \u0438 \u0437\u043d\u0430\u0435\u0442 \u043e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u00ab\u0417\u043d\u0430\u043d\u0438\u0435\u00bb \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0438\u043c \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438; \u0434\u0432\u0443\u043c\u044f \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0451\u043d\u043d\u044b\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u0442\u043e, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97640,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97639","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47K\u00f5ik, mida soovisite teada turvalisest paroolide l\u00e4htestamisest. Osa 2 | ProHoster","description":"Kaksfaktoriline autentimine K\u00f5ik, mida te lugesite esimeses osas, puudutas identifitseerimist selle p\u00f5hjal, mida.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0441\u0451, \u0447\u0442\u043e \u0432\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u0437\u043d\u0430\u0442\u044c \u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u043c \u0441\u0431\u0440\u043e\u0441\u0435 \u043f\u0430\u0440\u043e\u043b\u0435\u0439. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0414\u0432\u0443\u0445\u0444\u0430\u043a\u0442\u043e\u0440\u0430\u044f \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u0412\u0441\u0451 \u043f\u0440\u043e\u0447\u0438\u0442\u0430\u043d\u043d\u043e\u0435 \u0432\u0430\u043c\u0438 \u0432 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u043a\u0430\u0441\u0430\u043b\u043e\u0441\u044c \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0442\u043e\u0433\u043e, \u0447\u0442\u043e.","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T00:42:56+00:00","article:modified_time":"2020-10-20T00:42:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97639","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:16:25","updated":"2022-10-03 07:14:42","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}