Recentemente ho avuto tempo per riflettere di nuovo su come dovrebbe funzionare la funzione di reset sicuro della password, prima quando integravo questa funzionalità in , e poi quando ho aiutato un'altra persona a fare qualcosa di simile. In quest'ultimo caso, volevo dargli un link a una risorsa canonica con tutti i dettagli per implementare in modo sicuro la funzione di reset della password. Tuttavia, il problema è che una tale risorsa non esiste, almeno non una che descriva tutto ciò che ritengo importante. Così ho deciso di scriverla io stesso.
Vedete, il mondo delle password dimenticate è in realtà piuttosto misterioso. Ci sono molte diverse, del tutto accettabili opinioni e un sacco di opinioni piuttosto pericolose. È probabile che tu abbia già incontrato molte di esse come utente finale; quindi cercherò di utilizzare questi esempi per mostrare chi sta facendo tutto in modo corretto e chi no, e su cosa bisogna concentrarsi per una corretta implementazione della funzione nella propria applicazione.
Memorizzazione delle password: hashing, crittografia e (oh!) testo semplice
Non possiamo discutere di come gestire le password dimenticate prima di parlare del modo in cui vengono archiviate. Nella base di dati, le password sono conservate in uno dei tre principali modi:
- Testo semplice. C'è una colonna con la password che viene memorizzata in testo normale.
- Crittografato. Di solito usando la crittografia simmetrica (una chiave viene utilizzata sia per la crittografia che per la decrittografia), e le password crittografate sono anch'esse memorizzate in una colonna.
- Hashato. Un processo unidirezionale (la password può essere hashata, ma non può essere de-hashata); la password, si spera, è accompagnata da un sale, e ognuno di essi si trova nella propria colonna.
Affrontiamo subito la questione più semplice: non conservare mai le password in testo semplice! Mai. Una sola vulnerabilità a , un backup imprudente o uno dei tanti altri semplici errori — e tutto finisce, game over, tutte le vostre password — cioè, scusate, le password di tutti i vostri clienti diventeranno di dominio pubblico. Naturalmente, ciò comporterà un'enorme probabilità che diventino di dominio pubblico da tutti i loro account in altri sistemi. E sarà colpa vostra.
La crittografia è migliore, ma presenta le sue debolezze. Il problema della crittografia risiede nella decrittazione; si possono prendere questi codici che sembrano insensati e trasformarli di nuovo in testo semplice, e quando ciò accade, tornamo alla situazione delle password leggibili. Come avviene? Un piccolo difetto penetra nel codice responsabile della decrittazione della password, rendendolo accessibile al pubblico — questo è un modo. Gli hacker accedono alla macchina in cui sono memorizzati i dati crittografati — questo è un secondo modo. Un ulteriore modo è che viene rubato un backup del database, e qualcuno ottiene anche la chiave di crittografia, che spesso è conservata in modo molto poco sicuro.
E questo ci porta all'hashing. L'idea dell'hashing è che funzioni in un'unica direzione; l'unico modo per confrontare la password inserita dall'utente con la sua versione hashata è hashare l'input e confrontarlo. Per prevenire attacchi tramite strumenti come le "tabelle arcobaleno", introduciamo casualità nel processo tramite un sale (per completezza, leggi il mio sul storage crittografico). In definitiva, se implementato correttamente, possiamo avere un'alta certezza che le password hashate non diventino mai più testo semplice (parlerò dei vantaggi dei vari algoritmi di hashing in un altro post).
Un breve argomento su hashing e cifratura: l'unico motivo per cui potresti avere bisogno di cifrare anziché hashare una password è quando hai bisogno di vedere la password in chiaro, e non dovresti mai volerlo fare, almeno in una situazione con un sito web standard. Se hai bisogno di farlo, probabilmente stai facendo qualcosa di sbagliato!
Attenzione!
Poco più in basso nel testo del post, c'è una parte di uno screenshot del sito web pornografico AlotPorn. È stato ritagliato con cura e non c'è nulla che non si possa vedere in spiaggia, ma se ciò può comunque causare problemi, non scorrere verso il basso.
Reimposta sempre la password, mai non ricordarla mai
Ti è mai stata chiesta la funzione di promemoria della password? Fai un passo indietro e rifletti su questa richiesta: perché è necessario questo «promemoria»? Perché l'utente ha dimenticato la password. Cosa vogliamo veramente fare? Aiutarlo a rientrare nel sistema.
Capisco che la parola «promemoria» viene utilizzata (spesso) in senso colloquiale, ma in realtà stiamo cercando di aiutare l'utente a tornare online in modo sicuro.Poiché abbiamo bisogno di sicurezza, ci sono due motivi per cui un promemoria (cioè l'invio all'utente della sua password) non è appropriato:
- L'email è un canale non sicuro. Proprio come non invieremmo informazioni riservate tramite HTTP (utilizzeremmo HTTPS), non dovremmo trasmettere nulla via email, poiché il suo strato di trasporto non è sicuro. In effetti, è molto peggio che semplicemente trasmettere informazioni attraverso un protocollo di trasporto non protetto, perché le email vengono spesso salvate su un'unità, sono accessibili agli amministratori di sistema, vengono inoltrate e diffuse, e sono vulnerabili a malware, e così via. Le email non crittografate sono un canale estremamente insicuro.
- In ogni caso, non dovresti avere accesso alla password. Rileggi la sezione precedente sulla memorizzazione: dovresti avere un hash della password (con un buon sale resistente), quindi non dovresti in alcun modo essere in grado di estrarre la password e inviarla via email.
Permettimi di dimostrare il problema con un esempio : Ecco una tipica pagina di accesso:
È chiaro che il primo problema è che la pagina di accesso non si carica tramite HTTPS, e il sito offre anche di inviare la password («Send Password»). Questo potrebbe essere un esempio dell'uso colloquiale del termine menzionato, quindi facciamo un ulteriore passo e vediamo cosa succede:
Purtroppo, non sembra molto meglio; e l'email conferma la presenza del problema:
Questo ci dice due aspetti importanti di usoutdoor.com:
- Il sito non crittografa le password. Al meglio, vengono semplicemente codificate, ma è molto probabile che siano conservate in chiaro; non vediamo prove del contrario.
- Il sito invia una password a lungo termine (possiamo tornare e utilizzarla ripetutamente) attraverso un canale non sicuro.
Una volta chiarito questo, dobbiamo verificare se il processo di reset avviene in modo sicuro. Per prima cosa, è necessario assicurarsi che chi richiede abbia il diritto di eseguire il reset. In altre parole, prima di questo abbiamo bisogno di una verifica dell'identità; diamo un'occhiata a cosa succede quando l'identità è confermata senza una verifica preliminare che attesti che chi richiede sia davvero il proprietario dell'account.
L'elenco dei nomi utente e il suo impatto sull'anonimato
È meglio illustrare questo problema visivamente. Problema:
Vedi? Fai attenzione al messaggio 'There is no user registered with this email address' ("Nessun utente registrato con questo indirizzo email"). Il problema, ovviamente, si presenta se un sito simile conferma presenza un utente registrato con questo indirizzo email. Bingo: hai appena scoperto un feticismo pornografico di tuo marito/ capo/ vicino!
Naturalmente, la pornografia è un esempio piuttosto canonico dell'importanza della riservatezza, ma il rischio di associare un'identità a un determinato sito web è molto più ampio rispetto alla potenzialmente imbarazzante situazione descritta sopra. Uno dei pericoli è l'ingegneria sociale; se un aggressore riesce a collegare una persona a un servizio, avrà accesso a informazioni che potrebbe iniziare a utilizzare. Ad esempio, potrebbe contattare la persona spacciandosi per un rappresentante del sito web e richiedere ulteriori informazioni, cercando di effettuare .
Pratiche simili possono anche portare al rischio di "enumerazione degli utenti", in cui è possibile verificare l'esistenza di un'intera collezione di nomi utente o indirizzi email su un sito web attraverso semplici richieste di gruppo e analizzando le risposte. Hai un elenco di indirizzi email di tutti i dipendenti e pochi minuti per scrivere uno script? Allora ecco il problema!
Qual è l'alternativa? In realtà, è piuttosto semplice e splendidamente implementata su :
Qui Entropay non rivela affatto l'esistenza di un indirizzo email nel suo sistema a chi non detiene questo indirizzo. Se sei in possesso di questo indirizzo e non esiste nel sistema, riceverai un'email simile:
Naturalmente, ci possono essere situazioni accettabili in cui qualcuno pensa, di essersi registrato su un sito web. ma non è così, o lo ha fatto con un altro indirizzo email. L'esempio mostrato sopra gestisce efficacemente entrambe le situazioni. Ovviamente, se l'indirizzo corrisponde, riceverai una email che semplifica il ripristino della password.
La sottigliezza della scelta di Entropay sta nel fatto che la verifica dell'identità avviene tramite email prima di qualsiasi verifica online. Alcuni siti chiedono agli utenti di rispondere a una domanda segreta (maggiori dettagli su questo più avanti) fino a prima che possa iniziare il ripristino; tuttavia, il problema è che è necessario rispondere a una domanda fornendo un qualche tipo di identificazione (email o nome utente), il che rende quasi impossibile rispondere in modo intuitivo senza rivelare l'esistenza di un account anonimo.
Con questo approccio ci sono piccolo una diminuzione dell'usabilità, poiché nel caso in cui si tenti di ripristinare un account non esistente non c'è feedback immediato. Ovviamente, questo è l'intero scopo dell'invio di un'email, ma dal punto di vista dell'utente finale, se immatricola un indirizzo errato, lo scoprirà solo quando riceverà l'email. Ciò potrebbe causare una certa tensione da parte sua, ma è un piccolo prezzo da pagare per un processo così raro.
Un'altra nota, leggermente fuori tema: le funzioni di aiuto per l'accesso che rivelano la correttezza del nome utente o dell'indirizzo email presentano lo stesso problema. Rispondete sempre all'utente con il messaggio "La combinazione di nome utente e password è invalida" (Your username and password combination is invalid), invece di confermare esplicitamente l'esistenza delle informazioni di identificazione (ad esempio, "il nome utente è corretto, ma la password è errata").
Invio della password di ripristino contro invio dell'URL di ripristino
Il prossimo concetto che dobbiamo discutere riguarda il modo di ripristinare la password. Ci sono due soluzioni popolari:
- Generazione di una nuova password sul server e invio tramite email
- Invio di un'email con un URL unico che semplifica il processo di reimpostazione
Nonostante , il primo punto non dovrebbe mai essere utilizzato. Il problema è che implica la presenza di una password memorizzata, a cui si può tornare e riutilizzare in qualsiasi momento; è stata trasmessa tramite un canale non sicuro e rimane nella tua posta in arrivo. C'è il rischio che la posta in arrivo venga sincronizzata con dispositivi mobili e client di posta elettronica, oltre al fatto che potrebbe essere conservata online in un servizio di posta per un tempo molto lungo. Il succo della questione è che la tua casella di posta non può essere considerata un mezzo sicuro per la conservazione a lungo termine.
Ma oltre a ciò, il primo punto ha un altro grave problema: esso semplifica al massimo la blocco dell'account con cattive intenzioni. Se conosco l'indirizzo email di chi possiede l'account sul sito, posso bloccarlo in qualsiasi momento semplicemente reimpostando la sua password; si tratta di un attacco di tipo 'denial of service' servito su un piatto d'argento! Per questo motivo, la reimpostazione deve essere effettuata solo dopo aver verificato con successo il diritto di chi la richiede.
Quando parliamo di URL di reimpostazione, intendiamo l'indirizzo del sito web che è unico per questo specifico caso di processo di reimpostazione. Naturalmente, deve essere casuale, non deve essere facilmente decifrabile e non deve contenere link esterni all'account che semplifichino la reimpostazione. Ad esempio, l'URL di reimpostazione non dovrebbe essere semplicemente un percorso del tipo 'Reset/?username=JohnSmith'.
Vogliamo creare un token unico che possa essere inviato via email come URL di ripristino, e poi verificato con un record sul server associato all'account dell'utente, confermando in questo modo che il proprietario dell'account sia veramente la stessa persona che sta tentando di reimpostare la password. Ad esempio, il token potrebbe avere un formato come «3ce7854015cd38c862cb9e14a1ae552b» e essere memorizzato in una tabella insieme all'ID dell'utente che sta eseguendo il ripristino e al momento di generazione del token (approfondiremo questo argomento più avanti). Quando viene inviata l'email, contiene un URL del tipo «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», e quando l'utente lo carica, la pagina verifica l'esistenza del token, quindi conferma le informazioni dell'utente e consente di cambiare la password.
Naturalmente, poiché il processo descritto sopra (speriamo) consente all'utente di creare una nuova password, è necessario garantire che l'URL venga caricato tramite HTTPS. No, , questo URL con il token deve utilizzare la sicurezza del livello di trasporto, affinché non sia possibile attuare un attacco e la password generata dall'utente veniva trasmessa tramite una connessione sicura.
Inoltre, per l'URL di reset è necessario aggiungere un limite temporale al token, in modo che il processo di reset possa essere completato entro un certo intervallo, ad esempio, all'interno di un'ora. Questo garantisce che la finestra temporale del reset sia ridotta al minimo, affinché chi riceve questo URL di reset possa agire solo all'interno di questo brevissimo lasso di tempo. Naturalmente, l'attaccante potrebbe avviare nuovamente il processo di reset, ma avrà bisogno di ottenere un altro URL di reset unico.
Infine, dobbiamo garantire l'unicità di questo processo. Una volta completato il processo di reset, il token deve essere rimosso affinché l'URL di reset non sia più funzionante. Il punto precedente è necessario affinché l'attaccante abbia una finestra temporale molto ristretta durante la quale può manipolare l'URL di reset. Inoltre, chiaramente, dopo il completamento riuscito del reset, il token non è più necessario.
Alcuni di questi passaggi possono sembrare eccessivi, ma non compromettono affatto l'usabilità e in realtà aumentano la sicurezza, anche se in situazioni che, speriamo, saranno rare. Nel 99% dei casi, l'utente eseguirà il reset in un breve lasso di tempo e non resetterà la password di nuovo nel prossimo futuro.
Il ruolo del CAPTCHA
Oh, CAPTCHA, uno strumento di protezione che tutti noi amiamo odiare! In realtà, il CAPTCHA non è tanto uno strumento di protezione, quanto di identificazione: sei un umano o un robot (o uno script automatizzato). Il suo scopo è evitare l'invio automatico di moduli, il che, naturalmente, può può essere tentato come tentativo di violare la sicurezza. Nel contesto del reset delle password, il CAPTCHA significa che la funzione di reset non potrà essere violata tramite forzature brute, per spammerare l'utente o cercare di determinare l'esistenza di account (cosa che, naturalmente, sarà impossibile se hai seguito i consigli nella sezione sulla verifica dell'identità).
Naturalmente, il CAPTCHA stesso non è perfetto; ci sono molti precedenti di "violazioni" software e di tassi di successo sufficienti (60-70%). Inoltre, esiste una soluzione, mostrata nel mio post su , dove è possibile pagare le persone frazioni di centesimo per risolvere ogni CAPTCHA e ottenere un tasso di successo del 94%. Quindi è vulnerabile, ma (leggermente) alza la barriera all'ingresso.
Diamo un'occhiata a un esempio di PayPal:
In questo caso, il processo di reset non può semplicemente iniziare fino a quando non viene risolto il CAPTCHA, quindi teoricamente automatizzare il processo è impossibile. Teoricamente.
Tuttavia, per la maggior parte delle applicazioni web, questo sarebbe eccessivo e sicuramente rappresenta una diminuzione della fruibilità — le persone semplicemente non amano i CAPTCHA! Inoltre, i CAPTCHA sono qualcosa a cui si può facilmente tornare se necessario. Se un servizio inizia a essere attaccato (qui entra in gioco il logging, ma ne parleremo più avanti), aggiungere il CAPTCHA è molto semplice.
Domande e risposte segrete
In tutti i metodi che abbiamo considerato, siamo stati in grado di resettare la password avendo solo accesso all'account di posta elettronica. Dico "solo", ma naturalmente ottenere illegalmente l'accesso all'account email di qualcun altro deve può essere un processo complicato. Tuttavia, .
In realtà, il link sopra menzionato riguardo l'hacking dell'account di Sarah Palin su Yahoo! serve a due scopi; in primo luogo, illustra quanto possa essere facile hackerare (alcuni) account di posta elettronica, in secondo luogo, mostra come si possano usare a malafede brutti segreti di sicurezza. Ma torneremo su questo più tardi.
Il problema con il reset delle password che si basa completamente sull'email è che l'integrità dell'account del sito di cui stai cercando di eseguire il reset diventa totalmente dipendente dall'integrità dell'account email. Chiunque abbia accesso alla tua email, ha accesso a qualsiasi account che può essere resettato semplicemente ricevendo un'email. Per tali account, l'email è la «chiave di tutte le porte» della tua vita online.
Uno dei modi per ridurre questo rischio è implementare un modello di domanda e risposta segreta. Senza dubbio, hai già visto questi: scegli una domanda a cui solo tu devono conoscere la risposta, dopo di che, durante il reset della password, ti viene chiesta. Questo aumenta la certezza che la persona che sta cercando di effettuare il reset sia realmente il proprietario dell'account.
Torniamo a Sarah Palin: l'errore è stato che le risposte alle sue domande segrete erano facilmente reperibili. In particolare, quando sei una figura pubblica così significativa, informazioni come il cognome da nubile della madre, la storia scolastica o dove qualcuno potrebbe aver vissuto in passato non sono affatto segrete. Infatti, gran parte di esse può essere recuperata praticamente da chiunque. E così è successo con Sarah:
L'hacker David Kernell ha avuto accesso all'account di Palin, trovando dettagli della sua biografia, come l'università e la data di nascita, e poi utilizzando la funzione di recupero delle password dimenticate degli account Yahoo!.
In primo luogo, si tratta di un errore di progettazione da parte di Yahoo! - ponendo domande così semplici, l'azienda ha sostanzialmente sabotato il valore della domanda segreta, e quindi la sicurezza del proprio sistema. Ovviamente, il ripristino della password dell'account e-mail è sempre più complicato, poiché non puoi confermare la proprietà inviando un'email al proprietario (senza avere un secondo indirizzo), ma fortunatamente, oggi ci sono pochi modi per implementare un sistema del genere.
Torniamo alle domande segrete - esiste la possibilità di consentire all'utente di creare le proprie domande. Il problema è che il risultato saranno domande terribilmente ovvie:
Di che colore è il cielo?
Domande che mettono le persone in difficoltà quando la domanda segreta viene utilizzata per l'identificazione: una persona (ad esempio, in un call center):
Con chi ho passato il Natale?
Oppure domande francamente stupide:
Come si scrive 'password'?
Quando si tratta di domande segrete, gli utenti devono essere salvati da se stessi! In altre parole, la domanda segreta dovrebbe essere definita dal sito stesso, e ancora meglio, porre una serie domande segrete, da cui l'utente può scegliere. E non solo scegliere uno; idealmente, l'utente dovrebbe scegliere due o più domande segrete al momento della registrazione dell'account, che saranno poi utilizzate come secondo canale di identificazione. Avere più domande aumenta la fiducia nel processo di verifica, offre anche un tocco di casualità (non mostrare sempre la stessa domanda) e garantisce un po' di ridondanza nel caso in cui l'utente reale abbia dimenticato la password.
Quali caratteristiche dovrebbe avere una buona domanda segreta? Ci sono diversi fattori da considerare:
- Deve essere breve — la domanda deve essere chiara e inequivocabile.
- La risposta deve essere specifica — non abbiamo bisogno di una domanda a cui una persona può rispondere in modi diversi
- Le risposte possibili devono essere variegate — una domanda sul colore preferito di qualcuno offre un numero molto limitato di risposte possibili
- Ricerca la risposta deve essere complessa — se la risposta è facilmente reperibile qualunque (pensiamo alle persone in posizioni elevate), allora è inadeguata
- La risposta deve essere periodo nel tempo — se si chiede qual è il film preferito di qualcuno, dopo un anno la risposta potrebbe essere diversa
Come spesso accade, esiste un sito web dedicato a buone domande, chiamato . Alcune domande sembrano abbastanza buone, altre non superano i criteri sopra menzionati, in particolare il test della "facilità di ricerca".
Permettetemi di dimostrare come vengono implementate le domande segrete in PayPal e, in particolare, quali sforzi fa il sito per identificarsi. Prima abbiamo visto la pagina di avvio del processo (con CAPTCHA), e qui mostreremo cosa succede dopo aver inserito l'indirizzo email e risolto il CAPTCHA:
Di conseguenza, l'utente riceve un'email del genere:
Finora tutto sembra abbastanza normale, ma ecco cosa si cela dietro questo URL di reset:
Quindi, entrano in gioco le domande segrete. In effetti, PayPal consente anche di ripristinare la password confermando il numero della carta di credito, quindi c'è un canale aggiuntivo a cui non hanno accesso molti siti. Non posso semplicemente cambiare la password senza rispondere a entrambe domande segrete (o non conoscere il numero di carta). Anche se qualcuno riesce ad accedere alla mia email, non potrà reimpostare la password del mio account PayPal se non conosce un po' di più informazioni personali su di me. Quali informazioni? Ecco le opzioni di domande segrete offerte da PayPal:
La domanda su scuola e ospedale potrebbe sembrare un po' dubbiosa in termini di facilità di ricerca, ma le altre non sono male. Tuttavia, per migliorare la sicurezza, PayPal richiede un'ulteriore identificazione per modifiche le risposte alle domande segrete:
PayPal è un esempio piuttosto utopico di una sicurezza per la reimpostazione della password: implementa CAPTCHA per ridurre il rischio di attacchi di forza bruta, richiede due domande segrete e poi richiede un altro tipo di identificazione totalmente differente solo per cambiare le risposte — e questo dopo che l'utente ha già effettuato il login. Ovviamente, proprio questo ci aspettavamo da PayPal; è un'organizzazione finanziaria che gestisce grandi somme di denaro. Ciò non significa che ogni reimpostazione della password debba seguire questi passaggi — nella maggior parte dei casi sarebbe eccessivo — tuttavia è un buon esempio per situazioni in cui la sicurezza è un affare serio. di PayPal; è un'organizzazione finanziaria che gestisce grandi somme di denaro. Questo non significa che ogni ripristino della password debba seguire questi passaggi—nella maggior parte dei casi sarebbe eccessivo—ma è un buon esempio per situazioni in cui la sicurezza è una questione seria.
Il vantaggio del sistema delle domande segrete è che, se non l'hai implementato immediatamente, puoi aggiungerlo in un secondo momento se il livello di protezione del servizio lo richiede. Un buon esempio di questo è Apple, che ha introdotto di recente questo meccanismo. [articolo scritto nel 2012]. Iniziando a aggiornare un'app sul mio iPad, ho visto la seguente richiesta:
Successivamente, ho visto una schermata in cui era possibile scegliere tra diverse coppie di domande segrete e risposte, oltre a un indirizzo e-mail di recupero:
Per quanto riguarda PayPal, le domande sono selezionate in anticipo e alcune sono davvero abbastanza buone:
Ciascuna delle tre coppie di domande e risposte rappresenta un insieme distintivo di possibili domande, quindi ci sono molteplici modi per configurare l'account.
Un altro aspetto da considerare riguardo alla risposta alla domanda segreta è la memorizzazione. Avere il valore in chiaro nel database comporta quasi gli stessi rischi che si hanno con le password, ovvero una violazione del database rivela immediatamente il valore e mette a rischio non solo l'applicazione, ma potenzialmente anche altre applicazioni che utilizzano le stesse domande segrete (questo di nuovo ). Una delle soluzioni è l'hashing sicuro (un algoritmo robusto e un sale crittograficamente casuale), tuttavia, a differenza della maggior parte dei casi di memorizzazione delle password, qui potrebbe esserci una giustificabile ragione per la visibilità della risposta in chiaro. Uno scenario tipico è la verifica dell'identità da parte di un operatore dal vivo al telefono. Naturalmente, anche in questo caso l'hashing è applicabile (l'operatore può semplicemente inserire la risposta fornita dal cliente), ma nel caso peggiore la risposta segreta dovrebbe trovarsi a qualche livello di memorizzazione crittografica, anche se si tratta semplicemente di cifratura simmetrica. In sintesi: tratta i segreti come segreti!
L'ultimo aspetto delle domande e risposte segrete è che sono più vulnerabili all'ingegneria sociale. Tentare di estrarre direttamente la password di un account altrui è una cosa, ma avviare una conversazione sulla sua formazione (una comunissima domanda segreta) è completamente diverso. In effetti, è del tutto possibile conversare con qualcuno riguardo a molti aspetti della sua vita che potrebbero rappresentare una domanda segreta, senza destare sospetti. Ovviamente, l'essenza stessa della domanda segreta è che essa è legata all'esperienza di vita di qualcuno, il che la rende memorabile, ed è proprio qui che risiede il problema — le persone amano raccontare la propria esperienza di vita! C'è poco da fare a riguardo, se non scegliere opzioni di domande segrete che possano essere estratte con minor probabilità tramite ingegneria sociale.
[Продолжение следует.]
In pubblicità
VDSina offre server affidabili , ogni server è collegato a una connessione Internet da 500 Megabit e protetto gratuitamente da attacchi DDoS!
Fonte: habr.com
