{"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\/sq\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"T\u00eb gjitha q\u00eb keni dashur t\u00eb dini rreth riparimeve t\u00eb sigurt t\u00eb fjal\u00ebkalimeve. Pjesa 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autentikimi me dy faktor\u00eb<\/h2>\n

\n\u00c7do gj\u00eb q\u00eb keni lexuar n\u00eb pjes\u00ebn e par\u00eb<\/a><\/noindex> ka t\u00eb b\u00ebj\u00eb me identifikimin n\u00eb baz\u00eb t\u00eb asaj q\u00eb dijeni k\u00ebrkuesi<\/em><\/strong>. Ai e di adres\u00ebn e tij t\u00eb emailit, di se si t\u00eb qaccessoj\u00eb at\u00eb (pra, di fjal\u00ebkalimin e tij t\u00eb emailit) dhe di p\u00ebrgjigjet p\u00ebr pyetjet sekrete. <\/p>\n

\u00abDija\u00bb konsiderohet si nj\u00eb faktor autentikimi; dy faktor\u00ebt e tjer\u00eb t\u00eb zakonsh\u00ebm jan\u00eb ajo q\u00eb keni<\/em><\/strong>, p\u00ebr shembull, nj\u00eb pajisje fizike, dhe ajo q\u00eb jeni<\/em><\/strong>, p\u00ebr shembull, printet e gisht\u00ebrinjve ose irisit t\u00eb syve.<\/p>\n

\"T\u00eb
\n<\/a><\/noindex>
\nN\u00eb shumic\u00ebn e rasteve, realizimi i identifikimit biologjik \u00ebsht\u00eb shum\u00eb i v\u00ebshtir\u00eb, ve\u00e7an\u00ebrisht kur flasim p\u00ebr sigurin\u00eb e aplikacioneve t\u00eb internetit, prandaj n\u00eb autentikimin me dy faktor\u00eb (two factor authentication, 2FA) zakonisht p\u00ebrdoret atributi i dyt\u00eb \u2014 \u00abajo q\u00eb keni\u00bb. Nj\u00eb nga mund\u00ebsit\u00eb e njohura t\u00eb k\u00ebtij faktori t\u00eb dyt\u00eb \u00ebsht\u00eb tokeni fizik, p\u00ebr shembull, RSA SecurID<\/a><\/noindex>:<\/p>\n

\"T\u00eb
\nToken\u00ebt fizik\u00eb p\u00ebrdoren shpesh p\u00ebr autentikimin n\u00eb VPN-t\u00eb korporative dhe sh\u00ebrbimet financiare. P\u00ebr autentikimin n\u00eb sh\u00ebrbim, njer\u00ebzit duhet t\u00eb p\u00ebrdorin si fjal\u00ebkalimin ashtu edhe kodin n\u00eb token (i cili shpesh ndryshon) s\u00eb bashku me PIN-in. Teoretikisht, p\u00ebr identifikimin e sulmuesit, ai duhet t\u00eb dij\u00eb fjal\u00ebkalimin, t\u00eb ket\u00eb tokenin, si dhe t\u00eb dij\u00eb PIN-in e tokenit. N\u00eb skenarin e rikthimit t\u00eb fjal\u00ebkalimit, fjal\u00ebkalimi vet\u00eb sigurisht q\u00eb nuk \u00ebsht\u00eb i njohur, megjithat\u00eb, posedimi i tokenit mund t\u00eb p\u00ebrdoret p\u00ebr t\u00eb konfirmuar pron\u00ebsin\u00eb e llogaris\u00eb. Natyrisht, si\u00e7 ndodh me \u00e7do implementim t\u00eb mbrojtjes, kjo nuk ofron \"mbrojtje nga budallenjt\u00eb\"<\/a><\/noindex>, por padyshim rrit barrier\u00ebn e hyrjes.<\/p>\n

Nj\u00eb nga problemet kryesore t\u00eb k\u00ebtij qasjeje \u00ebsht\u00eb kostoja dhe logjistika e implementimit; po flasim p\u00ebr shp\u00ebrndarjen e pajisjeve fizike p\u00ebr \u00e7do klient dhe p\u00ebr trajnimin e tyre n\u00eb procesin e ri. P\u00ebr m\u00eb tep\u00ebr, p\u00ebrdoruesit duhet t\u00eb ken\u00eb pajisjen me vete, gj\u00eb q\u00eb n\u00eb rastin e tokenit fizik nuk ndodh gjithmon\u00eb. Nj\u00eb tjet\u00ebr mund\u00ebsi \u00ebsht\u00eb t\u00eb realizohet faktori i dyt\u00eb i autentikimit p\u00ebrmes SMS-it, i cili n\u00eb rastin e 2FA mund t\u00eb sh\u00ebrbej\u00eb si konfirmim se personi q\u00eb po p\u00ebrfiton procesin e rikthimit ka telefonin mobil t\u00eb pronarit t\u00eb llogaris\u00eb. Ja si e b\u00ebn Google:<\/p>\n

\"T\u00eb
\nGjithashtu \u00ebsht\u00eb e nevojshme t\u00eb aktivizohet verifikimi me dy hapa<\/a><\/noindex>, porosie se kjo do t\u00eb thot\u00eb se gjat\u00eb rikthimit t\u00eb ardhsh\u00ebm t\u00eb fjal\u00ebkalimit, telefoni juaj mobil mund t\u00eb b\u00ebhet faktori i dyt\u00eb i autentifikimit. Lejoni t\u00eb ilustroj k\u00ebt\u00eb me shembujn\u00eb e iPhone tim p\u00ebr arsye q\u00eb do t\u00eb b\u00ebhen t\u00eb qarta s\u00eb shpejti:<\/p>\n

\"T\u00eb
\nPas identifikimit t\u00eb adres\u00ebs s\u00eb emailit t\u00eb llogaris\u00eb Google, p\u00ebrcaktohet se \u00ebsht\u00eb aktivizuar 2FA dhe ne mund ta rikthejm\u00eb llogarin\u00eb me verifikimin q\u00eb d\u00ebrgohet p\u00ebrmes SMS n\u00eb telefonin mobil t\u00eb pronarit t\u00eb llogaris\u00eb:<\/p>\n

\"T\u00eb
\nTani na nevojitet t\u00eb zgjedhim fillimin e procesit t\u00eb rikthimit:<\/p>\n

\"T\u00eb
\nKy veprim \u00e7on n\u00eb d\u00ebrgimin e nj\u00eb emaili n\u00eb adres\u00ebn e regjistruar:<\/p>\n

\"T\u00eb
\nKy email p\u00ebrmban URL-n\u00eb e rikthimit:<\/p>\n

\"T\u00eb
\nKur merret akses n\u00eb URL-n\u00eb e rikthimit, nj\u00eb SMS d\u00ebrgohet dhe faqja e internetit k\u00ebrkon ta fusni at\u00eb:<\/p>\n

\"T\u00eb
\nJa ky SMS:<\/p>\n

\"T\u00eb
\nPas futjes s\u00eb tij n\u00eb shfletues, ne kthehemi n\u00eb territorin e rikthimit klasik t\u00eb fjal\u00ebkalimit:<\/p>\n

\"T\u00eb
\nNdoshta kjo duket pak e gjat\u00eb, dhe ka t\u00eb drejt\u00eb, por forma konfirmon se ai q\u00eb b\u00ebn rikthimin ka akses n\u00eb adres\u00ebn e emailit dhe telefonin mobil t\u00eb pronarit t\u00eb llogaris\u00eb. Por kjo mund t\u00eb jet\u00eb n\u00eb n\u00ebnt\u00eb her\u00eb m\u00eb e sigurt se rikthimi i fjal\u00ebkalimit vet\u00ebm p\u00ebrmes emailit. Sidoqoft\u00eb, ekzistojn\u00eb probleme...<\/p>\n

Problemi lidhet me smartfon\u00ebt. Pajisja e treguar m\u00eb posht\u00eb mund t\u00eb verifikoj\u00eb vet\u00ebm nj\u00eb faktor autentifikimi - ajo \u00ebsht\u00eb n\u00eb gjendje t\u00eb marr\u00eb SMS, por jo email:<\/p>\n

\"T\u00eb
\nMegjithat\u00eb, kjo pajisje mund t\u00eb marr\u00eb SMS dhe<\/em> t\u00eb marr\u00eb email p\u00ebr rikthimin e fjal\u00ebkalimit:<\/p>\n

\"T\u00eb
\nProblemi \u00ebsht\u00eb se ne e shqyrtojm\u00eb emailin si faktor t\u00eb par\u00eb t\u00eb autentifikimit, dhe SMS (ose madje aplikacionin q\u00eb gjeneron tokene) si t\u00eb dyt\u00eb, por sot ato jan\u00eb t\u00eb bashkuara n\u00eb nj\u00eb pajisje. Natyrisht, kjo do t\u00eb thot\u00eb se n\u00ebse dikush arrin t\u00eb hyj\u00eb n\u00eb smartfonin tuaj, e gjith\u00eb kjo leht\u00ebsi do t\u00eb reduktohej n\u00eb nj\u00eb kanal; ky faktor i dyt\u00eb \u2018ajo q\u00eb keni\u2019 do t\u00eb thot\u00eb se keni edhe faktorin e par\u00eb. Dhe e gjith\u00eb kjo mbrohet me nj\u00eb PIN prej kat\u00ebr numrash... n\u00ebse telefoni ka ndonj\u00ebher\u00eb nj\u00eb PIN dhe<\/em> ai ishte bllokuar.<\/p>\n

Po, funksioni 2FA i implementuar nga Google sigurisht q\u00eb ofron mbrojtje t\u00eb shtuar, por ai nuk \u00ebsht\u00eb i mbrojtur \u2018nga budallall\u00ebku\u2019, dhe sigurisht q\u00eb nuk mb\u00ebshtetet n\u00eb dy kanale krejt\u00ebsisht autonome.<\/p>\n

Rikthimi mbi emrin e p\u00ebrdoruesit p\u00ebrball\u00eb rikthimit mbi adres\u00ebn e emailit<\/h2>\n

\nA duhet lejuar rikthimi vet\u00ebm p\u00ebrmes adres\u00ebs elektronike? Apo p\u00ebrdoruesi duhet t\u00eb ket\u00eb mund\u00ebsin\u00eb t\u00eb b\u00ebj\u00eb rikthimin edhe p\u00ebrmes emrit? Problemi me rikthimin p\u00ebrmes emrit t\u00eb p\u00ebrdoruesit \u00ebsht\u00eb se nuk ka asnj\u00eb m\u00ebnyr\u00eb p\u00ebr t\u00eb njoftuar p\u00ebrdoruesin p\u00ebr emrin e gabuar t\u00eb p\u00ebrdoruesit, pa zbuluar<\/em> se dikush tjet\u00ebr mund t\u00eb ket\u00eb nj\u00eb llogari me k\u00ebt\u00eb em\u00ebr. N\u00eb seksionin e m\u00ebparsh\u00ebm, rikthimi p\u00ebrmes emailit garantonte q\u00eb pronari legjitim i k\u00ebsaj adrese elektroni t\u00eb merrte gjithmon\u00eb informacion pa zbuluar publikisht ekzistenc\u00ebn e tij n\u00eb sistem. Me vet\u00ebm emrin e p\u00ebrdoruesit, kjo \u00ebsht\u00eb e pamundur.<\/p>\n

Prandaj, p\u00ebrgjigja \u00ebsht\u00eb e qart\u00eb: vet\u00ebm p\u00ebrmes emailit. N\u00ebse provoni t\u00eb b\u00ebni rikthimin vet\u00ebm me emrin e p\u00ebrdoruesit, do t\u00eb ket\u00eb raste kur p\u00ebrdoruesi do t\u00eb pyes\u00eb se \u00e7far\u00eb ka ndodhur, ose<\/em> ju do t\u00eb zbuloni ekzistenc\u00ebn e llogarive. Po, \u00ebsht\u00eb vet\u00ebm nj\u00eb em\u00ebr p\u00ebrdoruesi, e jo nj\u00eb adres\u00eb emaili dhe po, \u00e7do person mund t\u00eb zgjedh\u00eb nj\u00eb em\u00ebr p\u00ebrdoruesi (t\u00eb disponuesh\u00ebm), por gjithsesi ka nj\u00eb probabilitet t\u00eb madh q\u00eb do t\u00eb zbuloni pronar\u00ebt e llogarive p\u00ebr shkak t\u00eb tendenc\u00ebs s\u00eb p\u00ebrdoruesve p\u00ebr t\u00eb ricikluar emrin.<\/p>\n

Pra, \u00e7far\u00eb ndodh kur dikush harron emrin e tij t\u00eb p\u00ebrdoruesit? N\u00ebse supozoni se emri i p\u00ebrdoruesit nuk \u00ebsht\u00eb menj\u00ebher\u00eb nj\u00eb adres\u00eb emaili (dhe kjo ndodh shpesh), procesi \u00ebsht\u00eb i ngjash\u00ebm me se si fillon rikthimi i fjal\u00ebkalimit - shkruajm\u00eb adres\u00ebn e emailit, pastaj d\u00ebrgojm\u00eb nj\u00eb mesazh n\u00eb at\u00eb adres\u00eb, pa zbuluar ekzistenc\u00ebn e saj. Diferenca e vetme \u00ebsht\u00eb se k\u00ebt\u00eb her\u00eb mesazhi p\u00ebrmban vet\u00ebm emrin e p\u00ebrdoruesit, dhe jo URL-n\u00eb e rikthimit t\u00eb fjal\u00ebkalimit. Ose, ose n\u00eb email do t\u00eb thuhet se nuk ka llogari p\u00ebr k\u00ebt\u00eb adres\u00eb.<\/p>\n

Verifikimi i identitetit dhe sakt\u00ebsia e adresave t\u00eb emailit<\/h2>\n

\nNj\u00eb aspekt ky\u00e7 i rikthimit t\u00eb fjal\u00ebkalimeve, dhe, ndoshta, aspekti m\u00eb<\/em> ky\u00e7 \u00ebsht\u00eb verifikimi i identitetit t\u00eb personit q\u00eb p\u00ebrpiqet t\u00eb b\u00ebj\u00eb rikthimin. A \u00ebsht\u00eb v\u00ebrtet pronari legjitim i llogaris\u00eb, apo dikush po p\u00ebrpiqet ta thyej\u00eb at\u00eb ose t'i shkaktoj\u00eb shqet\u00ebsime pronarit?<\/p>\n

\u00cbsht\u00eb evidente se ajo q\u00eb \u00ebsht\u00eb e-maili \u00ebsht\u00eb kanali m\u00eb i njohur dhe m\u00eb i p\u00ebrdorur p\u00ebr verifikimin e identitetit. Ai nuk \u00ebsht\u00eb i mbrojtur nga p\u00ebrdorimi i keq (\u00abnga budallai\u00bb), dhe ekzistojn\u00eb shum\u00eb raste kur thjesht mund\u00ebsia p\u00ebr t\u00eb pranuar mesazhe n\u00eb adres\u00ebn e pronarit t\u00eb llogaris\u00eb nuk \u00ebsht\u00eb e mjaftueshme, kur k\u00ebrkohet nj\u00eb nivel i lart\u00eb besueshm\u00ebrie n\u00eb identifikim (p\u00ebr k\u00ebt\u00eb arsye p\u00ebrdoret 2FA), megjithat\u00eb, pothuajse gjithmon\u00eb \u00ebsht\u00eb pika fillestare e procesit t\u00eb rivendosjes.<\/p>\n

N\u00ebse e-maili do t\u00eb luaj\u00eb nj\u00eb rol n\u00eb sigurimin e besueshm\u00ebris\u00eb, at\u00ebher\u00eb hapi i par\u00eb \u00ebsht\u00eb t\u00eb sigurohemi se adresa e e-mailit \u00ebsht\u00eb n\u00eb t\u00eb v\u00ebrtet\u00eb e sakt\u00eb. N\u00ebse dikush ka gabuar nj\u00eb simbol, qart\u00eb, rivendosja nuk do t\u00eb filloj\u00eb. Procesi i verifikimit t\u00eb e-mailit n\u00eb momentin e regjistrimit \u00ebsht\u00eb nj\u00eb m\u00ebnyr\u00eb e besueshme p\u00ebr t\u00eb kontrolluar sakt\u00ebsin\u00eb e adres\u00ebs. T\u00eb gjith\u00eb e kemi par\u00eb k\u00ebt\u00eb n\u00eb praktik\u00eb: regjistroheni, ju d\u00ebrgohet nj\u00eb e-mail me nj\u00eb URL unik, mbi t\u00eb cilin duhet t\u00eb klikoni, q\u00eb konfirmon se ju jeni me t\u00eb v\u00ebrtet\u00eb pronari i k\u00ebsaj llogarie e-maili. Pamund\u00ebsia p\u00ebr t\u00eb hyr\u00eb n\u00eb sistem p\u00ebrpara se t\u00eb p\u00ebrfundoj\u00eb ky proces garanton motivimin p\u00ebr t\u00eb konfirmuar adres\u00ebn.<\/p>\n

Ashtu si n\u00eb shum\u00eb aspekte t\u00eb tjera t\u00eb siguris\u00eb, nj\u00eb model i till\u00eb zvog\u00eblon leht\u00ebsin\u00eb e p\u00ebrdorimit n\u00eb k\u00ebmbim t\u00eb siguris\u00eb m\u00eb t\u00eb lart\u00eb n\u00eb lidhje me besueshm\u00ebrin\u00eb e identitetit t\u00eb p\u00ebrdoruesit. Kjo mund t\u00eb jet\u00eb e pranueshme p\u00ebr nj\u00eb uebfaqe q\u00eb p\u00ebrdoruesi e vler\u00ebson shum\u00eb dhe me k\u00ebnaq\u00ebsi do t\u00eb shtonte nj\u00eb hap tjet\u00ebr n\u00eb proces (sh\u00ebrbime t\u00eb paguara, banking, etj.), por gj\u00ebra t\u00eb tilla mund t\u00eb tundojn\u00eb p\u00ebrdoruesin n\u00ebse e percepton llogarin\u00eb si \"nj\u00ebher\u00ebsh\" dhe e p\u00ebrdor vet\u00ebm si nj\u00eb mjet p\u00ebr t\u00eb komentuar nj\u00eb postim.<\/p>\n

Identifikimi i atij q\u00eb e nisi procesin e rivendosjes<\/h2>\n

\n\u00cbsht\u00eb evidente se ka arsye p\u00ebr p\u00ebrdorimin e keq t\u00eb funksionit t\u00eb rivendosjes, dhe hakerat mund ta p\u00ebrdorin at\u00eb n\u00eb shum\u00eb m\u00ebnyra t\u00eb ndryshme. Nj\u00eb truk i thjesht\u00eb q\u00eb mund t\u00eb p\u00ebrdorim p\u00ebr t\u00eb ndihmuar n\u00eb konfirmimin e burimit t\u00eb k\u00ebrkes\u00ebs (ky truk zakonisht<\/em> funksionon) \u2014 \u00ebsht\u00eb shtimi i IP-adres\u00ebs k\u00ebrkuese n\u00eb e-mailin me ofert\u00ebn p\u00ebr rivendosje. Kjo i jep marr\u00ebsit disa<\/em> informacione p\u00ebr identifikimin e burimit t\u00eb k\u00ebrkes\u00ebs.<\/p>\n

Ja nj\u00eb shembull nga funksioni i rivendosjes q\u00eb un\u00eb po e integroj tani n\u00eb ASafaWeb:<\/p>\n

\"T\u00eb
\nLink \u2018find out more\u2019 ('M\u00ebso m\u00eb shum\u00eb') redirects the user to the site ip-adress.com<\/a><\/noindex>, informing about details such as location and organization of the requesting reset:<\/p>\n

\"T\u00eb
\nOf course, anyone wanting to conceal their identity has numerous ways to obfuscate their real IP address, but this provides a convenient means of adding partial identification of the requester, and in most cases it will give you a sufficient insight into who is executing the password reset request.<\/em> Email change notification<\/p>\n

This post is imbued with one theme \u2014 communication; inform the account owner as much as possible about what is happening at each stage of the process, without revealing anything that could be used maliciously. The same applies to the situation where the password has indeed changed \u2014<\/h2>\n

\ninform the owner about it! The reasons for changing the password may stem from two sources:<\/em><\/strong><\/p>\n

Password change after logging in because the user wants a new password<\/p>\n

    \n
  1. Password reset without logging in because the user forgot it<\/li>\n
  2. Although this post primarily addresses resets, notification in the first case reduces the risk of someone changing the password without the lawful owner's knowledge. How can this happen? A common scenario is when the legitimate owner's password is obtained (a reused password, leaked from another source; a password obtained through keylogging; an easily guessable password, etc.), after which the attacker decides to change it, thereby blocking the owner. Without email notification, the rightful owner will be unaware of the password change.<\/li>\n<\/ol>\n

    \nCertainly, in the case of a password reset, the owner should have already initiated the process themselves (or circumvented the above-described identity verification means), so the change<\/p>\n

    should not come as a surprise to them, but confirmation via email would provide positive feedback and an additional verification. Moreover, it ensures consistency with the aforementioned scenario.<\/em> Oh, and in case this is not already obvious \u2014<\/p>\n

    do not send the new password by email! Some might find this amusing, but<\/em><\/strong> such things happen Logs, logs, logs, and a little more logs<\/a><\/noindex>:<\/p>\n

    \"T\u00eb<\/p>\n

    Log, log, log dhe pak m\u00eb shum\u00eb log<\/h2>\n

    \nFuncioni e rikthimit t\u00eb fjal\u00ebkalimit \u00ebsht\u00eb er\u00ebsishme p\u00ebr sulmuesit: ata duan t\u00eb hyjn\u00eb n\u00eb llogarin\u00eb e dikujt tjet\u00ebr, ose thjesht t\u00eb shkaktojn\u00eb shqet\u00ebsime p\u00ebr pronarin e llogaris\u00eb\/sistemit. Shumica e praktikave t\u00eb p\u00ebrmendura m\u00eb sip\u00ebr lejojn\u00eb t\u00eb zvog\u00eblohet probabiliteti i abuzimeve, por nuk e parandalojn\u00eb at\u00eb, dhe ato me siguri nuk do t\u00eb ndalojn\u00eb njer\u00ebzit t\u00eb provojn\u00eb t\u00eb p\u00ebrdorin funksionin n\u00eb m\u00ebnyr\u00eb t\u00eb paautorizuar.<\/p>\n

    P\u00ebr t\u00eb njohur sjelljet e d\u00ebmshme, nj\u00eb praktik\u00eb e \u00e7muar \u00ebsht\u00eb logimi, dhe un\u00eb flas p\u00ebr logimin shum\u00eb t\u00eb detajuar.<\/em><\/strong>Regjistroni p\u00ebrpjekjet e d\u00ebshtuara p\u00ebr t\u00eb hyr\u00eb n\u00eb sistem, rikthimet e fjal\u00ebkalimeve, ndryshimet e fjal\u00ebkalimeve (dmth. kur p\u00ebrdoruesi tashm\u00eb \u00ebsht\u00eb i hyr\u00eb) dhe praktikisht gjith\u00e7ka q\u00eb mund t\u00eb ndihmoj\u00eb n\u00eb kuptimin e asaj q\u00eb ka ndodhur; kjo do t\u00eb jet\u00eb shum\u00eb e dobishme n\u00eb t\u00eb ardhmen. Regjistroni madje edhe pjes\u00ebt e procesit, p\u00ebr shembull, nj\u00eb funksion i mir\u00eb rikthimi duhet t\u00eb p\u00ebrfshij\u00eb iniciimin e rikthimit p\u00ebrmes uebfaqes (regjistroni k\u00ebrkes\u00ebn dhe p\u00ebrpjekjet e hyrjes p\u00ebr rikthim me emra p\u00ebrdoruesi ose adresa elektronike t\u00eb gabuara), regjistroni vizit\u00ebn n\u00eb uebfaqe p\u00ebr URL-n\u00eb e rikthimit (p\u00ebrfshir\u00eb p\u00ebrpjekjet p\u00ebr t\u00eb p\u00ebrdorur nj\u00eb token t\u00eb gabuar), dhe pastaj regjistroni suksesin ose d\u00ebshtimin e p\u00ebrgjigjes ndaj pyetjes sekrete.<\/em> Kur flas p\u00ebr logimin, un\u00eb nuk p\u00ebrfshij vet\u00ebm regjistrimin e faktit t\u00eb ngarkimit t\u00eb faqes, por edhe grumbullimin e sa m\u00eb shum\u00eb informacioni t\u00eb mundsh\u00ebm,<\/p>\n

    n\u00ebse nuk \u00ebsht\u00eb konfidencial. Djem,<\/em><\/strong>ju lutem, mos regjistroni fjal\u00ebkalimet n\u00eb loge! N\u00eb loge duhet t\u00eb regjistrohet identiteti i p\u00ebrdoruesit t\u00eb autorizuar (ai do t\u00eb jet\u00eb i autorizuar n\u00ebse ai<\/em><\/strong> ndryshon fjal\u00ebkalimin ekzistues ose p\u00ebrpiqet t\u00eb rikthej\u00eb<\/em> fjal\u00ebkalimin e dikujt tjet\u00ebr pas hyrjes n\u00eb sistem), \u00e7do em\u00ebr p\u00ebrdoruesi ose adres\u00eb elektronike q\u00eb ai p\u00ebrpiqet t\u00eb p\u00ebrdor\u00eb, plus \u00e7do token rikthimi q\u00eb ai p\u00ebrpiqet t\u00eb p\u00ebrdor\u00eb. Por gjithashtu ia vlen t\u00eb regjistrohen n\u00eb loge aspekte t\u00eb tilla si adresat IP dhe, n\u00ebse \u00ebsht\u00eb e mundur, madje edhe titujt e k\u00ebrkesave. Kjo ju lejon t\u00eb rikrijoni jo vet\u00ebm<\/em> \u00e7far\u00eb p\u00ebrdoruesi (ose sulmuesi) p\u00ebrpiqet t\u00eb b\u00ebj\u00eb, por gjithashtu nuk shkon, dhe gjithashtu ka nj\u00eb ide p\u00ebr at\u00eb q\u00eb ndodh n\u00eb sh\u00ebrbimet p\u00ebrreth, p\u00ebr t\u00eb kuptuar,<\/em> ai \u00ebsht\u00eb i till\u00eb. kush<\/em> Delegimi i p\u00ebrgjegj\u00ebsive te ekzekutues t\u00eb tjer\u00eb.<\/p>\n

    Delegimi i p\u00ebrgjegj\u00ebsive te ekzekutues t\u00eb tjer\u00eb.<\/h2>\n

    \nN\u00ebse mendoni se t\u00eb gjitha k\u00ebto paraqesin nj\u00eb ngarkes\u00eb t\u00eb madhe pune, nuk jeni t\u00eb vetmit. N\u00eb t\u00eb v\u00ebrtet\u00eb, nd\u00ebrtimi i nj\u00eb sistemi t\u00eb besuesh\u00ebm p\u00ebr menaxhimin e llogarive \u00ebsht\u00eb nj\u00eb detyr\u00eb e nd\u00ebrlikuar. Problemi nuk \u00ebsht\u00eb se ai \u00ebsht\u00eb teknikisht i v\u00ebshtir\u00eb, por se ka shum\u00eb ve\u00e7ori q\u00eb duhet t\u00eb merren parasysh. Kjo p\u00ebrfshin jo vet\u00ebm rikuperimin e fjal\u00ebkalimeve, por gjithashtu nj\u00eb proces t\u00eb plot\u00eb regjistrimi, ruajtjen e sigurt t\u00eb fjal\u00ebkalimeve, trajtimin e shum\u00eb p\u00ebrpjekjeve t\u00eb pasuksesshme p\u00ebr t'u ky\u00e7ur, etj. un\u00eb e promovoj iden\u00eb e p\u00ebrdorimit t\u00eb funksionaliteteve t\u00eb gatshme si ofruesi i an\u00ebtar\u00ebsis\u00eb ASP.NET<\/a><\/noindex>, p\u00ebrve\u00e7 saj, ka shum\u00eb m\u00eb tep\u00ebr p\u00ebr t\u00eb b\u00ebr\u00eb.<\/p>\n

    Sot ka shum\u00eb ofrues t\u00eb pal\u00ebve t\u00eb treta, q\u00eb e pranojn\u00eb me g\u00ebzim t\u00eb gjith\u00eb dhimbjen dhe e abstrahojn\u00eb at\u00eb n\u00eb nj\u00eb sh\u00ebrbim t\u00eb menaxhuar. N\u00eb mesin e k\u00ebtyre sh\u00ebrbimeve jan\u00eb OpenID, OAuth dhe madje edhe Facebook. Disa njer\u00ebz besojn\u00eb pa kufij n\u00eb k\u00ebt\u00eb model<\/a><\/noindex> (OpenID n\u00eb t\u00eb v\u00ebrtet\u00eb ishte shum\u00eb i suksessh\u00ebm n\u00eb Stack Overflow), megjithat\u00eb, disa t\u00eb others e shohin at\u00eb si nj\u00eb makth t\u00eb v\u00ebrtet\u00eb<\/a><\/noindex>.<\/p>\n

    Pa dyshim, nj\u00eb sh\u00ebrbim si OpenID zgjidh nj\u00eb num\u00ebr problemesh p\u00ebr zhvilluesit, megjithat\u00eb, gjithashtu \u00ebsht\u00eb e qart\u00eb se ai sjell t\u00eb reja. A kan\u00eb ata ndonj\u00eb rol? Po, por duket se nuk po shohim p\u00ebrdorim masiv t\u00eb sh\u00ebrbimeve t\u00eb ofruesve t\u00eb autentifikimit. Bankat, kompanit\u00eb ajrore dhe madje dyqanet - t\u00eb gjitha ata implementojn\u00eb mekanizma t\u00eb vet\u00eb autentifikimit, dhe \u00ebsht\u00eb e qart\u00eb se ka arsye shum\u00eb t\u00eb forta p\u00ebr k\u00ebt\u00eb.<\/p>\n

    Rikuperimi i keq<\/h2>\n

    \nNj\u00eb aspekt i r\u00ebnd\u00ebsish\u00ebm i \u00e7do nj\u00eb prej shembujve t\u00eb p\u00ebrmendur m\u00eb lart \u00ebsht\u00eb se fjal\u00ebkalimi i vjet\u00ebr konsiderohet i pavler\u00eb vet\u00ebm pas konfirmimit t\u00eb identitetit t\u00eb pronarit t\u00eb llogaris\u00eb<\/em><\/strong>. Kjo \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, sepse sikur llogaria t\u00eb mund t\u00eb rikuperohej n\u00eb<\/em> pa kontrollimin e identitetit, kjo do t\u00eb lejonte veprime t\u00eb ndryshme t\u00eb k\u00ebqija.<\/p>\n

    Ja nj\u00eb shembuj: dikush merr pjes\u00eb n\u00eb ankande n\u00eb nj\u00eb faqe ankandi, dhe af\u00ebr fundi t\u00eb procesit t\u00eb ankandeve ai bllokon konkurent\u00ebt duke nismuar procesin e rikuperimit, duke eliminuar k\u00ebshtu ata nga ankandi. \u00cbsht\u00eb evidente se, n\u00ebse nj\u00eb funksion i dob\u00ebt i rikuperimit mund t\u00eb keqinterpretohet, kjo mund t\u00eb \u00e7oj\u00eb n\u00eb pasoja t\u00eb r\u00ebnda negative. Vlen t\u00eb theksohet se bllokimi i llogarive p\u00ebrmes p\u00ebrpjekjeve t\u00eb pasuksesshme p\u00ebr t'u ky\u00e7ur \u00ebsht\u00eb nj\u00eb situat\u00eb e ngjashme, por kjo \u00ebsht\u00eb nj\u00eb tem\u00eb p\u00ebr nj\u00eb post tjet\u00ebr.<\/p>\n

    Si e thash\u00eb m\u00eb lart, n\u00ebse u jepni p\u00ebrdoruesve anonim\u00eb mund\u00ebsin\u00eb p\u00ebr t\u00eb rikuperuar fjal\u00ebkalimin e \u00e7do llogarie vet\u00ebm me e-mailin, at\u00ebher\u00eb krijoni nj\u00eb situat\u00eb ideale p\u00ebr sulme t\u00eb tipit \"mo\u00e7ali\". Kjo mund t\u00eb mos jet\u00eb ajo mo\u00e7ali<\/a><\/noindex>, p\u00ebr t\u00eb cil\u00ebn jemi m\u00ebsuar t\u00eb flasim, por nuk ka m\u00ebnyr\u00eb m\u00eb t\u00eb shpejt\u00eb p\u00ebr t\u00eb bllokuar aksesin n\u00eb nj\u00eb llogari sesa me nj\u00eb funksion t\u00eb keqplanifikuar p\u00ebr rikuperimin e fjal\u00ebkalimit.<\/p>\n

    Pika m\u00eb e dob\u00ebt<\/h2>\n

    \nNga perspektiva e mbrojtjes s\u00eb nj\u00eb llogarie, gjith\u00e7ka e shkruar m\u00eb sip\u00ebr \u00ebsht\u00eb e shk\u00eblqyer, megjithat\u00eb, duhet gjithmon\u00eb t\u00eb mbani n\u00eb mend ekosistemin p\u00ebrreth llogaris\u00eb q\u00eb po e mbrojm\u00eb. Le t\u00eb jap nj\u00eb shembull:<\/p>\n

    ASafaWeb \u00ebsht\u00eb hostuar n\u00eb nj\u00eb sh\u00ebrbim t\u00eb mrekulluesh\u00ebm q\u00eb ofrohet nga AppHarbor. Procesi i rikuperimit t\u00eb llogaris\u00eb s\u00eb hostimit ndodh k\u00ebshtu:<\/p>\n

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

    \"T\u00eb
    \nHapi 2:<\/strong><\/p>\n

    \"T\u00eb
    \nHapi 3:<\/strong><\/p>\n

    \"T\u00eb
    \nHapi 4:<\/strong><\/p>\n

    \"T\u00eb
    \nPas leht\u00ebsimit t\u00eb gjith\u00eb informacionit t\u00eb m\u00ebparsh\u00ebm, \u00ebsht\u00eb e leht\u00eb t\u00eb kuptosh se cilat aspekte n\u00eb nj\u00eb bot\u00eb ideale do t'i realizonim ndryshe. Megjithat\u00eb, k\u00ebtu dua t\u00eb them se n\u00ebse publikoj nj\u00eb faqe si ASafaWeb n\u00eb sh\u00ebrbimin AppHarbor dhe pastaj krijoj pyetje dhe p\u00ebrgjigje sekrete t\u00eb shk\u00eblqyera, shtoj faktorin e dyt\u00eb t\u00eb autentifikimit dhe b\u00ebj gjith\u00e7ka sipas rregullave, kjo nuk d\u00ebfton faktin se pika m\u00eb e dob\u00ebt e gjith\u00eb procesit do t\u00eb jet\u00eb n\u00eb gjendje ta thyej\u00eb k\u00ebt\u00eb. N\u00ebse dikush arrin t\u00eb autentikohet me sukses n\u00eb AppHarbor duke p\u00ebrdorur informacionin tim, at\u00ebher\u00eb ai do t\u00eb jet\u00eb n\u00eb gjendje t\u00eb ndryshoj\u00eb fjal\u00ebkalimin e \u00e7do llogarie ASafaWeb n\u00eb at\u00eb q\u00eb do!<\/p>\n

    Thelb\u00ebsore \u00ebsht\u00eb se q\u00ebndrueshm\u00ebria e implementimit t\u00eb mbrojtjes duhet t\u00eb konsiderohet n\u00eb t\u00ebr\u00ebsi: duhet t\u00eb modeloni k\u00ebrc\u00ebnimet p\u00ebr \u00e7do pik\u00eb hyrjeje t\u00eb sistemit, madje edhe n\u00ebse \u00ebsht\u00eb nj\u00eb proces sip\u00ebrfaq\u00ebsor si hyrja n\u00eb sistemin AppHarbor. Kjo duhet t\u00eb m\u00eb jap\u00eb nj\u00eb ide t\u00eb mir\u00eb se sa p\u00ebrpjekje duhet t\u00eb investoj n\u00eb procesin e rikuperimit t\u00eb fjal\u00ebkalimit t\u00eb ASafaWeb.<\/p>\n

    T\u00eb gjitha s\u00eb bashku<\/h2>\n

    \nKy post p\u00ebrmban nj\u00eb sasi t\u00eb madhe informacioni, prandaj dua ta p\u00ebrqendroj at\u00eb n\u00eb nj\u00eb diagram t\u00eb thjesht\u00eb vizual:<\/p>\n

    \"T\u00eb
    \nMbani mend se duhet t\u00eb b\u00ebni regjistrimin m\u00eb t\u00eb detajuar t\u00eb secilit nga k\u00ebto pika. K\u00ebtu jemi, \u00ebsht\u00eb aq e thjesht\u00eb!<\/p>\n

    P\u00ebrfundime<\/h2>\n

    \nPosti im duket i gjithansh\u00ebm, megjithat\u00eb ekzistojn\u00eb shum\u00eb materiale t\u00eb tjera q\u00eb un\u00eb mund t\u00eb<\/em> ta p\u00ebrfshij\u00eb n\u00eb t\u00eb, por vendosi t\u00eb duket nga kjo p\u00ebr shkak t\u00eb shkurt\u00ebsis\u00eb: roli i adres\u00ebs s\u00eb emergjenc\u00ebs elektronike, situata ku humbni aksesin n\u00eb emailin e lidhur me llogarin\u00eb (p\u00ebr shembull, keni ikur nga puna) dhe k\u00ebshtu me radh\u00eb. Si\u00e7 thash\u00eb m\u00eb par\u00eb, funksioni i rikuperimit nuk \u00ebsht\u00eb aq i komplikuar, ka vet\u00ebm shum\u00eb pik\u00ebpamje p\u00ebr t\u00eb.<\/p>\n

    Edhe pse rikuperimi nuk \u00ebsht\u00eb aq i v\u00ebshtir\u00eb, shpesh implementohet gabimisht. M\u00eb sip\u00ebr kemi par\u00eb disa shembuj kur implementimi mund<\/em> \u00e7on n\u00eb probleme, dhe ka shum\u00eb m\u00eb tep\u00ebr raste kur rikuperimi i gabuar v\u00ebrtet\u00eb<\/em> ka shkaktuar probleme. S\u00eb fundmi doli n\u00eb pah se funksioni i rikuperimit t\u00eb passwords \u00ebsht\u00eb p\u00ebrdorur p\u00ebr t\u00eb vjedhur bitcoin n\u00eb vler\u00eb prej 87 mij\u00eb dollar\u00ebsh.<\/a><\/noindex>Kjo \u00ebsht\u00eb nj\u00eb rezultat negativ serioz!<\/p>\n

    Prandaj, jini t\u00eb kujdessh\u00ebm me funksionet tuaja t\u00eb rikuperimit, modeloni k\u00ebrc\u00ebnimet<\/a><\/noindex> n\u00eb pika t\u00eb ndryshme, dhe gjat\u00eb projektimit t\u00eb funksionit mos hiqni kapel\u00ebn tuaj t\u00eb zez\u00eb, sepse ka nj\u00eb mund\u00ebsi t\u00eb madhe q\u00eb dikush tjet\u00ebr do ta vesh\u00eb at\u00eb!<\/p>\n

    <\/p>\n

    SOF6<\/h4>\n

    \nVDSina<\/b> ofron \u00e7mime t\u00eb ul\u00ebta server\u00eb me qira<\/a><\/noindex> me pages\u00eb p\u00ebr dit\u00eb, \u00e7do server \u00ebsht\u00eb i lidhur me nj\u00eb kanal interneti prej 500 Megabit dhe \u00ebsht\u00eb falas t\u00eb mbrohet nga sulmet DDoS!<\/p>\n

    \"T\u00eb<\/a><\/noindex>
    \n
    Burimi:     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\udd47Gjith\u00e7ka q\u00eb d\u00ebshironi t\u00eb dini p\u00ebr rikuperimin e sigurt t\u00eb passwords. Pjesa 2 | ProHoster","description":"Autentikimi me dy faktor\u00eb Gjith\u00e7ka q\u00eb lexuat n\u00eb pjes\u00ebn e par\u00eb lidhet me identifikimin n\u00eb baz\u00eb t\u00eb atij q\u00eb.","canonical_url":"https:\/\/prohoster.info\/sq\/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":"sq_AL","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\/sq\/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\/sq\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}