Recentemente ho avuto tempo per riflettere di nuovo su come dovrebbe funzionare la funzione di ripristino sicuro della password, prima quando ho integrato questa funzionalità in , e poi quando ho aiutato a realizzare qualcosa di simile a un'altra persona. In quest'ultimo caso, volevo dargli un link a una risorsa canonica con tutti i dettagli sull'implementazione sicura della funzione di ripristino. Tuttavia, il problema è che tale risorsa non esiste, almeno non una che descriva tutto ciò che considero importante. Così ho deciso di scriverla io stesso.
Vedete, il mondo delle password dimenticate è in realtà piuttosto misterioso. Ci sono molte diverse e assolutamente accettabili opinioni e una serie di punti di vista piuttosto pericolosi. È probabile che con ognuna di esse abbiate avuto molte esperienze come utenti finali; perciò cercherò di utilizzare questi esempi per mostrare chi fa tutto correttamente e chi no, e su cosa bisogna concentrarsi per implementare correttamente la funzione nella propria applicazione.
Archiviazione delle password: hashing, crittografia e (oh!) testo semplice
Non possiamo discutere su cosa fare con le password dimenticate prima di discutere su come vengono archiviate. Nelle basi di dati, le password sono archiviate in uno dei tre principali modi:
- Testo semplice. C'è una colonna con la password che è memorizzata in testo normale.
- Crittografata. Di solito mediante crittografia simmetrica (una chiave viene usata sia per la crittografia che per la decrittografia), e le password crittografate sono anche archiviate in una colonna.
- Hashata. Un processo unidirezionale (la password può essere hashata, ma non de-hashata); la password, si spera, è accompagnata da un sale, e ciascuno di essi si trova nella propria colonna.
Facciamo subito chiarezza su una domanda molto semplice: non archiviare mai le password in testo semplice! Mai. Un'unica vulnerabilità a , un backup fatto inconsapevolmente o uno dei decine di altri errori semplici — e tutto, game over, tutte le vostre password — voglio dire, scusate, le password di tutti i vostri clienti diventeranno di dominio pubblico. Naturalmente, ciò comporterebbe una enorme probabilità che diventino di dominio pubblico per tutti i loro account in altri sistemi. E questo sarà colpa vostra.
La crittografia è migliore, ma ha le sue debolezze. Il problema della crittografia riguarda la decrittazione; è possibile prendere questi crittogrammi dall'aspetto folle e riconvertirli in testo semplice, e quando ciò accade, ci ritroviamo di fronte a una situazione con password leggibili. Come avviene? Un piccolo difetto penetra nel codice che si occupa della decrittazione della password, rendendola pubblicamente accessibile — questo è uno dei modi. Gli hacker ottengono accesso alla macchina in cui sono memorizzati i dati crittografati — questo è il secondo modo. Un altro modo, di nuovo, consiste nel rubare un backup del database, e qualcuno ottiene anche la chiave di crittografia, che spesso è conservata in modo molto inaffidabile.
E questo ci porta all'hashing. L'idea dell'hashing è che avviene in un'unica direzione; l'unico modo per confrontare la password inserita dall'utente con la sua versione hashata è hashare l'input e confrontarli. Per evitare attacchi con strumenti come le 'tabelle arcobaleno', introduciamo dell'imprevedibilità nel processo utilizzando il sale (per una visione completa leggi il mio sull'archiviazione crittografica). In definitiva, se implementato correttamente, possiamo ritenere con un buon grado di certezza che le password hashate non diventeranno mai più testo semplice (parlerò dei vantaggi di diversi algoritmi di hashing in un altro post).
Un breve argomento sull'hashing e la crittografia: l'unico motivo per cui potresti avere mai bisogno di crittografare, piuttosto che hashare una password è quando hai bisogno di vedere la password in formato semplice, e non dovresti mai desiderarlo, almeno in una situazione con un sito web standard. Se hai bisogno di farlo, è probabile che tu stia facendo qualcosa di sbagliato!
Attenzione!
Poco più in basso nel post c'è una parte di uno screenshot di un sito web pornografico AlotPorn. È stato ritagliato con cura, e non c'è nulla di così scandaloso da non poter essere visto in spiaggia, ma se questo comunque può creare problemi, allora non scorrere verso il basso.
Ripristina sempre la password, mai ricordarla
Ti è mai stato chiesto di creare una funzione di promemoria La password? Fai un passo indietro e rifletti su questa richiesta al contrario: perché è necessario questo "promemoria"? Perché l'utente ha dimenticato la password. Cosa vogliamo davvero fare? Aiutarlo a rientrare nel sistema.
Capisco che la parola "promemoria" venga usata (spesso) in modo colloquiale, ma in realtà stiamo cercando di aiutare l'utente a tornare online in modo sicuro. Poiché ci serve sicurezza, ci sono due motivi per cui un promemoria (cioè l'invio della password all'utente) non è appropriato:
- L'email è un canale insicuro. Proprio come non invieremmo nulla di riservato via HTTP (utilizzeremmo HTTPS), non dovremmo inviare nulla via email, poiché il suo livello di trasporto non è sicuro. In effetti, è molto peggio della semplice trasmissione di informazioni tramite un protocollo di trasporto non protetto, poiché le email sono spesso salvate su supporto, accessibili agli amministratori di sistema, inoltrate e diffuse, disponibili a malware e così via. Le email non criptate sono un canale estremamente insicuro.
- In ogni caso non dovresti avere accesso alla password. Rileggi la sezione precedente sullo stoccaggio: dovresti avere un hash della password (con un buon sale robusto), cioè non dovresti essere in grado di recuperare la password e inviarla via email.
Lascia che ti dimostri il problema con un esempio : Ecco una tipica pagina di login:
Chiaramente, il primo problema è che la pagina di accesso non viene caricata tramite HTTPS, ma il sito offre anche di inviare la password ("Invia Password"). Potrebbe essere un esempio dell'uso colloquiale del termine sopra menzionato, quindi facciamo un ulteriore passo e vediamo cosa succede:
Sfortunatamente, non sembra molto meglio; e l'email conferma l'esistenza del problema:
Questo ci dice due aspetti importanti di usoutdoor.com:
- Il sito non esegue l'hashing delle password. Al massimo, vengono criptate, ma molto probabilmente vengono memorizzate in chiaro; non vediamo prove contrarie.
- Il sito invia una password a lungo termine (possiamo tornare e usarla ripetutamente) attraverso un canale non protetto.
Dopo aver chiarito questo, dobbiamo verificare se il processo di reset viene eseguito in modo sicuro. La prima cosa da fare è accertarsi che il richiedente abbia il diritto di eseguire il reset. In altre parole, abbiamo bisogno di una verifica dell'identità; vediamo cosa succede quando l'identità viene confermata senza un controllo preliminare su chi sia realmente il richiedente dell'account.
Elenco dei nomi degli utenti e il suo impatto sull'anonimità
Questo problema è meglio illustrarlo 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 di un utente registrato con questo indirizzo email. Bingo: hai appena scoperto il fetish porno di tuo marito / capo / vicino!
Naturalmente, il porno è un esempio piuttosto canonico dell'importanza della privacy, ma il pericolo di associare un'identità a un determinato sito web è molto più ampio della situazione potenzialmente imbarazzante descritta sopra. Uno dei pericoli è l'ingegneria sociale; se un aggressore riesce a collegare una persona a un servizio, avrà accesso a informazioni che potrà iniziare a utilizzare. Ad esempio, potrebbe contattare la persona spacciandosi per un rappresentante del sito web e richiedere ulteriori informazioni, cercando di attuare .
Esempi di tali pratiche portano anche al rischio di «enumerazione dei nomi degli utenti», dove è possibile verificare l'esistenza su un sito web di un'intera collezione di nomi utente o indirizzi email con semplici richieste di gruppo e studiando le risposte. Hai una lista di indirizzi email di tutti i dipendenti e alcuni minuti per scrivere uno script? Allora è chiaro quale sia il problema!
Qual è dunque l'alternativa? In realtà, è piuttosto semplice, e meravigliosamente implementata su :
Qui Entropay non rivela assolutamente nulla sull'esistenza del proprio indirizzo email nel sistema a chi non possiede tale indirizzo. Se tu possiedi se questo indirizzo non esiste nel sistema, riceverai un'email simile:
Naturalmente, ci possono essere situazioni accettabili in cui qualcuno pensa, di essersi registrato sul sito web. ma non è così, oppure lo ha fatto con un altro indirizzo email. L'esempio mostrato sopra gestisce entrambe le situazioni in modo efficace. Ovviamente, se l'indirizzo corrisponde, riceverai un'email che semplifica il reset della password.
La finezza della soluzione selezionata di Entropay è che la verifica dell'identità avviene tramite email prima di qualsiasi verifica online. Alcuni siti chiedono agli utenti di rispondere a una domanda segreta (di seguito maggiori dettagli) fino a di come possa iniziare il reset; tuttavia, il problema è che è necessario rispondere alla domanda fornendo una forma di identificazione (email o nome utente), rendendo poi quasi impossibile rispondere in modo intuitivo senza rivelare l'esistenza di un conto utente anonimo.
Con questo approccio c'è una leggera diminuzione dell'usabilità, poiché in caso di tentativo di reset di un conto inesistente non c'è feedback immediato. Naturalmente, questo è il senso dell'invio dell'email, ma dal punto di vista di un utente finale vero e proprio, se inserisce un indirizzo errato, lo scoprirà solo ricevendo l'email. Questo può generare un certo livello di ansia da parte sua, ma è un piccolo prezzo da pagare per un processo così raro.
Un'altra nota, leggermente fuori tema: le funzionalità di aiuto per l'accesso, che rivelano la validità del nome utente o dell'indirizzo email, presentano lo stesso problema. Rispondi sempre all'utente con un messaggio "Combinazione nome utente e password non valida" (Your username and password combination is invalid), piuttosto che confermare esplicitamente l'esistenza delle informazioni di identificazione (ad esempio, "il nome utente è corretto, ma la password è errata").
Invio della password di reset contro invio dell'URL di reset
Il concetto successivo che dobbiamo discutere riguarda il modo in cui si effettua il reset della password. Ci sono due soluzioni popolari:
- Generazione di una nuova password sul server e invio via email
- Invio di un'email con un URL unico che semplifica il processo di reset
Nonostante , il primo punto non deve mai essere utilizzato. Il suo problema è che implica la presenza di una password salvata, alla quale si può tornare e riutilizzare in qualsiasi momento; è stata trasmessa tramite un canale non sicuro e rimane nelle vostre mail in arrivo. C'è la possibilità che le mail in arrivo siano sincronizzate con dispositivi mobili e client di posta elettronica, e possono rimanere online in un servizio di posta elettronica per molto tempo. La questione è che la 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 serio problema: esso semplifica al massimo la possibilità di bloccare un account con cattive intenzioni. Se conosco l'indirizzo e-mail di chi possiede un account su un sito web, posso bloccarlo in qualsiasi momento, semplicemente resettando la sua password; si tratta di un attacco di tipo 'denial of service', servito su un piatto d'argento! È per questo che il reset deve essere eseguito solo dopo la verifica del diritto di richiesta.
Quando parliamo di URL di reset, ci riferiamo all'indirizzo web che è unico per questo specifico caso di reset. Ovviamente, deve essere casuale, non deve essere facilmente indovinabile e non deve contenere alcun link esterno all'account che semplifichi il reset. Ad esempio, l'URL di reset non deve essere semplicemente un percorso come 'Reset/?username=JohnSmith'.
Vogliamo creare un token unico da inviare via email come URL di reset, e poi confrontarlo con il record sul server per l'account utente, confermando così che il proprietario dell'account è davvero la stessa persona che sta tentando di resetare la password. Ad esempio, il token potrebbe essere '3ce7854015cd38c862cb9e14a1ae552b' e essere memorizzato in una tabella insieme all'ID utente che esegue il reset e all'orario di generazione del token (ne parleremo più avanti). Quando inviamo un'email, essa contiene un URL come 'Reset/?id=3ce7854015cd38c862cb9e14a1ae552b', e quando l'utente lo carica, la pagina verifica l'esistenza del token, conferma poi 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 il caricamento dell'URL tramite HTTPS. No, , questo URL con il token deve utilizzare la sicurezza del livello di trasporto, affinché non sia possibile attaccare il modulo per l'inserimento della nuova password e la password creata dall'utente venga trasmessa tramite una connessione sicura.
Inoltre, per l'URL di ripristino è necessario aggiungere un limite di tempo per il token, affinché il processo di ripristino possa essere completato entro un intervallo di tempo definito, ad esempio, entro un'ora. Questo garantisce che la finestra di tempo per il ripristino sia minima, in modo che chi riceve questo URL di ripristino possa agire solo all'interno di questa ristretta finestra. Naturalmente, un attaccante può avviare nuovamente il processo di ripristino, ma avrà bisogno di ottenere un altro URL di ripristino unico.
Infine, dobbiamo garantire che questo processo sia monouso. Una volta completato il processo di ripristino, il token deve essere rimosso, affinché l'URL di ripristino non sia più funzionante. Il punto precedente è necessario affinché l'attaccante abbia una finestra di tempo molto ristretta durante la quale può manipolare l'URL di ripristino. Inoltre, naturalmente, dopo un completamento riuscito del ripristino, il token non è più necessario.
Alcuni di questi passaggi possono sembrare eccessivi, ma non influenzano affatto l'usabilità e è davvero aumentano la sicurezza, anche se in situazioni che, speriamo, saranno rare. Nel 99% dei casi, l'utente attiverà il ripristino in un intervallo di tempo molto breve e non ripristinerà la password di nuovo nel prossimo futuro.
Il ruolo del CAPTCHA
Oh, CAPTCHA, lo strumento di protezione che tutti noi amiamo odiare! In realtà, il CAPTCHA è uno strumento non tanto di protezione, quanto di identificazione: sei un uomo o un robot (o uno script automatizzato). Il suo scopo è evitare l'invio automatico di moduli, che, naturalmente, può verrebbe utilizzato come tentativo di violazione della sicurezza. Nel contesto del ripristino delle password, il CAPTCHA significa che la funzione di ripristino non sarà possibile hackerare tramite un attacco di forza bruta per poi spammare l'utente o tentare di determinare l'esistenza di account (cosa che, naturalmente, sarà impossibile se hai seguito i consigli nella sezione sull'identificazione).
Naturalmente, la CAPTCHA da sola non è perfetta; ci sono molti precedenti di 'hackeraggio' software e tassi di successo sufficientemente elevati (60-70%). Inoltre, c'è una soluzione che ho mostrato nel mio post su , in cui è possibile pagare le persone pochi centesimi per risolvere ogni CAPTCHA e ottenere un tasso di successo del 94%. Quindi è vulnerabile, ma (leggermente) aumenta la barriera d'ingresso.
Diamo un'occhiata all'esempio di PayPal:
In questo caso, il processo di reset non può semplicemente iniziare fino a quando non viene risolta la CAPTCHA, quindi teoricamente automazione del processo è impossibile. Teoricamente.
Tuttavia, per la maggior parte delle applicazioni web, questo sarebbe eccessivo e assolutamente rappresenta una diminuzione della usabilità: alla gente semplicemente non piace la CAPTCHA! Inoltre, la CAPTCHA è una di quelle cose a cui si può tornare facilmente, se necessario. Se il servizio inizia a subire attacchi (qui entra in gioco il logging, ma ne parlerò più tardi), aggiungere la CAPTCHA è molto semplice.
Domande e risposte segrete
Con tutti i metodi esaminati, abbiamo potuto resettare la password semplicemente avendo accesso all'account di posta elettronica. Dico 'semplicemente', ma, naturalmente, ottenere illegalmente l'accesso all'account di posta di qualcun altro dovrebbe essere un processo difficile. Tuttavia .
In effetti, il link sopra sull'hackeraggio dell'account di Sarah Palin su Yahoo! serve a due scopi; prima di tutto, illustra quanto sia facile hackerare (alcuni) account email, e in secondo luogo, mostra come si possano utilizzare domande segrete cattive per intenti malevoli. Ma torneremo su questo più tardi.
Il problema con il reset delle password che dipende completamente dall'email è che l'integrità dell'account del sito di cui stai cercando di reimpostare la password diventa completamente dipendente dall'integrità dell'account email. Chiunque abbia accesso alla tua email ha accesso a qualsiasi account che può essere ripristinato 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 è l'implementazione del modello di domanda e risposta segreta. Sicuramente, li avete già visti: scegliete una domanda a cui solo voi dovete conoscere la risposta, dopo di che vi viene posta durante il ripristino della password. Questo aumenta la certezza che la persona che sta tentando di eseguire il ripristino sia effettivamente il proprietario dell'account.
Ritorniamo a Sarah Palin: l'errore è stato che le risposte alle sue domande segrete erano facilmente reperibili. In particolare, quando si è una figura pubblica così importante, le informazioni sul cognome da nubile della madre, sulla storia educativa o su dove qualcuno potrebbe aver vissuto in passato non sono affatto segrete. In effetti, gran parte di esse può essere trovata praticamente da chiunque. Così è successo con Sarah:
L'hacker David Kernell ha ottenuto 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 per gli account Yahoo!.
In primo luogo, si tratta di un errore di progettazione da parte di Yahoo! — ponendo domande così semplici, l'azienda ha praticamente sabotato il valore della domanda segreta e, quindi, la sicurezza del proprio sistema. Naturalmente, il ripristino delle password per un'email è sempre più complicato, poiché non puoi confermare la proprietà inviando un'email al proprietario (senza avere un secondo indirizzo), ma, per fortuna, oggi non ci sono molte applicazioni per creare un sistema del genere.
Ritorniamo alle domande segrete: esiste la possibilità di permettere all'utente di creare le proprie domande. Il problema è che ne derivano domande terribilmente ovvie:
Di che colore è il cielo?
Domande che mettono le persone in imbarazzo, quando per identificare si usa una domanda segreta che coinvolge una persona (ad esempio, in un call center):
Con chi ho passato la notte di Natale?
O domande francamente stupide:
Come si scrive ‘password’?
Quando si tratta di domande segrete, gli utenti devono essere protetti da se stessi! In altre parole, la domanda segreta dovrebbe essere definita dal sito stesso, e ancora meglio, porre una serie di domande segrete tra cui l'utente può scegliere. E non deve solo scegliere una; 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 il livello di fiducia nel processo di verifica e fornisce anche la possibilità di aggiungere casualità (non mostrare sempre la stessa domanda), oltre a garantire un po' di ridondanza nel caso in cui l'utente legittimo dimentichi la password.
Qual è quindi una buona domanda segreta? Ci sono diversi fattori che influenzano questa scelta:
- Deve essere breve — la domanda deve essere chiara e univoca.
- La risposta deve essere specifica — non vogliamo una domanda a cui una persona può rispondere in modi diversi.
- Le possibili risposte devono essere diverse — una domanda sul colore preferito di qualcuno offre un sottoinsieme molto ridotto di possibili risposte.
- Ricerca la risposta deve essere complessa — se la risposta può essere facilmente trovata da chiunque (pensiamo a persone in posizioni elevate), allora è negativa.
- La risposta deve essere deve essere costante nel tempo — se si chiede 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 piuttosto valide, altre non superano parte dei test sopra descritti, in particolare il controllo di "facilità di ricerca".
Lasciate che vi mostri come le domande segrete sono implementate in PayPal e, in particolare, quali sforzi il sito impiega per l'identificazione. Prima abbiamo visto la pagina che inizia il processo (con CAPTCHA), qui mostreremo cosa succede dopo aver inserito l'indirizzo e-mail e risolto il CAPTCHA:
Di conseguenza, l'utente riceve una e-mail del genere:
Finora tutto sembra piuttosto normale, ma ecco cosa si cela dietro questo URL di reset:
Così, entrano in gioco le domande segrete. In realtà, PayPal consente anche di reimpostare la password, confermando il numero della carta di credito, quindi esiste un canale aggiuntivo non accessibile da molti siti. Non posso semplicemente cambiare la password senza rispondere a entambe le domande segrete (o non conoscendo il numero della carta). Anche se qualcuno dovesse accedere alla mia e-mail, non potrebbe reimpostare la password del mio account PayPal se non sa un po' di più su di me. Quale informazione? Ecco le opzioni delle domande segrete proposte da PayPal:
La questione della scuola e dell'ospedale può sembrare leggermente incerta in termini di facilità di ricerca, ma gli altri non sono così male. Tuttavia, per aumentare la sicurezza PayPal richiede un'identificazione aggiuntiva per cambiamenti le risposte a domande segrete:
PayPal è un esempio piuttosto utopico di un recupero sicuro 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 completamente diverso solo per cambiare le risposte — e questo dopo che l'utente ha già effettuato l'accesso. Ovviamente, ci si aspettava proprio questo da PayPal; questo è ciò che ci si aspetta da PayPal; è un'istituzione finanziaria che gestisce grandi somme di denaro. Questo non significa che ogni recupero di password debba seguire questi passaggi — nella maggior parte dei casi, è eccessivo — tuttavia, è un buon esempio per le situazioni in cui la sicurezza è un affare serio.
Il vantaggio del sistema delle domande segrete è che, se non l'hai attuato subito, puoi aggiungerlo successivamente, se il livello di protezione delle risorse lo richiede. Un buon esempio è Apple, che ha implementato questo meccanismo solo di recente [articolo scritto nel 2012]. Una volta iniziato ad aggiornare l'app sul mio iPad, ho visto la seguente richiesta:
Poi ho visto uno schermo dove potevo scegliere tra diverse coppie di domande segrete e risposte, oltre a un indirizzo email di recupero:
Per quanto riguarda PayPal, le domande sono selezionate in anticipo e alcune di esse sono davvero piuttosto buone:
Ciascuna delle tre coppie di domande e risposte rappresenta un insieme separato di possibili domande, quindi ci sono abbastanza modi per configurare l'account.
Un altro aspetto da considerare riguardo alla risposta a una domanda segreta è lo storage. La presenza in DB di testo semplice presenta quasi le stesse minacce di un password, poiché 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 (è di nuovo ). Una delle opzioni è l'hashing sicuro (un algoritmo resistente e un sale crittograficamente casuale), tuttavia, a differenza della maggior parte dei casi di memorizzazione delle password, qui potrebbe esserci una valida ragione per la visibilità della risposta come testo semplice. Uno scenario tipico è la verifica dell'identità da parte di un operatore dal vivo al telefono. Naturalmente, in questo caso si può applicare anche l'hashing (l'operatore può semplicemente inserire la risposta fornita dal cliente), ma nel peggiore dei casi, la risposta segreta deve trovarsi a qualche livello di archiviazione crittografica, anche se si tratta semplicemente di crittografia simmetrica. In sintesi: trattate i segreti come segreti!
E l'ultimo aspetto delle domande e risposte segrete è che sono più vulnerabili all'ingegneria sociale. Cercare di estorcere direttamente la password di un altro account è una cosa, mentre instaurare una conversazione sul suo percorso di studi (una domanda segreta popolare) è completamente un'altra. In realtà, puoi facilmente conversare con qualcuno su molti aspetti della sua vita che potrebbero rappresentare una domanda segreta, senza destare sospetti. Naturalmente, l'essenza stessa della domanda segreta è che è legata all'esperienza di vita di qualcuno, quindi viene ricordata, e proprio qui sorge il problema — le persone amano raccontare della propria esperienza di vita! Su questo c'è poco da fare, a meno di non scegliere tali opzioni di domande segrete, in modo che possano con minore probabilità essere estorte tramite ingegneria sociale.
[Continua a leggere.]
In base alla pubblicità
VDSina offre server affidabili , ogni server è collegato a un canale Internet da 500 Megabit ed è protetto gratuitamente dagli attacchi DDoS!
Fonte: habr.com
