{"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\/hr\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Sve \u0161to ste \u017eeljeli znati o sigurnom resetiranju lozinki. Dio 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Dvofaktorska autentifikacija<\/h2>\n

\nSve \u0161to ste pro\u010ditali u prvom delu<\/a><\/noindex> vezano je uz identifikaciju na osnovu onoga \u0161to zna osoba koja tra\u017ei<\/em><\/strong>. Ona zna svoju adresu e-po\u0161te, zna kako do\u0107i do nje (tj. zna svoju lozinku za e-po\u0161tu) i zna odgovore na tajna pitanja. <\/p>\n

\"Znanje\" se smatra jednim od faktora autentifikacije; dva druga uobi\u010dajena faktora su ono \u0161to imate<\/em><\/strong>, na primjer, fizi\u010dki ure\u0111aj, i ono tko ste<\/em><\/strong>, na primjer, otisci prstiju ili mre\u017enica oka.<\/p>\n

\"Sve
\n<\/a><\/noindex>
\nU ve\u0107ini slu\u010dajeva, provo\u0111enje biolo\u0161ke identifikacije je malo realizabilno, posebno kada govorimo o sigurnosti web aplikacija, stoga se prilikom dvofaktorske autentifikacije (two factor authentication, 2FA) obi\u010dno koristi drugi atribut \u2014 \"ono \u0161to imate\". Jedna od popularnih opcija ovog drugog faktora je fizi\u010dki token, primjerice, RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Sve
\nFizi\u010dki token se \u010desto koristi za autentifikaciju u korporativnim VPN-ima i financijskim uslugama. Za autentifikaciju u servisu potrebno je koristiti i lozinku i kod na tokenu (koji se \u010desto mijenja) u kombinaciji s PIN-om. Teoretski, za identifikaciju napada\u010da mora znati lozinku, imati token, kao i znati PIN tokena. U scenariju vra\u0107anja lozinke sama lozinka o\u010dito nije poznata, me\u0111utim posjedovanje tokena mo\u017ee se iskoristiti za potvrdu vlasni\u0161tva nad ra\u010dunom. Naravno, kao i kod svake implementacije za\u0161tite, to ne garantira \"za\u0161titu od gluposti\"<\/a><\/noindex>, ali svakako pove\u0107ava ulaznu barijeru.<\/p>\n

Jedan od glavnih problema ovog pristupa je cijena i logistika implementacije; govorimo o isporuci fizi\u010dkih ure\u0111aja svakom klijentu i o obuci o novom postupku. Osim toga, korisnici moraju imati sa sobom ure\u0111aj, \u0161to u slu\u010daju fizi\u010dkog tokena nije uvijek mogu\u0107e. Jo\u0161 jedna opcija je implementirati drugi faktor autentifikacije putem SMS-a, koji u slu\u010daju 2FA mo\u017ee slu\u017eiti kao potvrda da osoba koja provodi proces vra\u0107anja ima mobilni telefon vlasnika ra\u010duna. Evo kako to radi Google:<\/p>\n

\"Sve
\nTako\u0111er je potrebno uklju\u010diti dvofaktorsku verifikaciju<\/a><\/noindex>, ali to zna\u010di da bi va\u0161 mobilni telefon mogao postati drugi faktor autentifikacije prilikom sljede\u0107eg resetiranja lozinke. Dopustite mi da to demonstriram na primjeru svog iPhonea zbog razloga koji \u0107e uskoro postati jasni:<\/p>\n

\"Sve
\nNakon identifikacije adrese e-po\u0161te, Googleov ra\u010dun utvr\u0111uje da je omogu\u0107ena 2FA i mo\u017eemo resetirati ra\u010dun putem verifikacije koja se \u0161alje SMS-om na mobilni telefon vlasnika ra\u010duna:<\/p>\n

\"Sve
\nSada trebamo odabrati po\u010detak procesa resetiranja:<\/p>\n

\"Sve
\nOva radnja dovodi do slanja e-po\u0161te na registriranu adresu:<\/p>\n

\"Sve
\nOva e-po\u0161ta sadr\u017ei URL za resetiranje:<\/p>\n

\"Sve
\nPrilikom pristupa URL-u za resetiranje, \u0161alje se SMS i web stranica tra\u017ei njegov unos:<\/p>\n

\"Sve
\nEvo tog SMS-a:<\/p>\n

\"Sve
\nNakon unosa u preglednik vra\u0107amo se na podru\u010dje klasi\u010dnog resetiranja lozinke:<\/p>\n

\"Sve
\nVjerojatno se \u010dini pomalo opsceno, i tako jest, ali obrazac potvr\u0111uje da osoba koja izvr\u0161ava resetiranje ima pristup adresi e-po\u0161te i mobilnom telefonu vlasnika ra\u010duna. No, to mo\u017ee biti devet puta sigurnije od resetiranja lozinke isklju\u010divo putem e-po\u0161te. Me\u0111utim, postoje problemi...<\/p>\n

Problem se odnosi na pametne telefone. Prikazani ure\u0111aj mo\u017ee potvrditi samo jedan faktor autentifikacije \u2014 mo\u017ee primati SMS, ali ne i e-po\u0161tu:<\/p>\n

\"Sve
\nMe\u0111utim, ovaj ure\u0111aj mo\u017ee primati SMS i<\/em> primati poruke o resetiranju lozinke:<\/p>\n

\"Sve
\nProblem je u tome \u0161to smatramo e-po\u0161tu prvim faktorom autentifikacije, a SMS (ili \u010dak aplikaciju koja generira tokene) drugim, ali danas su svi spojeni u jedan ure\u0111aj. Naravno, to zna\u010di da ako netko do\u0111e do va\u0161eg pametnog telefona, sav taj udobnost smanjit \u0107e se na to da se ponovno vra\u0107amo na jedan kanal; ovaj drugi faktor \u201eto, \u0161to imate\u201c zna\u010di da imate i prvi faktor. A sve to je za\u0161ti\u0107eno jednim PIN-om od \u010detiri cifre\u2026 ako telefon uop\u0107e ima PIN i<\/em> bio je zaklju\u010dan.<\/p>\n

Da, implementirana Googleova funkcija 2FA zasigurno osigurava dodatnu za\u0161titu, ali nije za\u0161ti\u0107ena \u201eod budale\u201c i potpuno ne ovisi o dva potpuno autonomna kanala.<\/p>\n

Resetiranje putem korisni\u010dkog imena nasuprot resetiranju putem adrese e-po\u0161te<\/h2>\n

\nTreba li omogu\u0107iti resetiranje samo putem e-po\u0161te? Ili bi korisnik trebao imati mogu\u0107nost resetiranja i prema imenu? Problem resetiranja prema korisni\u010dkom imenu je taj \u0161to nema na\u010dina da se obavijesti korisnik o pogre\u0161nom korisni\u010dkom imenu, ne otkrivaju\u0107i<\/em> to da netko drugi mo\u017ee imati ra\u010dun s tim imenom. U prethodnom odjeljku, resetiranje putem e-po\u0161te jam\u010dilo je da \u0107e zakoniti vlasnik te e-po\u0161te uvijek primiti povratne informacije bez javnog otkrivanja njegovog postojanja u sustavu. Samo uporabom korisni\u010dkog imena to nije mogu\u0107e.<\/p>\n

Stoga je odgovor kratak: samo e-po\u0161ta. Ako poku\u0161ate izvr\u0161iti resetiranje samo pomo\u0107u korisni\u010dkog imena, do\u0107i \u0107e do situacija u kojima \u0107e korisnik biti zbunjen oko toga \u0161to se doga\u0111a, ili<\/em> otkrit \u0107ete postojanje ra\u010duna. Da, to je samo korisni\u010dko ime, a ne adresa e-po\u0161te, i da, bilo tko mo\u017ee odabrati bilo koje (dostupno) korisni\u010dko ime, ali i dalje postoji velika vjerojatnost da \u0107ete neizravno otkriti vlasnike ra\u010duna zbog sklonosti korisnika vi\u0161estrukom kori\u0161tenju istog imena.<\/p>\n

\u0160to se doga\u0111a kada netko zaboravi svoje korisni\u010dko ime? Ako pretpostavimo da korisni\u010dko ime nije odmah adresa e-po\u0161te (a to se \u010desto doga\u0111a), postupak je sli\u010dan onome kako po\u010dinje resetiranje lozinke \u2014 unosimo adresu e-po\u0161te, a zatim \u0161aljemo poruku na tu adresu, ne otkrivaju\u0107i njezino postojanje. Jedina razlika je u tome \u0161to ovaj put poruka sadr\u017ei samo korisni\u010dko ime, a ne URL za resetiranje lozinke. Ili to, ili \u0107e u e-po\u0161ti pisati da za tu adresu nema ra\u010duna.<\/p>\n

Provjera identiteta i to\u010dnost adresa e-po\u0161te<\/h2>\n

\nKlju\u010dni aspekt resetiranja lozinki, i, \u010dak, vjerojatno, najva\u017eniji<\/em> aspekt je provjera identiteta osobe koja poku\u0161ava izvr\u0161iti resetiranje. Je li zaista to zakoniti vlasnik ra\u010duna, ili netko poku\u0161ava hakirati ili uzrokovati neugodnosti vlasniku?<\/p>\n

O\u010digledno je da je e-po\u0161ta najprakti\u010dniji i najra\u0161ireniji kanal za provjeru identiteta. Nije za\u0161ti\u0107ena od nepromi\u0161ljenog kori\u0161tenja (\u201eod glupaka\u201c), a ima mnogo slu\u010dajeva kada jednostavna mogu\u0107nost primanja poruka na adresu vlasnika ra\u010duna nije dovoljna kada je potrebna visoka razina sigurnosti u identifikaciji (zbog toga se koristi 2FA), me\u0111utim, gotovo uvijek je to po\u010detna to\u010dka procesa resetiranja.<\/p>\n

Ako e-po\u0161ta igra ulogu u osiguranju sigurnosti, prvo treba osigurati da je adresa e-po\u0161te zapravo ispravna. Ako netko pogrije\u0161i u znaku, o\u010digledno, resetiranje se ne\u0107e zapo\u010deti. Proces verifikacije e-po\u0161te prilikom registracije je pouzdan na\u010din provjere ispravnosti adrese. Svi smo to vidjeli u praksi: registrujete se, \u0161alju vam e-poruku s jedinstvenim URL-om na koji treba kliknuti, \u0161to potvr\u0111uje da ste vi zaista vlasnik te adrese e-po\u0161te. Nemogu\u0107nost prijave u sustav prije zavr\u0161etka ovog procesa garantira motivaciju za potvrdu adrese.<\/p>\n

Kao i u mnogim drugim aspektima sigurnosti, takav model smanjuje korisni\u010dku pogodnost u zamjenu za pove\u0107anje razine sigurnosti u pogledu identiteta korisnika. To mo\u017ee biti prihvatljivo za web stranicu koju korisnik visoko cijeni i rado \u0107e dodati jo\u0161 jedan korak u procesu (pla\u0107ene usluge, bankarstvo itd.), ali takve stvari mogu odbiti korisnika ako smatra da je ra\u010dun \u201ejednokratni\u201c i koristi ga, na primjer, samo kao sredstvo za komentiranje objava.<\/p>\n

Identifikacija onoga tko je pokrenuo proces resetiranja<\/h2>\n

\nO\u010digledno je da postoje razlozi za zlonamjernu upotrebu funkcije resetiranja, i napada\u010di je mogu koristiti na mnogo razli\u010ditih na\u010dina. Jedan jednostavan trik koji mo\u017eemo koristiti kao pomo\u0107 u potvrdi izvora zahtjeva (ovaj trik obi\u010dno<\/em> funkcionira) je dodavanje IP adrese tra\u017eitelja u e-poruku o mogu\u0107nosti resetiranja. To daje primatelju neku<\/em> informaciju za identifikaciju izvora zahtjeva.<\/p>\n

Evo primjera iz funkcije resetiranja koju trenutno implementiram u ASafaWeb:<\/p>\n

\"Sve
\nVeza \u201efind out more\u201c (\u201eSaznajte vi\u0161e\u201c) preusmjerava korisnika na stranicu ip-adress.com<\/a><\/noindex>, koji pru\u017ea informacije kao \u0161to su lokacija i organizacija koja tra\u017ei resetiranje:<\/p>\n

\"Sve
\nNaravno, svatko tko \u017eeli sakriti svoj identitet ima mno\u0161tvo na\u010dina za obfuscaciju svog stvarnog IP adresa, no ovo je prikladan na\u010din dodavanja djelomi\u010dne identifikacije podnositelja zahtjeva, i ve\u0107ini<\/em> u nekim slu\u010dajevima \u0107e vam dati dovoljno informacija o tome tko \u0107e izvr\u0161iti zahtjev za resetiranje lozinke.<\/p>\n

Obavijest o promjenama putem e-po\u0161te<\/h2>\n

\nOvaj post je pro\u017eet jednom temom \u2014 komunikacijom; obavje\u0161tavajte vlasnika ra\u010duna \u0161to je vi\u0161e mogu\u0107e o tome \u0161to se doga\u0111a u svakom koraku procesa, ne otkrivaju\u0107i ni\u0161ta \u0161to bi moglo biti kori\u0161teno u zlu. Isto se odnosi na situaciju kada je lozinka zapravo promijenjena \u2014 obavijestite vlasnika!<\/em><\/strong><\/p>\n

Razlozi za promjenu lozinke mogu imati dva izvora:<\/p>\n

    \n
  1. Promjena lozinke nakon prijave, jer korisnik \u017eeli novu lozinku<\/li>\n
  2. Resetiranje lozinke bez prijave, jer je korisnik zaboravio svoju lozinku<\/li>\n<\/ol>\n

    \nIako je ovaj post uglavnom posve\u0107en resetiranju, obavijest u prvom slu\u010daju smanjuje rizik od toga da netko promijeni lozinku bez znanja zakonitog vlasnika. Kako se to mo\u017ee dogoditi? Vrlo \u010dest scenarij je dobivanje lozinke zakonitog vlasnika (ponovo kori\u0161tena lozinka, procurila s drugog mjesta; lozinka dobijena keyloggingom; lako poga\u0111ana lozinka itd.), nakon \u010dega decidirano napada\u010d odlu\u010di promijeniti, tako onemogu\u0107iv\u0161i vlasnika. Bez obavijesti putem e-po\u0161te, stvarni vlasnik ne\u0107e znati za promjenu lozinke.<\/p>\n

    Naravno, u slu\u010daju resetiranja lozinke, vlasnik bi ve\u0107 trebao sam pokrenuti proces (ili zaobi\u0107i navedene provjere identiteta), stoga promjena ne bi trebao<\/em> ne bi trebala biti iznena\u0111enje, me\u0111utim, potvrda putem e-po\u0161te bila bi pozitivna povratna informacija i dodatna provjera. Osim toga, to omogu\u0107ava dosljednost s ranije opisanim scenarijem.<\/p>\n

    Oh, i u slu\u010daju da to jo\u0161 nije o\u010dito \u2014 ne \u0161aljite novu lozinku putem e-po\u0161te!<\/em><\/strong> Neki bi se mogli nasmijati na to, ali to se doga\u0111a<\/a><\/noindex>:<\/p>\n

    \"Sve<\/p>\n

    Logovi, logovi, logovi i jo\u0161 malo logova<\/h2>\n

    \nFunkcija resetiranja lozinke privla\u010di napada\u010de: napada\u010d \u017eeli dobiti pristup ne\u010dijem ra\u010dunu ili jednostavno stvoriti neugodnosti vlasniku ra\u010duna\/sustava. Mnoge od gore navedenih praksi smanjuju vjerojatnost zloupotreba, ali ih ne sprje\u010davaju i sigurno ne\u0107e sprije\u010diti ljude da poku\u0161avaju koristiti funkciju na nepredvi\u0111en na\u010din.<\/p>\n

    Za prepoznavanje zlonamjernog pona\u0161anja izuzetno je dragocjena praksa logiranje, a mislim na vrlo detaljno logiranje<\/em><\/strong>. Zabilje\u017eite neuspje\u0161ne prijave u sustav, ponovna postavljanja lozinki, promjene lozinki (tj. kada je korisnik ve\u0107 prijavljen) i gotovo sve \u0161to mo\u017ee pomo\u0107i razumijevanju onoga \u0161to se doga\u0111a; to \u0107e biti vrlo korisno u budu\u0107nosti. Zabilje\u017eite u logovima \u010dak i pojedine dijelove<\/em> procesa, primjerice, dobra funkcija resetiranja trebala bi uklju\u010divati zapo\u010dinjanje resetiranja putem web stranice (zabilje\u017eite zahtjev i poku\u0161aje prijave za resetiranje s neispravnim korisni\u010dkim imenom ili e-po\u0161tom), zabilje\u017eite posjet web stranici putem URL-a za resetiranje (uklju\u010duju\u0107i poku\u0161aje kori\u0161tenja neispravnog tokena), a zatim zabilje\u017eite uspje\u0161nost ili neuspjeh odgovora na tajni pitanje.<\/p>\n

    Kada govorim o logiranju, mislim ne samo na zabilje\u017ebu u\u010ditavanja stranice, ve\u0107 i na prikupljanje \u0161to je mogu\u0107e vi\u0161e informacija, ako nisu povjerljive<\/em><\/strong>. Momci, molim vas, nemojte zapisivati lozinke u logove!<\/em><\/strong> U logovima treba zabilje\u017eiti identitet autoriziranog korisnika (bit \u0107e autoriziran ako mijenja<\/em> postoje\u0107u lozinku ili poku\u0161ava resetirati ne\u010diju lozinku<\/em> nakon prijave), bilo koja poku\u0161ana korisni\u010dka imena ili adrese e-po\u0161te uz bilo koje tokene resetiranja koje poku\u0161ava koristiti. No, tako\u0111er vrijedi zabilje\u017eiti u logovima i takve aspekte, kao \u0161to su IP adrese i, ako je mogu\u0107e, \u010dak i zaglavlja upita. To vam omogu\u0107ava da rekreirate ne samo \u0161ta<\/em> \u0161to korisnik (ili napada\u010d) poku\u0161ava u\u010diniti, ve\u0107 i ko<\/em> tko je on.<\/p>\n

    Delegiranje odgovornosti drugim izvr\u0161iteljima<\/h2>\n

    \nAko mislite da je to opse\u017ean posao, niste sami. Uistinu, izgradnja pouzdane sustava za upravljanje nalozima nije lagan zadatak. Nije rije\u010d samo o tehni\u010dkoj slo\u017eenosti, ve\u0107 i o mnogim specifi\u010dnostima. To uklju\u010duje ne samo resetiranje, ve\u0107 \u010ditav proces registracije, sigurno pohranjivanje lozinki, obrada vi\u0161estrukih neuspje\u0161nih poku\u0161aja prijave itd. i sl. promoviram ideju kori\u0161tenja gotove funkcionalnosti poput ASP.NET membership providera,<\/a><\/noindex>ali osim toga, potrebno je u\u010diniti jo\u0161 mnogo toga.<\/p>\n

    Danas postoji mnogo vanjskih pru\u017eatelja koji rado preuzimaju sve neda\u0107e i apsktiraju sve to u jedan upravljani servis. Me\u0111u takvim servisima su OpenID, OAuth pa \u010dak i Facebook. Neki ljudi beskrajno vjeruju ovom modelu,<\/a><\/noindex> (OpenID se doista pokazao vrlo uspje\u0161nim na Stack Overflow), me\u0111utim, drugi doslovno ga smatraju no\u0107nom morom.<\/a><\/noindex>.<\/p>\n

    Bez sumnje, servis poput OpenID rje\u0161ava mnoge probleme programerima, no tako\u0111er je neosporno da dodaje nove. Imaju li neku ulogu? Da, ali o\u010dito je da ne vidimo masovno kori\u0161tenje usluga pru\u017eatelja autentifikacije. Banke, aviokompanije i \u010dak prodavaonice \u2014 svi implementiraju vlastiti mehanizam autentifikacije, i o\u010dito postoji vrlo ozbiljan razlog za to.<\/p>\n

    Zlonamjerno resetiranje<\/h2>\n

    \nVa\u017ean aspekt svakog od gore navedenih primjera je da stara lozinka postaje beskorisna samo nakon potvrde identiteta vlasnika ra\u010duna.<\/em><\/strong>To je va\u017eno, jer kad bi se ra\u010dun mogao resetirati do<\/em> bez provjere identifikacije, to bi omogu\u0107ilo razne zlonamjerne radnje.<\/p>\n

    Evo primjera: netko sudjeluje u aukciji, a bli\u017ee kraju procesa licitacije blokira konkurente pokretanjem procesa resetiranja, zapravo ih uklanjaju\u0107i iz aukcije. O\u010dito, ako se lo\u0161e dizajnirana funkcija resetiranja mo\u017ee iskoristiti neispravno, to mo\u017ee dovesti do ozbiljnih negativnih posljedica. Treba napomenuti da blokiranje ra\u010duna putem neispravnih poku\u0161aja prijave predstavlja sli\u010dnu situaciju, ali to je ve\u0107 tema za drugu objavu.<\/p>\n

    Kao \u0161to sam spomenuo ranije, ako se anonimnim korisnicima dopusti resetiranje lozinke bilo kojeg ra\u010duna samo znanjem adrese e-po\u0161te, to je savr\u0161ena situacija za napad tipa \"usluge odbijanja\". To mo\u017eda nije ono DoS<\/a><\/noindex>, o kojem smo navikli govoriti, ali ne postoji br\u017ei na\u010din da se blokira pristup ra\u010dunu nego kroz lo\u0161e osmi\u0161ljenu funkciju resetiranja lozinke.<\/p>\n

    Najslabija karika<\/h2>\n

    \nIz perspektive za\u0161tite jednog ra\u010duna, sve gore navedeno je fenomenalno, me\u0111utim uvijek trebate imati na umu ekosustav koji okru\u017euje ra\u010dun koji \u0161titite. Dopustite mi da navedem primjer:<\/p>\n

    ASafaWeb se hosta na nevjerojatnoj usluzi koju pru\u017ea AppHarbor. Proces resetiranja ra\u010duna hostinga ide ovako:<\/p>\n

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

    \"Sve
    \nKorak 2:<\/strong><\/p>\n

    \"Sve
    \nKorak 3:<\/strong><\/p>\n

    \"Sve
    \nKorak 4:<\/strong><\/p>\n

    \"Sve
    \nNakon \u0161to ste pro\u010ditali sve prethodne informacije, lako je razumjeti koje aspekte bismo u idealnom svijetu realizirali malo druga\u010dije. Me\u0111utim, ovdje \u017eelim re\u0107i da ako objavim stranicu poput ASafaWeb na usluzi AppHarbor i zatim smi\u0161ljam odli\u010dna tajna pitanja i odgovore, dodam drugi faktor autentifikacije i u\u010dinim sve ostalo po pravilima, to ne ukida \u010dinjenicu da \u0107e najslabija karika cijelog procesa biti sposobna sve to slomiti. Ako se netko uspje\u0161no autentificira na AppHarbor koriste\u0107i moje informacije, mo\u0107i \u0107e promijeniti lozinku bilo kojeg ASafaWeb ra\u010duna na ono \u0161to \u017eeli!<\/p>\n

    Bit je u tome da otpornost implementacije za\u0161tite treba razmatrati cjelovito: potrebno je simulirati prijetnje svake ulazne to\u010dke sustava, \u010dak i ako je to povr\u0161inski proces, poput prijave na AppHarbor. To bi mi trebalo dati dobru predstavu o tome koliko truda trebam ulo\u017eiti u proces resetiranja lozinke ASafaWeb.<\/p>\n

    Sve povezujemo<\/h2>\n

    \nOva objava sadr\u017ei veliki volumen informacija, pa \u017eelim koncentrirati to u jednostavnu vizualnu shemu:<\/p>\n

    \"Sve
    \nZapamtite da je potrebno provesti maksimalno detaljno logiranje svake od ovih stavki. To je to, jednostavno!<\/p>\n

    Zaklju\u010dci<\/h2>\n

    \nMoj post izgleda sveobuhvatno, me\u0111utim postoji mnogo dodatnih materijala koje mogu mogao<\/em> uklju\u010diti u njega, ali odlu\u010dio sam se od njega odvojiti radi sa\u017eetka: uloga adrese e-po\u0161te za oporavak, situacija u kojoj gubite pristup e-po\u0161ti povezanoj s ra\u010dunom (na primjer, kada ste napustili posao) i tako dalje. Kao \u0161to sam ranije rekao, funkcija resetiranja nije toliko slo\u017eena, ali postoje brojni pogledi na nju.<\/p>\n

    \u010cak iako resetiranje nije tako te\u0161ko, \u010desto se pogre\u0161no implementira. Gore smo vidjeli nekoliko primjera kada implementacija mo\u017ee<\/em> mo\u017ee dovesti do problema, a postoji mnogo vi\u0161e presedana kada pogre\u0161no resetiranje zaista<\/em> uzrokuje probleme. Nedavno se otkrilo da resetiranje lozinke koristi za kra\u0111u bitcoina u iznosu od 87 tisu\u0107a dolara<\/a><\/noindex>. To je ozbiljna negativna posljedica!<\/p>\n

    Zato budite oprezni sa svojim funkcijama resetiranja, modelirajte prijetnje<\/a><\/noindex> na razli\u010ditim to\u010dkama, a prilikom dizajniranja funkcije ne skidajte svoju crnu kapu, jer postoji velika vjerojatnost da \u0107e je netko drugi staviti!<\/p>\n

    <\/p>\n

    U okviru reklame<\/h4>\n

    \nVDSina<\/b> nudi povoljne servere za iznajmljivanje<\/a><\/noindex> na dnevnoj osnovi, svaki poslu\u017eitelj je povezan s internet kanalom od 500 megabita i besplatno je za\u0161ti\u0107en od DDoS napada!<\/p>\n

    \"Sve<\/a><\/noindex>
    \n
    Izvor:     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\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\udd47Sve \u0161to ste \u017eeljeli znati o sigurnom resetiranju lozinki. Dio 2 | ProHoster","description":"Dvofaktorska autentifikacija Sve \u0161to ste pro\u010ditali u prvom dijelu odnosilo se na identifikaciju na temelju onoga \u0161to.","canonical_url":"https:\/\/prohoster.info\/hr\/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":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}