{"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\/it\/blog\/administrirovanie\/vsyo-chto-vy-hoteli-znat-o-bezopasnom-sbrose-parolej-chast-2","title":{"rendered":"Tutto ci\u00f2 che volevate sapere sul ripristino sicuro delle password. Parte 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Autenticazione a due fattori<\/h2>\n

\nTutto ci\u00f2 che hai letto in prima parte<\/a><\/noindex> riguarda l'identificazione basata su ci\u00f2 che sa l'utente che richiede<\/em><\/strong>. Lui conosce il proprio indirizzo email, sa come accedervi (ovvero, conosce la propria password email) e conosce le risposte alle domande segrete. <\/p>\n

La \"conoscenza\" \u00e8 considerata un fattore di autenticazione; gli altri due fattori comuni sono ci\u00f2 che possiedi<\/em><\/strong>, ad esempio, un dispositivo fisico, e chi sei<\/em><\/strong>, ad esempio, impronte digitali o retina dell'occhio.<\/p>\n

\"Tutto
\n<\/a><\/noindex>
\nNella maggior parte dei casi, l'identificazione biometrica \u00e8 poco praticabile, soprattutto quando si parla di sicurezza delle applicazioni web, quindi nell'autenticazione a due fattori (two factor authentication, 2FA) si utilizza solitamente un secondo attributo: \"ci\u00f2 che possiedi\". Una delle opzioni pi\u00f9 popolari per questo secondo fattore \u00e8 un token fisico, come RSA SecurID<\/a><\/noindex>:<\/p>\n

\"Tutto
\nIl token fisico \u00e8 frequentemente utilizzato per l'autenticazione in VPN aziendali e servizi finanziari. Per autenticarsi nel servizio \u00e8 necessario utilizzare sia la password, sia il codice sul token (che cambia spesso) insieme a un PIN. Teoricamente, per identificarsi, un attaccante dovrebbe conoscere la password, possedere il token e sapere anche il PIN del token. Nel caso di un reset della password, la password stessa \u00e8 chiaramente sconosciuta, tuttavia il possesso del token pu\u00f2 essere utilizzato per confermare la propriet\u00e0 dell'account. Naturalmente, come per qualsiasi implementazione di sicurezza, non garantisce una \"protezione dai principianti\"<\/a><\/noindex>, ma sicuramente aumenta la barriera all'ingresso.<\/p>\n

Uno dei principali problemi di questo approccio \u00e8 il costo e la logistica dell'implementazione; stiamo parlando della consegna di dispositivi fisici a ogni cliente e della formazione su questo nuovo processo. Inoltre, gli utenti devono avere con s\u00e9 il dispositivo, il che nel caso di un token fisico non avviene sempre. Un'altra opzione \u00e8 implementare un secondo fattore di autenticazione tramite SMS, che nel caso del 2FA pu\u00f2 servire a confermare che la persona che sta effettuando il reset possiede il telefono cellulare del proprietario dell'account. Ecco come lo fa Google:<\/p>\n

\"Tutto
\n\u00c8 anche necessario attivare la verifica in due passaggi<\/a><\/noindex>, ma questo significa che al prossimo ripristino della password il tuo telefono cellulare potrebbe diventare il secondo fattore di autenticazione. Permettimi di dimostrarlo con il mio iPhone per motivi che diventeranno presto chiari:<\/p>\n

\"Tutto
\nDopo aver identificato l'indirizzo email, Google determina che la 2FA \u00e8 stata attivata e possiamo ripristinare l'account tramite una verifica che viene inviata tramite SMS al telefono cellulare del proprietario dell'account:<\/p>\n

\"Tutto
\nOra dobbiamo scegliere di avviare il processo di ripristino:<\/p>\n

\"Tutto
\nQuesta azione provoca l'invio di un'email all'indirizzo registrato:<\/p>\n

\"Tutto
\nQuesta email contiene l'URL per il ripristino:<\/p>\n

\"Tutto
\nAccedendo all'URL di ripristino viene inviato un SMS e il sito web chiede di inserirlo:<\/p>\n

\"Tutto
\nEcco questo SMS:<\/p>\n

\"Tutto
\nDopo averlo inserito nel browser, torniamo alla zona del classico ripristino della password:<\/p>\n

\"Tutto
\nProbabilmente sembra un po' prolisso, ed \u00e8 cos\u00ec, ma il modulo conferma che chi sta effettuando il ripristino ha accesso all'indirizzo email e al telefono cellulare del proprietario dell'account. Ma questo potrebbe essere nove volte pi\u00f9 sicuro rispetto al ripristino della password solo tramite email. Tuttavia, ci sono dei problemi...<\/p>\n

Il problema riguarda gli smartphone. Il dispositivo mostrato di seguito pu\u00f2 autenticare solo un fattore di autenticazione: pu\u00f2 ricevere SMS ma non email:<\/p>\n

\"Tutto
\nTuttavia, questo dispositivo pu\u00f2 ricevere SMS e<\/em> ricevere email per il ripristino della password:<\/p>\n

\"Tutto
\nIl problema \u00e8 che consideriamo l'email come il primo fattore di autenticazione e gli SMS (o persino un'app che genera token) come il secondo, ma oggi sono uniti in un unico dispositivo. Ovviamente ci\u00f2 significa che se qualcun altro accede al tuo smartphone, tutta questa comodit\u00e0 si ridurr\u00e0 a un solo canale; quel secondo fattore 'quello che hai' implica che hai anche il primo fattore. E tutto ci\u00f2 \u00e8 protetto da un PIN di quattro cifre... se il telefono ha effettivamente un PIN e<\/em> \u00e8 stato bloccato.<\/p>\n

S\u00ec, la funzione 2FA implementata da Google fornisce sicuramente una protezione aggiuntiva, ma non \u00e8 protetta \"dall'ignoranza\" e non dipende affatto da due canali completamente autonomi.<\/p>\n

Ripristino tramite nome utente contro ripristino tramite indirizzo email<\/h2>\n

\n\u00c8 necessario consentire il ripristino solo tramite indirizzo e-mail? O l'utente dovrebbe avere la possibilit\u00e0 di effettuare il ripristino anche tramite nome? Il problema del ripristino tramite nome utente \u00e8 che non c'\u00e8 modo di informare l'utente riguardo a un nome utente errato, senza rivelare<\/em> che qualcun altro potrebbe avere un account con quel nome. Nella sezione precedente, il ripristino tramite e-mail garantiva che il legittimo proprietario di quell'indirizzo e-mail ricevesse sempre un feedback senza rivelare pubblicamente la sua esistenza nel sistema. Con solo il nome utente, questo non \u00e8 possibile.<\/p>\n

Quindi la risposta \u00e8 breve: solo e-mail. Se provi a effettuare il ripristino solo con il nome utente, ci saranno casi in cui l'utente non capir\u00e0 cosa sia successo, o<\/em> rivelando l'esistenza degli account. S\u00ec, \u00e8 solo un nome utente, non un indirizzo e-mail, e s\u00ec, chiunque pu\u00f2 scegliere un qualsiasi nome utente (disponibile), ma c'\u00e8 comunque una grande probabilit\u00e0 di rivelare indirettamente i proprietari degli account a causa della tendenza degli utenti a riutilizzare il nome.<\/p>\n

Allora, cosa succede quando qualcuno dimentica il proprio nome utente? Se si presume che il nome utente non sia direttamente un indirizzo e-mail (cosa che accade spesso), il processo \u00e8 simile a come inizia un ripristino della password: inseriamo l'indirizzo e-mail e poi inviamo un messaggio a quell'indirizzo, senza rivelarne l'esistenza. L'unica differenza \u00e8 che questa volta il messaggio contiene solo il nome utente, non un URL di ripristino della password. O questo, o nell'e-mail sar\u00e0 indicato che non c'\u00e8 alcun account per quell'indirizzo.<\/p>\n

Verifica dell'identit\u00e0 e accuratezza degli indirizzi e-mail<\/h2>\n

\nUn aspetto chiave del ripristino delle password, e probabilmente anche il pi\u00f9<\/em> aspetto chiave \u00e8 la verifica dell'identit\u00e0 della persona che sta tentando di eseguire il ripristino. \u00c8 veramente il legittimo proprietario dell'account, o qualcuno sta cercando di hackerarlo o di creare disagio al proprietario?<\/p>\n

\u00c8 evidente che la posta elettronica \u00e8 il canale pi\u00f9 comodo e diffuso per la verifica dell'identit\u00e0. Non \u00e8 immune da utilizzi impropri (\u201cda principianti\u201d) e ci sono molti casi in cui la semplice possibilit\u00e0 di ricevere email all'indirizzo del proprietario dell'account non \u00e8 sufficiente se \u00e8 richiesta un'alta affidabilit\u00e0 nell'identificazione (da qui l'uso della 2FA), tuttavia \u00e8 quasi sempre il punto di partenza del processo di reset.<\/p>\n

