{"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 soovisite teada paroolide turvalisest l\u00e4htestamisest. Osa 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kaksifaktoriline autentimine<\/h2>\n

\nK\u00f5ik, mida olete lugenud esimeses osas<\/a><\/noindex> puudutas tuvastamist selle p\u00f5hjal, mida teab taotleja<\/em><\/strong>. Ta teab oma e-posti aadressi, teab, kuidas sellele juurde p\u00e4\u00e4seda (st teab oma e-posti parooli) ja teab saladusk\u00fcsimustele vastuseid. <\/p>\n

\u00abTeadmine\u00bb 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 iirised.<\/p>\n

\"K\u00f5ik,
\n<\/a><\/noindex>
\nEnamasti on bioloogilise tuvastamise rakendamine keeruline, eriti kui r\u00e4\u00e4gime veebirakenduste turvalisusest, seet\u00f5ttu kasutatakse kaksifaktorilisel autentimisel (two factor authentication, 2FA) tavaliselt teist attribuuti \u2014 \u00absee, mis teil on\u00bb. \u00dcks populaarne variant sellest teisest tegurist 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 rahandusteenustes. Teenuses autentimiseks tuleb kasutada nii parooli kui ka kodeeritud tokenit (mis tihti muutub) koos PIN-iga. Teoreetiliselt peab r\u00fcndaja isiku tuvastamiseks teadma parooli, omama tokenit ja teadma ka tokeni PIN-koodi. Parooli l\u00e4htestamise stsenaariumi puhul on parool ilmselgelt teadmata, kuid tokeni omamine v\u00f5ib kinnitada konto omamist. Loomulikult, nagu iga kaitse rakenduse puhul, see ei paku \"idiootide kaitset\"<\/a><\/noindex>, kuid kindlasti t\u00f5stab sisenemise takistust.<\/p>\n

\u00dcks peamisi selle l\u00e4henemise probleeme on hind ja rakenduse logistika; me r\u00e4\u00e4gime f\u00fc\u00fcsiliste seadmete edastamisest igale kliendile ja nende uue protsessiga tutvumisest. Lisaks peab kasutajal olema seade kaasas, mida f\u00fc\u00fcsilise tokeni puhul ei pruugi alati olla. Teine v\u00f5imalus on rakendada teine autentimise tegur SMS-i kaudu, mis 2FA korral v\u00f5ib kinnitada, et isik, kes protseduuri k\u00e4ivitab, omab konto omaniku mobiiltelefoni. Nii teeb seda Google:<\/p>\n

\"K\u00f5ik,
\nSamuti tuleb aktiveerida kaheastmeline autentimine<\/a><\/noindex>, kuid see t\u00e4hendab, et j\u00e4rgmise parooli l\u00e4htestamise korral v\u00f5ib teie mobiiltelefon saada teiseks autentimise teguriks. Las ma demonstreerin seda oma iPhone'i n\u00e4itel, p\u00f5hjuseid, mis varsti selguvad:<\/p>\n

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

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

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

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

\"K\u00f5ik,
\nParooli l\u00e4htestamise URL-i kasutamise korral 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 klassikalisse parooli l\u00e4htestamise protsessi:<\/p>\n

\"K\u00f5ik,
\nSee v\u00f5ib tunduda veidi keeruline, ja nii ongi, kuid vorm kinnitab, et parooli l\u00e4htestav isik p\u00e4\u00e4seb juurde nii e-posti aadressile kui ka konto omaniku mobiiltelefonile. Kuid see v\u00f5ib olla kuni \u00fcheksa korda turvalisem kui parooli l\u00e4htestamine ainult e-posti kaudu. Siiski on m\u00f5ned probleemid\u2026<\/p>\n

Probleem on seotud nutitelefonidega. Allpool n\u00e4idatud seade suudab kinnitada ainult \u00fchte autentimistegurit \u2013 see suudab saada SMS-e, kuid mitte e-kirju:<\/p>\n

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

\"K\u00f5ik,
\nProbleem on selles, et me peame e-posti esimeseks autentimise teguriks ja SMS-i (v\u00f5i isegi toote kasutusnime genereeriva rakenduse) teiseks, kuid t\u00e4na on need \u00fchendatud \u00fchte seadmesse. Loomulikult t\u00e4hendab see, et kui keegi p\u00e4\u00e4seb juurde teie nutitelefonile, siis k\u00f5ik see mugavus viib tagasi \u00fchte kanalisse; see teine faktor \u201emillega teil on\u201c t\u00e4hendab, et teil on ka esimene tegur. Ja k\u00f5ik see on kaitstud neljakohalise PIN-koodiga\u2026 kui telefonil \u00fcldse on PIN. ja<\/em> ta on lukustatud.<\/p>\n

Jah, Google'i rakendatud 2FA funktsioon pakub t\u00f5epoolest t\u00e4iendavat kaitset, kuid see ei kaitse \u201eidiotide\u201d eest ja kindlasti ei s\u00f5ltu see kahest t\u00e4iesti autonoomsest kanalist.<\/p>\n

Kasutajanime kaudu l\u00e4htestamine versus e-posti aadressi kaudu l\u00e4htestamine<\/h2>\n

\nKas on vaja lubada l\u00e4htestamine ainult e-posti aadressi kaudu? V\u00f5i peaks kasutaja olema v\u00f5imeline l\u00e4htestama ka kasutajanime kaudu? Probleem kasutajanime kaudu l\u00e4htestamisega on see, et ei ole mingit v\u00f5imalust kasutajat vale kasutajanime eest teavitada, ei paljastades<\/em> keegi teine v\u00f5ib sellise nimega konto omada. Eelnevas osas tagas e-posti kaudu l\u00e4htestamine, et seaduslik omanik saab alati tagasiotsingu ilma oma olemasolu s\u00fcsteemis avalikustamiseta. Ainult kasutajanimega seda teha ei saa.<\/p>\n

Seet\u00f5ttu on vastus l\u00fchike: ainult e-post. Kui proovite l\u00e4htestamist teha ainult kasutajanime abil, tekivad olukorrad, kus kasutaja ei saa aru, mis toimub. v\u00f5i<\/em> te paljastate kontode olemasolu. Jah, see on lihtsalt kasutajanimi, mitte e-posti aadress, ja jah, iga\u00fcks v\u00f5ib valida mistahes (saadaval) kasutajanime, kuid siiski on suur t\u00f5en\u00e4osus, et paljastate konto omanike identiteete, kuna kasutajatel on kalduvus kasutada sama nime mitu korda.<\/p>\n

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\u00e4htestamise algusele \u2014 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\u00e4htestamise URL-i. V\u00f5i siis on e-kirjas kirjas, et selle aadressiga ei ole kontot.<\/p>\n

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

\nParoolide l\u00e4htestamise v\u00f5tmek\u00fcsimus, ja t\u00f5en\u00e4oliselt isegi k\u00f5ige<\/em> v\u00f5tmek\u00fcsimus on selle isiku tuvastamine, kes p\u00fc\u00fcab l\u00e4htestamist sooritada. Kas see on t\u00f5eliselt konto seaduslik omanik v\u00f5i \u00fcritab keegi seda h\u00e4kkida v\u00f5i omanikule ebamugavust tekitada?<\/p>\n

Ilma leiab, et e-post on k\u00f5ige mugavam ja levinum isikutuvastamise kanal. See ei ole kaitstud oskamatute k\u00e4imiste eest (\u201enagu tolad\u201d), ja on palju juhuseid, kui lihtne v\u00f5imalus saada kirju konto omaniku aadressile ei piisa, kui n\u00f5utakse k\u00f5rget kindlustunnet identifitseerimises (seet\u00f5ttu kasutatakse ka 2FA). Kuid enamasti on see siiski protsessi taastamise alguspunkt.<\/p>\n

Kui e-post m\u00e4ngib rolli usaldusv\u00e4\u00e4rsuse tagamisel, tuleb k\u00f5igepealt veenduda, et e-posti aadress on t\u00f5eliselt korrektne. Kui keegi teeb vea s\u00fcmboliga, siis on ilmne, et taastamisprotsess ei alga. E-posti aadressi kontrollimise protsess registreerimise hetkel on usaldusv\u00e4\u00e4rne meetod aadressi \u00f5iguse kontrollimiseks. Oleme k\u00f5ik seda praktikas n\u00e4inud: teil on registreerimise ajal saadetud e-kiri ainulaadse URL-iga, millele tuleb vajutada, et kinnitada, et olete t\u00f5epoolest selle e-posti konto omanik. Sisse logimise vajaduse tagamine enne selle protsessi l\u00f5puleviimist tagab motivatsiooni aadressi kinnitamiseks.<\/p>\n

Nagu paljude teiste turvaelementide puhul, v\u00e4hendab see mudel kasutajakogemust, et tagada k\u00f5rgemat turvalisust seoses kasutaja identiteedi usaldusv\u00e4\u00e4rsusega. See v\u00f5ib olla vastuv\u00f5etav lehek\u00fcljel, mille registreerimist kasutaja k\u00f5rgelt hindab ja on valmis lisama veel \u00fche sammu protsessile (makseteenused, pangandust jne), kuid sellised asjad v\u00f5ivad kasutajat eemale t\u00f5rjuda, kui ta n\u00e4eb kontot \u2018\u00fchekordse\u2019 vahendina, n\u00e4iteks lihtsalt postituse kommenteerimiseks.<\/p>\n

Identifitseerimine, kes algatas l\u00e4htestamisprotsessi<\/h2>\n

\nOn ilmne, et l\u00e4htestamisfunktsiooni kuritarvitamiseks on p\u00f5hjuseid ja r\u00fcndajad v\u00f5ivad kasutada seda mitmeti. \u00dcks lihtne nipp, mida saame kasutada p\u00e4ringu allika kinnitamiseks (see nipp tavaliselt<\/em> toimib) \u2014 see on IP-aadressi lisamine l\u00e4htestamise pakkumise e-kirja. See varustab saajat m\u00f5ningase<\/em> teabega p\u00e4ringu allika tuvastamiseks.<\/p>\n

Siin on n\u00e4ide l\u00e4htestamisfunktsioonist, mida praegu ASafaWeb'i sisse integreerin:<\/p>\n

\"K\u00f5ik,
\nLink \u201efind out more\u201c (\u201eUuri l\u00e4hemalt\u201c) viib kasutaja saidile ip-adress.com<\/a><\/noindex>, mis edastab sellist teavet nagu asukoht ja korraldaja, kes taotleb parooli taastamist:<\/p>\n

\"K\u00f5ik,
\nMuidugi on igal, kes soovib oma isikup\u00e4ra varjata, palju viise oma tegeliku IP-aadressi peitmiseks, kuid see on mugav viis lisada osaline identifitseerimine taotlejale ning enamasti<\/em> annab see teile piisava \u00fclevaate sellest, kes taotleb parooli taastamist.<\/p>\n

Teade muudatustest e-posti teel<\/h2>\n

\nSee postitus on k\u00fcllastunud \u00fche teema \u2014 kommunikatsiooni; teavitage konto omanikku v\u00f5imalikult palju toimuvast igas protsessi etapis, paljastamata midagi, mida v\u00f5iks kasutada kuritarvitamiseks. Sama kehtib ka olukorra puhul, kui parool on tegelikult muutunud \u2014 teatage sellest omanikule!<\/em><\/strong><\/p>\n

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

    \n
  1. Parooli muutmine p\u00e4rast sisse logimist, kuna kasutaja soovib uut parooli<\/li>\n
  2. Parooli taastamine ilma sisse logimata, kuna kasutaja on selle unustanud<\/li>\n<\/ol>\n

    \nKuigi see postitus keskendub peamiselt passiivsete paroolide taastamisele, v\u00e4hendab esimesena saadud teavitus riski, et keegi muudab parooli ilma seadusliku omaniku teadmata. Kuidas see v\u00f5ib juhtuda? \u00dcks levinumaid stsenaariume on seadusliku omaniku parooli hankimine (taaskasutatud parool, mille on lekitanud m\u00f5ni teine allikas; parool, mille on saanud nuhkvara abil; kergesti arvatav parool jne), mille j\u00e4rel otsustavad kurjategijad selle muuta, blokeerides seel\u00e4bi omaniku. Ilma e-kirja teavitamata ei tea t\u00f5eline omanik parooli muutmisest.<\/p>\n

    Muidugi, parooli taastamise korral peab omanik juba olema protsessi ise algatanud (v\u00f5i \u00fcletama eespool kirjeldatud identiteedi kontrolli), seega muutmine kasutada swap-i \u00fcldse. Seega pole oluline, kus see asub. Me ei ela enam 95. aastal, ausalt \u00f6eldes!<\/em> ei tohiks teda \u00fcllatada, kuid e-kirja kinnitus on positiivne tagasiside ja t\u00e4iendav kontroll. Lisaks tagab see \u00fchtsuse eespool kirjeldatud stsenaariumiga.<\/p>\n

    Oh, ja juhuks, kui see pole veel ilmne \u2014 \u00e4rge saatke uut parooli e-postiga!<\/em><\/strong> M\u00f5ni v\u00f5ib sellest naerda, kuid sellised asjad juhtuvad<\/a><\/noindex>:<\/p>\n

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

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

    \nParooli taastamise funktsioon on ahvatlev kurjategijatele: r\u00fcndaja tahab kas saada ligip\u00e4\u00e4su teise inimese kontole v\u00f5i lihtsalt tekitada ebamugavusi konto\/s\u00fcsteemi omanikule. Paljud eespool kirjeldatud praktikad aitavad v\u00e4hendada kuritarvitamise t\u00f5en\u00e4osust, kuid ei takista seda t\u00e4ielikult ja nad ei takista kindlasti inimesi proovimast funktsiooni eba\u00f5igesti kasutada.<\/p>\n

    Kuritahtliku k\u00e4itumise tuvastamiseks on \u00e4\u00e4rmiselt v\u00e4\u00e4rtuslik praktika logimine, ja ma m\u00f5tlen v\u00e4ga detailsele logimisele<\/em><\/strong>. Salvestage eba\u00f5nnestunud sisselogimise katsed, paroolide l\u00e4htestamised, paroolide muutmised (st kui kasutaja on juba sisse logitud) ja praktiliselt k\u00f5ik, mis v\u00f5ib aidata teil m\u00f5ista, mis toimub; see osutub tulevikus v\u00e4ga kasulikuks. Salvestage logides isegi \u00fcksikud osad<\/em> protsessi, n\u00e4iteks hea l\u00e4htestamisfunktsioon peaks sisaldama l\u00e4htestamise algatamist veebisaidi kaudu (salvestage p\u00e4ringud ja sisselogimis\u00fcritused vale kasutajanime v\u00f5i e-posti aadressiga), salvestage veebisaidi k\u00fclastamine l\u00e4htestamise URL-i kaudu (sealhulgas vale tokeni kasutamise katsed) ja seej\u00e4rel logige vastuse edukust v\u00f5i eba\u00f5nnestumist salajasele k\u00fcsimusele.<\/p>\n

    Kui ma r\u00e4\u00e4gin logimisest, siis m\u00f5istan ma mitte ainult lehe laadimise fakti salvestamist, vaid ka v\u00f5imalikult palju teabe kogumist, kui see ei ole konfidentsiaalne.<\/em><\/strong>Poisid, palun \u00e4rge salvestage paroole logides!<\/em><\/strong> Logides tuleb registreerida autentitud kasutaja isik (ta on autentitud, kui ta muudab<\/em> olemasolevat parooli v\u00f5i p\u00fc\u00fcab l\u00e4htestada teise inimese parooli<\/em> p\u00e4rast s\u00fcsteemi sisselogimist), k\u00f5ik proovitud kasutajanimed v\u00f5i e-posti aadressid pluss k\u00f5ik l\u00e4htestamis-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) \u00fcritab teha, aga ka kes<\/em> ta on selline.<\/p>\n

    Vastutuse delegeerimine teistele t\u00e4itjatele<\/h2>\n

    \nKui arvate, et see k\u00f5ik on tohutu t\u00f6\u00f6, siis te ei ole \u00fcksi. Tegelikult on usaldusv\u00e4\u00e4rse konto haldamise s\u00fcsteemi \u00fclesehitamine keeruline \u00fclesanne. See ei seisne ainult tehnilistes raskustes, vaid sisaldab ka mitmeid erip\u00e4rasid. See h\u00f5lmab mitte ainult l\u00e4htestamist, vaid ka registreerimisprotsessi, paroolide turvalist salvestamist, mitmeid vale sisselogimise katseid jne. Kuigi ma propageerin valmiduse kasutamist nagu ASP.NET liikmesuse pakkuja<\/a><\/noindex>, tuleb teha palju muud.<\/p>\n

    T\u00e4nap\u00e4eval on olemas palju kolmandate osapoolte teenusepakkujaid, kes on valmis v\u00f5tma k\u00f5ik vaevad enda kanda ja abistama seda \u00fches hallatavates teenustes. Selliste teenuste hulka kuuluvad OpenID, OAuth ja isegi Facebook. M\u00f5ned inimesed uskumatult usuvad sellesse mudelisse<\/a><\/noindex> (OpenID osutus t\u00f5epoolest Stack Overflow'is v\u00e4ga edukaks), kuid teised peavad seda s\u00f5na otseses m\u00f5ttes \u00f5uduseks.<\/a><\/noindex>.<\/p>\n

    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\u00e4e autentimisteenuste pakkujate teenuste ulatuslikku kasutamist. Pangad, lennufirmad ja isegi poed \u2014 k\u00f5ik nad rakendavad oma autentimismehhanisme ja on ilmne, et sellel on v\u00e4ga tugevad p\u00f5hjused.<\/p>\n

    Halb kohe<\/h2>\n

    \nIga \u00fclaltoodud n\u00e4ite oluline aspekt on see, et vana parool loetakse kasutu ainult p\u00e4rast konto omaniku isiku tuvastamist<\/em><\/strong>. See on oluline, sest kui kontot saaks l\u00e4htestada kuni<\/em> ilma identifitseerimise kontrollita, siis looks see v\u00f5imalusi igasugustele pahatahtliketele tegevustele.<\/p>\n

    N\u00e4ide: keegi osaleb oksjoniveebisaidil ja oksjoni l\u00f5pus blokeerib ta konkurente, k\u00e4ivitades l\u00e4htestamisprotsessi, eemaldades need seel\u00e4bi oksjonilt. Ilmselgelt, kui kehvalt kavandatud l\u00e4htestusfunktsiooni saab v\u00e4\u00e4rkasutada, v\u00f5ib see viia t\u00f5siste negatiivsete tagaj\u00e4rgedeni. Tasub mainida, et kontode blokeerimine vale sisenemise katsete t\u00f5ttu on sarnane olukord, kuid see on juba teema teiseks postituseks.<\/p>\n

    Nagu ma eelnevalt mainisin, kui anda anon\u00fc\u00fcmsetele kasutajatele v\u00f5imalus l\u00e4htestada mis tahes konto parool, lihtsalt tema e-posti aadressi teades, on see ideaalne olukord teenuse keelamise r\u00fcnnaku jaoks. See ei pruugi olla see, millest me tavaliselt r\u00e4\u00e4gime, kuid ei ole kiiremat viisi konto juurdep\u00e4\u00e4su blokeerimiseks kui kehvalt l\u00e4bi m\u00f5eldud parooli l\u00e4htestamise funktsiooni abil. DoS<\/a><\/noindex>, millest me oleme harjunud r\u00e4\u00e4kima, kuid ei ole kiiremat viisi konto juurdep\u00e4\u00e4su blokeerimiseks kui kehvalt l\u00e4bi m\u00f5eldud parooli l\u00e4htestamise funktsiooni abil.<\/p>\n

    K\u00f5ige n\u00f5rgem l\u00fcli<\/h2>\n

    \nKonto kaitse seisukohalt on k\u00f5ik eelnev suurep\u00e4rane, kuid peate alati meeles pidama ka teie kaitstava konto \u00f6kos\u00fcsteemi. Lubage mul tuua n\u00e4ide:<\/p>\n

    ASafaWeb on majandatud suurep\u00e4rasel teenusel, mida pakub AppHarbor. Hostingu konto l\u00e4htestamise protsess toimub j\u00e4rgmiselt:<\/p>\n

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

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

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

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

    \"K\u00f5ik,
    \nKuna olen lugenud kogu eelnevat teavet, on n\u00fc\u00fcd lihtne m\u00f5ista, milliseid aspekte v\u00f5iksime ideaalsetes tingimustes pisut teisiti teostada. Siiski tahan \u00f6elda, et isegi kui avaldan sarnase saidi ASafaWeb AppHarboris, m\u00f5tlen v\u00e4lja suurep\u00e4rased salajased k\u00fcsimused ja vastused, lisan teise autentimise teguri ja teen k\u00f5ik muud asjad \u00f5igesti, ei t\u00fchista see t\u00f5siasja, et kogu protsessi n\u00f5rk link v\u00f5ib selle k\u00f5ik l\u00f5hkuda. Kui keegi suudab AppHarboris autentimise edukalt l\u00e4bi viia, kasutades minu andmeid, siis suudab ta ASafaWebi mis tahes konto parooli muuta soovitud parooliks!<\/p>\n

    Oluline on, et kaitse rakendamise vastupidavust tuleks vaadata tervikuna: tuleb modelleerida iga s\u00fcsteemi sisenemispunkti ohte, isegi kui see on pinnapealne protsess, n\u00e4iteks sisenemine AppHarborisse. See peaks andma mulle hea \u00fclevaate sellest, kui palju energiat pean investeerima ASafaWebi parooli l\u00e4htestamise protsessi.<\/p>\n

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

    \nSee post sisaldab suurt hulka teavet, seet\u00f5ttu tahan selle koondada lihtsasse visuaalsesse skeemi:<\/p>\n

    \"K\u00f5ik,
    \nPidage meeles, et peaksite registreerima igasuguse teabe v\u00f5imalikult \u00fcksikasjalikult. See ongi k\u00f5ik, see on lihtne!<\/p>\n

    Kokkuv\u00f5te<\/h2>\n

    \nMinu postitus tundub k\u00f5ikeh\u00f5lmav, kuid on palju t\u00e4iendavaid materjale, mida ma v\u00f5iks<\/em> soovisin lisada, kuid otsustasin l\u00fchiduse huvides sellest loobuda: p\u00e4\u00e4ste-e-posti aadressi roll, olukord, kus kaotad juurdep\u00e4\u00e4su oma konto k\u00fclge seotud e-posti (n\u00e4iteks kui oled t\u00f6\u00f6lt lahkunud), ja nii edasi. Nagu ma varem \u00fctlesin, pole l\u00e4htestamise funktsioon nii keeruline, lihtsalt on palju erinevaid vaatenurki sellele.<\/p>\n

    Isegi kui l\u00e4htestamine ei ole nii keeruline, tehakse seda tihti valesti. \u00dclalpool n\u00e4gime paar n\u00e4idet, kus kehv rakendamine suuteline<\/em> v\u00f5ib p\u00f5hjustada probleeme, ja on palju rohkem pretsedente, kus vale l\u00e4htestamine t\u00f5esti<\/em> p\u00f5hjustas probleeme. Hiljuti selgus, et l\u00e4htestamise funktsiooni kasutati 87 000 dollari v\u00e4\u00e4rtuses bitcoinide varastamiseks.<\/a><\/noindex>See on t\u00f5sine negatiivne tulemus!<\/p>\n

    Seet\u00f5ttu olge ettevaatlikud oma l\u00e4htestamise funktsioonide suhtes, modellige ohte.<\/a><\/noindex> erinevates punktides, ja funktsioonide kavandamisel \u00e4rge eemaldage oma musta m\u00fctsi, sest on suur t\u00f5en\u00e4osus, et keegi teine paneb selle p\u00e4he!<\/p>\n

    <\/p>\n

    Reklaami \u00f5igustes<\/h4>\n

    \nVDSina<\/b> pakub soodsaid servereid rendiks<\/a><\/noindex> p\u00e4evase maksmisega, iga server on \u00fchendatud 500 Mbit\/s internetikanaliga ja on 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 k\u00f5ik, mida soovisite teada turvalisest paroolide l\u00e4htestamisest. Osa 2 | ProHoster","description":"Kahefaktoriline autentimine K\u00f5ik, mida te esimeses osas lugesite, puudutas identifitseerimist selle alusel, mida k\u00fcsija teab. Ta teab oma e-posti aadressi, teab, kuidas sellele ligi p\u00e4\u00e4seda (st teab oma e-posti parooli) ja teab vastuseid salajastele k\u00fcsimustele. 'Teadmine' loetakse \u00fcheks autentimise teguriks; kaks muud levinud tegurit on see, et teil on","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 \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","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"},"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}]}}