{"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 quello 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

\nQuanto hai letto riguarda parte uno<\/a><\/noindex> l'identificazione basata su ci\u00f2 che sa chi fa la richiesta<\/em><\/strong>. Sa il suo indirizzo email, sa come accedervi (cio\u00e8 sa la sua password) e conosce le risposte alle domande segrete. <\/p>\n

La \u00abconoscenza\u00bb \u00e8 considerata un fattore di autenticazione; gli altri due fattori comuni sono ci\u00f2 che hai<\/em><\/strong>, come un dispositivo fisico, e ci\u00f2 che sei<\/em><\/strong>, come le impronte digitali o la retina dell'occhio.<\/p>\n

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

\"Tutto
\nIl token fisico \u00e8 frequentemente utilizzato per l'autenticazione in VPN aziendali e nei servizi finanziari. Per accedere al servizio \u00e8 necessario utilizzare sia una password che il codice del token (che cambia frequentemente) insieme a un PIN. Teoricamente, per identificarsi, un attaccante dovrebbe conoscere la password, avere il token e anche conoscere il PIN del token. In uno scenario di reset della password, la password stessa \u00e8 ovviamente sconosciuta, ma possedere il token pu\u00f2 essere utilizzato per confermare la titolarit\u00e0 dell'account. Naturalmente, come in qualsiasi implementazione di sicurezza, non fornisce una \"protezione contro gli stupidi\"<\/a><\/noindex>, ma aumenta sicuramente la barriera d'ingresso.<\/p>\n

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

\"Tutto
\n\u00c8 anche necessario includere l'autenticazione a due fattori<\/a><\/noindex>, ma questo significa che durante il prossimo reset della password il tuo telefono cellulare potrebbe diventare il secondo fattore di autenticazione. Lasciate che vi mostri questo esempio sul mio iPhone per motivi che diventeranno chiari tra poco:<\/p>\n

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

\"Tutto
\nOra dobbiamo scegliere l'inizio del processo di reset:<\/p>\n

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

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

\"Tutto
\nQuando si accede all'URL per il reset, viene inviato un SMS e il sito web chiede di inserirlo:<\/p>\n

\"Tutto
\nEcco l'SMS:<\/p>\n

\"Tutto
\nDopo averlo inserito nel browser, torniamo all'area classica per il reset della password:<\/p>\n

\"Tutto
\nProbabilmente sembra un po' verboso, ed \u00e8 cos\u00ec, ma il modulo conferma che la persona che esegue il reset ha accesso all'indirizzo email e al numero di telefono mobile del proprietario dell'account. Tuttavia, questo pu\u00f2 essere fino a nove volte pi\u00f9 sicuro rispetto al reset della password solo tramite email. Ma ci sono delle problematiche...<\/p>\n

Il problema riguarda gli smartphone. Il dispositivo mostrato qui 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 reset della password:<\/p>\n

\"Tutto
\nIl problema \u00e8 che consideriamo l'email come il primo fattore di autenticazione e gli SMS (o anche le app che generano token) come il secondo, ma oggi sono uniti in un unico dispositivo. Ci\u00f2 implica che se qualcuno ottiene accesso al tuo smartphone, tutta questa comodit\u00e0 diventa un ritorno a un singolo canale; questo secondo fattore 'qualcosa che hai' implica che hai anche il primo fattore. E tutto ci\u00f2 \u00e8 protetto da un PIN di quattro cifre\u2026 se il telefono ha un PIN. e<\/em> \u00e8 stato bloccato.<\/p>\n

S\u00ec, la funzione di autenticazione a due fattori (2FA) implementata da Google offre sicuramente una protezione aggiuntiva, ma non \u00e8 protetta 'dai meno esperti' e non dipende affatto da due canali completamente autonomi.<\/p>\n

Reset tramite nome utente contro reset tramite indirizzo email<\/h2>\n

\nDovrebbe essere consentito il reset solo tramite indirizzo email? O l'utente dovrebbe avere la possibilit\u00e0 di effettuare il reset anche tramite nome utente? Il problema del reset tramite nome utente \u00e8 che non c'\u00e8 modo di informare l'utente su un nome utente errato, senza rivelare<\/em> che qualcun altro possa avere un account con questo nome. Nella sezione precedente, il ripristino tramite email ha garantito che il legittimo proprietario di questa email riceva sempre feedback senza la divulgazione pubblica della sua esistenza nel sistema. Con solo il nome utente non \u00e8 possibile farlo.<\/p>\n

Pertanto, la risposta \u00e8 semplice: solo email. Se provi a eseguire il ripristino solo usando il nome utente, potrebbero verificarsi situazioni in cui l'utente si chieder\u00e0 cosa sia successo. o<\/em> stai rivelando l'esistenza degli account. S\u00ec, \u00e8 solo un nome utente, non un indirizzo email e s\u00ec, chiunque pu\u00f2 scegliere 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 i nomi.<\/p>\n

Cosa succede quindi quando qualcuno dimentica il proprio nome utente? Se si considera che il nome utente non \u00e8 immediatamente un indirizzo email (cosa che accade spessissimo), il processo \u00e8 simile a quello di un reset della password: inseriamo l'indirizzo email e poi inviamo un messaggio a tale indirizzo, senza rivelarne l'esistenza. L'unica differenza \u00e8 che questa volta il messaggio contiene solo il nome utente, e non un URL per il reset della password. Oppure, nell'email sar\u00e0 indicato che non esiste un account per quell'indirizzo.<\/p>\n

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

\nUn aspetto cruciale del reset delle password, e probabilmente il pi\u00f9<\/em> cruciale aspetto \u00e8 la verifica dell'identit\u00e0 della persona che sta tentando di effettuare il reset. \u00c8 davvero il legittimo proprietario dell'account, o qualcuno sta tentando di hackerarlo o creare disagi al proprietario?<\/p>\n

\u00c8 evidente che l'e-mail sia il canale pi\u00f9 comodo e comune per la verifica dell'identit\u00e0. Non \u00e8 immune da malintesi e ci sono molti casi in cui la semplice possibilit\u00e0 di ricevere e-mail all'indirizzo del proprietario dell'account non \u00e8 sufficiente se \u00e8 richiesta un'alta affidabilit\u00e0 nell'identificazione (ed \u00e8 per questo che si utilizza la 2FA). Tuttavia, quasi sempre rappresenta il punto di partenza per il processo di reimpostazione.<\/p>\n

Se l'e-mail deve svolgere un ruolo nella garanzia dell'affidabilit\u00e0, \u00e8 fondamentale assicurarsi prima di tutto che l'indirizzo e-mail sia corretto. Se qualcuno commette un errore di battitura, \u00e8 chiaro che la reimpostazione non inizier\u00e0. Il processo di verifica dell'e-mail durante la registrazione \u00e8 un metodo sicuro per controllare la validit\u00e0 dell'indirizzo. Tutti noi l'abbiamo visto in pratica: ti registri e ricevi un'e-mail con un URL unico su cui devi cliccare, confermando cos\u00ec che sei davvero il proprietario di quell'account e-mail. L'impossibilit\u00e0 di accedere al sistema fino al completamento di questo processo garantisce una motivazione per confermare l'indirizzo.<\/p>\n

Come in molti altri aspetti della sicurezza, questo modello riduce l'usabilit\u00e0 in cambio di una maggiore sicurezza in relazione alla verifica dell'identit\u00e0 dell'utente. Questo pu\u00f2 essere accettabile per un sito a cui l'utente attribuisce un alto valore e che con piacere accetterebbe un ulteriore passaggio nel processo (servizi a pagamento, banking, ecc.), ma simili misure possono allontanare l'utente se percepisce l'account come 'usa e getta' e lo usa, ad esempio, semplicemente per commentare un post.<\/p>\n

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

\n\u00c8 chiaro che ci sono motivi per un uso dannoso della funzione di reset, e i malintenzionati possono sfruttarla in diversi modi. Un semplice trucco che possiamo utilizzare per confermare la fonte della richiesta (questo trucco di solito<\/em> funziona) \u00e8 quello di aggiungere all'e-mail che offre il reset l'indirizzo IP del richiedente. 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 link \u00abfind out more\u00bb (\u00abScoprire di pi\u00f9\u00bb) porta l'utente al sito ip-adress.com<\/a><\/noindex>, fornendo informazioni come la posizione e l'organizzazione della richiesta di reset:<\/p>\n

\"Tutto
\nNaturalmente, chiunque desideri nascondere la propria identit\u00e0 ha numerosi modi per offuscare il proprio vero indirizzo IP, tuttavia questo \u00e8 un modo conveniente per fornire un parziale identificativo della richiesta e, in nella maggior parte<\/em> alcuni casi, ti dar\u00e0 un'idea sufficiente di chi sta effettuando la richiesta per il reset della password.<\/p>\n

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

\nQuesto post \u00e8 intriso di un tema \u2014 comunicazione; fornisci al proprietario dell'account quante pi\u00f9 informazioni possibile su ci\u00f2 che sta accadendo in ogni fase del processo, senza rivelare nulla che possa essere utilizzato male. Lo stesso vale anche per la situazione in cui la password \u00e8 stata effettivamente cambiata \u2014 informa il proprietario!<\/em><\/strong><\/p>\n

Le ragioni per cui una password pu\u00f2 essere cambiata possono essere due:<\/p>\n

    \n
  1. Cambio password dopo il login, perch\u00e9 l'utente desidera una nuova password<\/li>\n
  2. Reset della password senza login, perch\u00e9 l'utente l'ha dimenticata<\/li>\n<\/ol>\n

    \nSebbene questo post sia principalmente dedicato al ripristino della password, la notifica nel primo caso riduce il rischio che qualcuno modifichi la password senza il consenso del legittimo proprietario. Come pu\u00f2 accadere? Uno scenario molto comune \u00e8 il recupero della password del legittimo proprietario (una password riutilizzata, trapelata da un'altra fonte; una password ottenuta tramite keylogging; una password facile da indovinare, ecc.), dopo di che l'attaccante decide di cambiarla, bloccando cos\u00ec il proprietario. Senza una notifica via email, il vero proprietario non sar\u00e0 a conoscenza della modifica della password.<\/p>\n

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

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

    \"Tutto<\/p>\n

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

    \nLa funzione di reset della password \u00e8 allettante per gli aggressori: un attaccante desidera ottenere accesso all'account di un'altra persona o semplicemente arrecare fastidio al proprietario dell'account\/sistema. Molte delle pratiche sopra descritte riducono la probabilit\u00e0 di abusi, ma non li prevengono e sicuramente non impediranno alle persone di tentare di utilizzare la funzione in modo non autorizzato.<\/p>\n

    Per riconoscere comportamenti malevoli, 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 loggato) e praticamente tutto ci\u00f2 che pu\u00f2 aiutarti a comprendere cosa sta accadendo; sar\u00e0 molto utile in futuro. Registra nei log anche singole parti<\/em> Il processo, ad esempio, una buona funzione di reset dovrebbe includere l'inizio del reset tramite il sito web (registrare la richiesta e i tentativi di accesso per il reset con nome utente o email errati), registrare la visita al sito web all'URL di reset (comprese le tentativi di utilizzo di un token errato) e poi registrare nel log il successo o l'errore nella risposta alla domanda segreta.<\/p>\n

    Quando parlo di logging, intendo non solo registrare il fatto di aver caricato la pagina, ma anche raccogliere quante pi\u00f9 informazioni possibile, se non sono riservate<\/em><\/strong>. Ragazzi, per favore, non registrate le password nei log!<\/em><\/strong> Nei log bisogna registrare l'identit\u00e0 dell'utente autenticato (sar\u00e0 autenticato se egli cambia<\/em> una password esistente o cerca di resettare una password di qualcun altro<\/em> dopo aver effettuato il login), qualsiasi nome utente o indirizzo email provato da lui, pi\u00f9 qualsiasi token di reset che sta cercando di utilizzare. Ma \u00e8 anche utile registrare nei log aspetti come gli indirizzi IP e, se possibile, anche gli header delle richieste. Questo permette di ricreare non solo cosa<\/em> l'utente (o l'attaccante) cerca di fare, ma anche chi<\/em> \u00e8 cos\u00ec.<\/p>\n

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

    \nSe pensi che tutto ci\u00f2 rappresenti un enorme onere di lavoro, non sei solo. In realt\u00e0, costruire un sistema affidabile per la gestione degli account \u00e8 una sfida complessa. Non si tratta solo di difficolt\u00e0 tecniche, ma ci sono molte peculiarit\u00e0. Non si limita al reset, esiste un intero processo di registrazione, una conservazione sicura delle password, la gestione di molteplici tentativi di accesso errati, 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 questo ci sono molte altre cose da fare.<\/p>\n

    Oggi ci sono molti fornitori esterni che si assumono volentieri tutte queste difficolt\u00e0 e astraendo tutto ci\u00f2 in un unico servizio gestito. Tra questi servizi ci sono OpenID, OAuth e persino Facebook. Alcune persone credono senza limiti a questo modello<\/a><\/noindex> (OpenID si \u00e8 rivelato molto efficace 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 altres\u00ec certo che aggiunge nuove complessit\u00e0. Hanno un ruolo? S\u00ec, ma \u00e8 evidente che non vediamo un uso massiccio dei servizi offerti dai fornitori di autenticazione. Banche, compagnie aeree e persino negozi \u2014 tutti implementano i propri meccanismi di autenticazione, e ovviamente ci sono motivi molto validi per questo.<\/p>\n

    Reset dannoso<\/h2>\n

    \nUn aspetto importante di ciascuno degli esempi sopra citati \u00e8 che la vecchia password \u00e8 considerata inutile solo dopo la verifica dell'identit\u00e0 del proprietario dell'account<\/em><\/strong>. Questo \u00e8 importante, perch\u00e9 se l'account potesse essere resettato fino a<\/em> senza la verifica dell'identit\u00e0, si aprirebbero possibilit\u00e0 per ogni tipo di azione malevola.<\/p>\n

    Ecco un esempio: qualcuno partecipa a un'asta su un sito d'aste e, verso la fine del processo, blocca i concorrenti avviando un processo di reset, eliminandoli cos\u00ec dall'asta. \u00c8 evidente che se una funzione di reset mal progettata pu\u00f2 essere sfruttata in modo errato, ci\u00f2 pu\u00f2 portare a seri risultati negativi. \u00c8 importante notare che il blocco degli account tramite tentativi di accesso errati \u00e8 una situazione simile, ma questa \u00e8 un'altra storia.<\/p>\n

    Come ho detto prima, se si d\u00e0 agli utenti anonimi la possibilit\u00e0 di resettare la password di qualsiasi account semplicemente conoscendo l'indirizzo email, si crea una situazione ideale per un attacco di tipo \"denial of service\". Potrebbe non essere quello di cui siamo abituati a parlare, ma non esiste modo pi\u00f9 veloce per bloccare l'accesso a un account che con una funzione di reset della password mal progettata. DoS<\/a><\/noindex>, di cui parliamo generalmente, ma non esiste modo pi\u00f9 veloce per bloccare l'accesso a un account che tramite una funzione di reset della password mal progettata.<\/p>\n

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

    \nDal punto di vista della sicurezza di un account, tutto ci\u00f2 che \u00e8 stato detto sopra \u00e8 fantastico, ma bisogna sempre tenere a mente l'ecosistema che circonda l'account che si vuole proteggere. Permettetemi 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 in questo modo:<\/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 facile capire quali aspetti in un mondo ideale realizzeremmo diversamente. Tuttavia, voglio dire che se pubblicassi un sito simile a ASafaWeb sul servizio AppHarbor, e poi inventassi ottime domande e risposte segrete, aggiungessi un secondo fattore di autenticazione e facessi tutto il resto seguendo le regole, questo non annullerebbe il fatto che il punto pi\u00f9 debole dell'intero processo potrebbe romperlo. Se qualcuno riesce a effettuare l'autenticazione in AppHarbor utilizzando le mie informazioni, potrebbe cambiare la password di qualsiasi account ASafaWeb a suo piacimento!<\/p>\n

    Il concetto \u00e8 che la resilienza della protezione deve essere vista in modo olistico: bisogna modellare le minacce per ogni punto di ingresso del sistema, anche se si tratta di un processo superficiale, come l'accesso al sistema AppHarbor. Questo dovrebbe darmi una buona idea di quanti sforzi devo dedicare al processo di reimpostazione della password di ASafaWeb.<\/p>\n

    Colleghiamo tutto insieme<\/h2>\n

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

    \"Tutto
    \nRicordate di eseguire il logging il pi\u00f9 dettagliato possibile su ciascuno di questi punti. Ecco tutto, \u00e8 semplice!<\/p>\n

    Risultati<\/h2>\n

    \nIl mio post sembra completo, tuttavia ci sono molti materiali aggiuntivi che voglio potrebbe<\/em> includere, ma ho deciso di omettere per brevit\u00e0: il ruolo dell'indirizzo e-mail di recupero, la situazione in cui si perde l'accesso all'e-mail collegata all'account (ad esempio, se si \u00e8 licenziati) e cos\u00ec via. Come ho detto prima, la funzione di reset non \u00e8 cos\u00ec complicata, ci sono solo molteplici 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 causato problemi, e ci sono molti pi\u00f9 casi in cui un reset errato davvero<\/em> ha portato a problemi. Recentemente \u00e8 emerso che il reset della password \u00e8 stato utilizzato per rubare bitcoin per un valore di 87 mila dollari.<\/a><\/noindex>Questo \u00e8 un grave risultato negativo!<\/p>\n

    Quindi, siate cauti con le vostre funzioni di reset, modellate le minacce<\/a><\/noindex> in diversi punti, e quando progettate le funzioni, non togliete il vostro cappello nero, perch\u00e9 c'\u00e8 una grande possibilit\u00e0 che qualcun altro lo indossi!<\/p>\n

    <\/p>\n

    In pubblicit\u00e0<\/h4>\n

    \nVDSina<\/b> offre soluzioni economiche server in affitto<\/a><\/noindex> con pagamento giornaliero, ogni server \u00e8 collegato a un canale internet di 500 Megabit ed \u00e8 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 quello che volevi sapere sul ripristino sicuro delle password. Parte 2 | ProHoster","description":"Autenticazione a due fattori Tutto ci\u00f2 che hai letto nella prima parte riguarda l'identificazione basata su ci\u00f2 che conosce chi richiede. Sa il proprio indirizzo email, sa come accedervi (cio\u00e8 conosce la propria password) e conosce le risposte a domande segrete. La \"conoscenza\" \u00e8 considerata un fattore di autenticazione; gli altri due fattori comuni sono che possiedi","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 \u0437\u043d\u0430\u0435\u0442 \u0437\u0430\u043f\u0440\u0430\u0448\u0438\u0432\u0430\u044e\u0449\u0438\u0439. \u041e\u043d \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u0430\u0434\u0440\u0435\u0441 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b, \u0437\u043d\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u043a \u043d\u0435\u0439 \u0434\u043e\u0441\u0442\u0443\u043f (\u0442.\u0435. \u0437\u043d\u0430\u0435\u0442 \u0441\u0432\u043e\u0439 \u043f\u0430\u0440\u043e\u043b\u044c \u043e\u0442 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043f\u043e\u0447\u0442\u044b) \u0438 \u0437\u043d\u0430\u0435\u0442 \u043e\u0442\u0432\u0435\u0442\u044b \u043d\u0430 \u0441\u0435\u043a\u0440\u0435\u0442\u043d\u044b\u0435 \u0432\u043e\u043f\u0440\u043e\u0441\u044b. \u00ab\u0417\u043d\u0430\u043d\u0438\u0435\u00bb \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u043e\u0434\u043d\u0438\u043c \u0444\u0430\u043a\u0442\u043e\u0440\u043e\u043c \u0430\u0443\u0442\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u0438; \u0434\u0432\u0443\u043c\u044f \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0440\u0430\u0441\u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0451\u043d\u043d\u044b\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u044f\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u0442\u043e, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441","og:url":"https:\/\/prohoster.info\/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"},"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}]}}