Se la posta elettronica deve svolgere un ruolo nel garantire fiducia, la prima cosa da verificare \u00e8 che l'indirizzo email sia realmente corretto. Se qualcuno commette un errore in un carattere, \u00e8 evidente che il reset non avr\u00e0 inizio. Il processo di verifica dell'email al momento della registrazione \u00e8 un modo affidabile per controllare la correttezza dell'indirizzo. Tutti noi abbiamo visto questo in pratica: ci si registra, si riceve un'email con un URL unico su cui cliccare, che conferma che si \u00e8 veramente il proprietario di quell'account email. L'impossibilit\u00e0 di accedere al sistema fino al completamento di questo processo garantisce la motivazione a confermare l'indirizzo.<\/p>\n

Come in molti altri aspetti della sicurezza, questo modello riduce l'usabilit\u00e0 in cambio di un livello maggiore di sicurezza rispetto alla fiducia nell'identit\u00e0 dell'utente. Questo pu\u00f2 essere accettabile per un sito la cui registrazione \u00e8 altamente valutata dall'utente e che accetter\u00e0 volentieri un ulteriore passo nel processo (servizi a pagamento, banking, ecc.), ma simili requisiti possono allontanare l'utente se percepisce l'account come 'usa e getta', utilizzandolo ad esempio semplicemente come mezzo per commentare un post.<\/p>\n

Identificazione di chi ha avviato il processo di reset<\/h2>\n

\n\u00c8 evidente che ci sono motivi per un uso malevolo della funzione di reset, e i malintenzionati possono sfruttarla in vari modi. Un trucco semplice che possiamo usare per confermare la fonte della richiesta (questo trucco di solito<\/em> funziona) \u00e8 quello di includere nell'email di proposta di reset l'indirizzo IP di chi richiede. Questo fornisce al destinatario alcune<\/em> informazioni per identificare la fonte della richiesta.<\/p>\n

Ecco un esempio dalla funzione di reset che sto attualmente integrando in ASafaWeb:<\/p>\n

\"Tutto
\nIl collegamento \u00abfind out more\u00bb (\u00abScopri di pi\u00f9\u00bb) porta l'utente al sito web ip-adress.com<\/a><\/noindex>, che comunica informazioni come la posizione e l'organizzazione della richiesta di reimpostazione:<\/p>\n

\"Tutto
\nNaturalmente, chiunque voglia nascondere la propria identit\u00e0 ha molti modi per offuscare il proprio vero IP, tuttavia questo \u00e8 un modo conveniente per aggiungere un parziale identificativo della richiesta, e in maggior parte dei<\/em> alcuni casi fornir\u00e0 un'adeguata comprensione di chi effettua la richiesta di reimpostazione della password.<\/p>\n

Notifica dei cambiamenti via email<\/h2>\n

\nQuesto post \u00e8 incentrato su un tema: la comunicazione; informa il proprietario dell'account il pi\u00f9 possibile su cosa sta succedendo in ogni fase del processo, senza rivelare nulla che possa essere usato con intento malevolo. Lo stesso vale per la situazione in cui la password \u00e8 stata effettivamente cambiata \u2014 informalo!<\/em><\/strong><\/p>\n

Le ragioni per cambiare la password possono essere due:<\/p>\n

    \n
  1. Cambio della password dopo l'accesso, perch\u00e9 l'utente vuole una nuova password<\/li>\n
  2. Reimpostazione della password senza accesso, perch\u00e9 l'utente l'ha dimenticata<\/li>\n<\/ol>\n

    \nSebbene questo post sia principalmente dedicato alla reimpostazione, la notifica nel primo caso riduce il rischio che qualcuno cambi la password senza la conoscenza del legittimo proprietario. Come pu\u00f2 succedere? Uno scenario comune \u00e8 il recupero della password del legittimo proprietario (password riutilizzata, trapelata da un'altra fonte; password ottenuta tramite keylogging; password facilmente indovinabili, ecc.), dopo di che un malintenzionato decide di cambiarla, bloccando cos\u00ec il proprietario. Senza una notifica via email, il vero proprietario non sapr\u00e0 della modifica della password.<\/p>\n

    Certo, nel caso di reimpostazione della password, il proprietario dovrebbe gi\u00e0 aver iniziato il processo (o bypassato i mezzi di verifica dell'identit\u00e0 sopra descritti), quindi il cambiamento non dovrebbe<\/em> essere una sorpresa per lui, tuttavia la conferma via email sar\u00e0 un feedback positivo e una verifica aggiuntiva. Inoltre, garantisce coerenza con lo scenario descritto sopra.<\/p>\n

    Oh, e nel caso in cui non sia gi\u00e0 chiaro \u2014 non inviare la nuova password via email!<\/em><\/strong> A qualcuno questo potrebbe sembrare divertente, ma succede<\/a><\/noindex>:<\/p>\n

    \"Tutto<\/p>\n

    Log, log, log e ancora pi\u00f9 log<\/h2>\n

    \nLa funzione di reset della password \u00e8 attraente per i malintenzionati: l'attaccante pu\u00f2 voler accedere all'account di un'altra persona o semplicemente creare disagi al proprietario dell'account\/sistema. Molte delle pratiche descritte sopra permettono di ridurre la probabilit\u00e0 di abusi, ma non li prevengono e non impediranno sicuramente alle persone di cercare di utilizzare la funzione in modo non previsto.<\/p>\n

    Per riconoscere un comportamento malevolo, una pratica assolutamente preziosa \u00e8 il logging, e intendo dire un logging molto dettagliato<\/em><\/strong>. Registra i tentativi di accesso falliti, il reset delle password, la modifica delle password (cio\u00e8 quando l'utente \u00e8 gi\u00e0 connesso) e praticamente tutto ci\u00f2 che pu\u00f2 aiutarti a comprendere ci\u00f2 che sta accadendo; sar\u00e0 molto utile in futuro. Registra nei log anche singole parti<\/em> del processo, ad esempio, una buona funzione di reset dovrebbe includere l'inizio del reset tramite il sito web (registra la richiesta e i tentativi di accesso per il reset con nome utente o email errati), registra la visita al sito web tramite l'URL di reset (inclusi i tentativi di utilizzo di un token non valido), e poi annota nei log l'esito o meno della risposta alla domanda segreta.<\/p>\n

    Quando parlo di logging, non intendo solo registrare il fatto che una pagina \u00e8 stata caricata, ma raccogliere il maggior numero possibile di informazioni, se non \u00e8 riservata<\/em><\/strong>. Ragazzi, per favore, non registrate nei log le password!<\/em><\/strong> Nei log \u00e8 necessario registrare l'identit\u00e0 dell'utente autorizzato (sar\u00e0 autorizzato se cambia<\/em> una password esistente o tenta di resettare la password di qualcun altro<\/em> dopo essersi connesso al sistema), qualunque nome utente o indirizzo email tentato e qualsiasi token di reset che sta cercando di utilizzare. \u00c8 anche utile registrare nei log aspetti come gli indirizzi IP e, se possibile, anche le intestazioni delle richieste. Questo ti permette di ricostruire non solo cosa<\/em> cosa sta tentando di fare l'utente (o l'attaccante), ma anche chi<\/em> chi \u00e8.<\/p>\n

    Delegare la responsabilit\u00e0 ad altri esecutori<\/h2>\n

    \nSe pensi che tutto ci\u00f2 rappresenti un grande volume di lavoro, non sei solo. In realt\u00e0, costruire un sistema affidabile per la gestione degli account non \u00e8 un compito facile. Non si tratta solo di una difficolt\u00e0 tecnica, ci sono molte peculiarit\u00e0 coinvolte. Non riguarda solo il reset, ma esiste un intero processo di registrazione, una memorizzazione sicura delle password, la gestione di molteplici tentativi di accesso non riusciti, ecc. e cos\u00ec via. Anche se promuovo l'idea di utilizzare funzionalit\u00e0 pronte come il provider di membership ASP.NET<\/a><\/noindex>, oltre a ci\u00f2 c'\u00e8 molto altro da fare.<\/p>\n

    Oggi ci sono molti fornitori esterni che si assumono volentieri tutte le difficolt\u00e0, astrarre tutto questo in un servizio gestito. Tra questi servizi ci sono OpenID, OAuth e anche Facebook. Alcune persone credono ciecamente a questo modello<\/a><\/noindex> (OpenID si \u00e8 rivelato molto successo su Stack Overflow), tuttavia altri lo considerano letteralmente un incubo<\/a><\/noindex>.<\/p>\n

    Senza dubbio, un servizio come OpenID risolve molti problemi per gli sviluppatori, ma \u00e8 altrettanto certo che introduce nuovi problemi. Hanno un ruolo? S\u00ec, ma \u00e8 evidente che non osserviamo un uso massiccio dei servizi dei fornitori di autenticazione. Le banche, le compagnie aeree e persino i negozi \u2014 tutti implementano i propri meccanismi di autenticazione, e chiaramente ci sono motivi molto validi per questo.<\/p>\n

    Reset malevolo<\/h2>\n

    \nUn aspetto importante di ciascuno degli esempi sopra menzionati \u00e8 che la vecchia password \u00e8 considerata inutile solo dopo la conferma dell'identit\u00e0 del proprietario dell'account<\/em><\/strong>. Questo \u00e8 importante, perch\u00e9 se un account potesse essere resettato fino a<\/em> senza verifica dell'identit\u00e0, questo permetterebbe una serie di azioni malevole.<\/p>\n

    Ecco un esempio: qualcuno partecipa a un'asta in un sito di aste, e verso la fine del processo di asta blocca i concorrenti avviando il processo di reset, in questo modo eliminandoli dall'asta. \u00c8 evidente che se una funzione di reset mal progettata pu\u00f2 essere sfruttata in modo errato, pu\u00f2 portare a gravi conseguenze negative. Vale la pena notare che il blocco degli account tramite tentativi di accesso errati \u00e8 una situazione simile, ma questa \u00e8 gi\u00e0 un'altra questione.<\/p>\n

    Come ho detto prima, se si consente agli utenti anonimi di reimpostare la password di qualsiasi account, semplicemente conoscendo il suo indirizzo email, si crea una situazione perfetta per un attacco di tipo \"denial of service\". Questo non \u00e8 necessariamente quello di cui siamo abituati a parlare, ma non c'\u00e8 modo pi\u00f9 veloce per bloccare l'accesso a un account rispetto a una funzione di reimpostazione password mal concepita. DoS<\/a><\/noindex>, di cui normalmente parliamo, ma non c'\u00e8 modo pi\u00f9 veloce per bloccare l'accesso a un account rispetto a una funzione di reimpostazione password mal concepita.<\/p>\n

    Il punto pi\u00f9 debole<\/h2>\n

    \nDal punto di vista della protezione di un singolo account, tutto ci\u00f2 che \u00e8 scritto sopra \u00e8 fantastico, ma devi sempre tenere a mente l'ecosistema che circonda l'account che stai proteggendo. Permettimi di fare un esempio:<\/p>\n

    ASafaWeb \u00e8 ospitato su un servizio straordinario fornito da AppHarbor. Il processo di reimpostazione dell'account di hosting avviene cos\u00ec:<\/p>\n

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

    \"Tutto
    \nFase 2:<\/strong><\/p>\n

    \"Tutto
    \nFase 3:<\/strong><\/p>\n

    \"Tutto
    \nFase 4:<\/strong><\/p>\n

    \"Tutto
    \nDopo aver letto tutte le informazioni precedenti, \u00e8 gi\u00e0 facile capire quali aspetti in un mondo ideale realizzeremmo in modo diverso. Tuttavia, qui voglio dire che se pubblicassi un sito simile a ASafaWeb sul servizio di AppHarbor, e poi inventassi ottime domande segrete e risposte, aggiungessi un secondo fattore di autenticazione e facessi tutto il resto secondo le regole, non annulla il fatto che il punto pi\u00f9 debole dell'intero processo sar\u00e0 in grado di rompere tutto questo. Se qualcuno riesce a autenticarsi con successo su AppHarbor, utilizzando le mie informazioni, potr\u00e0 cambiare la password di qualsiasi account ASafaWeb a suo piacimento!<\/p>\n

    Il significato \u00e8 che la resilienza dell'attuazione della sicurezza deve essere considerata nel suo insieme: \u00e8 necessario modellare le minacce a ciascun punto di ingresso del sistema, anche se si tratta di un processo superficiale, ad esempio l'accesso al sistema di AppHarbor. Questo dovrebbe darmi una buona idea di quanta energia devo investire nel processo di reimpostazione della password di ASafaWeb.<\/p>\n

    Mettiamo tutto insieme<\/h2>\n

    \nQuesto post contiene una grande quantit\u00e0 di informazioni, quindi voglio concentrarlo in uno schema visivo semplice:<\/p>\n

    \"Tutto
    \nRicorda di eseguire la registrazione dettagliata di ciascuno di questi punti. Ecco tutto, \u00e8 cos\u00ec semplice!<\/p>\n

    Conclusioni<\/h2>\n

    \nIl mio post sembra completo, tuttavia ci sono molti materiali aggiuntivi che io essere.<\/em> includere in esso, ma ho deciso di distaccarmene per brevit\u00e0: il ruolo dell'indirizzo email di recupero, la situazione in cui si perde accesso all'email associata all'account (ad esempio, se si lascia un lavoro) e cos\u00ec via. Come ho detto in precedenza, la funzione di reset non \u00e8 cos\u00ec complessa, ci sono solo molti punti di vista su di essa.<\/p>\n

    Anche se il reset non \u00e8 cos\u00ec difficile, spesso viene implementato in modo errato. In precedenza abbiamo visto un paio di esempi in cui l'implementazione pu\u00f2<\/em> ha portato a problemi, e ci sono molti pi\u00f9 precedenti in cui un reset errato in effetti<\/em> problemi. Recentemente \u00e8 emerso che il reset della password \u00e8 stato utilizzato per rubare bitcoin per un totale di 87 mila dollari<\/a><\/noindex>. Questo \u00e8 un serio risultato negativo!<\/p>\n

    Pertanto, prestare attenzione alle proprie funzioni di reset, modellare le minacce<\/a><\/noindex> in vari punti, e durante la progettazione della funzione non toglierti il tuo cappello nero, perch\u00e9 c'\u00e8 una grande probabilit\u00e0 che qualcun altro lo indossi!<\/p>\n

    <\/p>\n

    In base alla pubblicit\u00e0<\/h4>\n

    \nVDSina<\/b> offre opzioni economiche server in affitto<\/a><\/noindex> con pagamento giornaliero, ogni server \u00e8 connesso a un canale Internet da 500 Megabit e protetto gratuitamente da attacchi DDoS!<\/p>\n

    \"Tutto<\/a><\/noindex>
    \n
    Fonte:     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\udd47Tutto ci\u00f2 che volevi sapere sul reset sicuro delle password. Parte 2 | ProHoster","description":"Autenticazione a due fattori Tutto ci\u00f2 che hai letto nella prima parte riguardava l'identificazione basata su ci\u00f2 che.","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/97639","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=97639"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97639\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/97640"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=97639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=97639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=97639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}