Al pratico: vulnerabilità degli account

Al pratico: vulnerabilità degli account postato il 07/10/2009 16:19:59 nel forum programmazione, open source e hosting e modificato da ghennadi72 il 07/10/2009 21:49:06

Mi é venuto in mente di fare una scaletta di punti potenzialmente problematici nella gestione di un qualsiasi GDR online, a prescindere dal pacchetto usato (uno di quelli disponibili qui o autoprodotto) per esaminare possibili soluzioni.

Conosco PHP+MySQL, quindi laddove provo a individuare soluzioni tecniche mi rifaccio a questi.

Comincio con un argomento che é tra quelli più sensibili, data l'insorgenza frequente di "furti di account". Prego chiunque abbia esperienza in materia di integrare, suggerire, postare (se ne ha voglia) anche soluzioni tecniche adottate.



1) SICUREZZA DELL'ACCOUNT (USERNAME, PASSWORD...)
E' un argomento molto critico, soprattutto perchè riguarda anche l'utente "benintenzionato" ma distratto o facilone (es. il tipico utente che tiene la password annotata su un postit attaccato al monitor in ufficio, o che sceglie come password il nome della squadra di calcio preferita e poi sbandiera i suoi gusti calcistici in bacheca) che potrebbe esporsi a sua insaputa, qualunque misura tecnica noi possiamo prendere, a rischi di sottrazione dell'account.

Ipotizzando alcuni approcci al problema:

* Crittazione della password: tralasciando che rientra fra le direttive del progetto legalità, mi sembra una buona abitudine. Personalmente ho optato per la crittazione con sha1, "irrobustita" dall'uso di un "seme", ossia una parola, o combinazione di lettere e numeri "aggiunta" alla password generata dal sistema o scelta dall'utente.
La parola "seme" può essere contenuta in un file di configurazione della land, ovviamente fra i tag di PHP in modo che non sia accessibile tramite richiesta http. Un "irrobustimento" ulteriore può essere quello di cambiare periodicamente la parola "seme", anche se questo rende inutilizzabili le password già registrate e forza gli utenti a generarne una nuova ogni volta che il seme viene cambiato.

* Robustezza della password: aldilà dei consigli che possiamo dare all'utenza, l'unico "aiuto" concreto che si può dare, dato che statisticamente il giocatore non legge un tubo dei consigli che vengono forniti al momento della scelta della password, é quello di implementare controlli che richiedano password complesse e non troppo corte, per renderle meno vulnerabili ad attacchi brute-force, e anche meno facili da indovinare. Ad esempio forzando l'utente a mescolare maiuscole e minuscole, lettere e numeri, e imponendo una lunghezza minima della password. Risulterà una password meno facile da ricordare ma anche meno vulnerabile e meno facile da indovinare.
L'ideale, per facilitare le cose all'utente, sarebbe anche di effettuare il controllo sulla complessità/lunghezza della password prima dell'invio (validazione lato client) usando anche uno dei tanti script ajax/js disponibili gratuitamente.

* Separazione tra login e nome del personaggio giocante: lo Username rappresenta esattamente la metà di quello che occorre per fare il login, quindi dal punto di vista dell'utente malintenzionato, conoscere lo username dell'utente é possedere già la metà di quello che gli serve. E' difficile intervenire sulla maggior parte degli OS in circolazione, dal momento che quasi sempre lo username usato per il login coincide con il nome del personaggio utilizzato in gioco, che é quindi pubblicamente disponibile agli altri utenti.
Laddove possibile, soprattutto se si sta scrivendo un proprio GDR senza fare ricorso ad alcuno di quelli esistenti, l'ideale sarebbe di distinguere nettamente tra lo username di login, e il nome del personaggio da usare in gioco, mantenendo il primo segreto e (sperabilmente) noto solo all'utente e agli amministratori. Questo comporta che la fase di creazione del PG deve avvenire successivamente alla creazione dell'account di login.
Alcuni OS già prevedono questa possibilità, ad esempio richiedendo l'inserimento dell'indirizzo email come username. Tuttavia anche l'email é un dato potenzialmente pubblico. Un ulteriore modo di irrobustire la separazione tra username e personaggio sarebbe quella di impedire la scelta di un nome per il PG coincidente con lo username di login scelto.

* Canali di pubblicazione dello username: supponendo che sia stato distinto il login dal nome del PG, alcuni potrebbero voler implementare una parte esterna al gioco, ad esempio liste degli utenti online con appositi profili (compleanni, contatti esterni, etc), o addirittura sistemi di messaggeria privata esterni al gioco, per lo scambio utente-utente anzichè pg-pg. In tal caso sarebbe buona norma non rendere visibile lo username, e far scegliere invece all'utente registrato un nome, o un nick, visibile agli altri utenti che non coincida né col nome del PG né con lo username di login.

Nota: la separazione tra Username e Personaggio può risultare utile anche per ragioni che non hanno alcuna relazione con la sicurezza, ad esempio se si volesse consentire a determinate categorie di utenti di muovere più di un personaggio (magari in funzione di una quest) senza costringerli a creare più account.

07/10/2009 21:21:09 e modificato da ghennadi72 il 07/10/2009 21:42:40

CRITTAZIONE PASSWORD CON SHA1 + SEME
Metto qui la soluzione che ho adottato io, ricapitolando in breve il principio del sistema.

La pass viene inizialmente generata a random dal sistema, al momento dell'iscrizione e inviata all'email fornita dall'utente. NON viene salvata subito nel database. Viene concatenata a una parola (o combinazione di lettere/numeri) detta seme, come misura di irrobustimento. Poi viene passata alla funzione sha1 che la cripta. Il risultato é una stringa alfanumerica di 40 caratteri, quindi il campo del database predisposto per salvare la pass deve essere impostato di conseguenza (varchar(40) o più).
Solo a questo punto la pass viene salvata nel database. In nessuno di questi passaggi la pass in chiaro deve essere resa disponibile a terzi, amministratori compresi, se non all'utente finale che la riceve. Questo per non vanificare il principio base del sistema: l'utente deve essere il solo a conoscere la propria password e anche per gli admin deve risultare impossibile (diciamo altamente improbabile) anche ricavarla.

Dal momento del salvataggio nel database, la password non sarà più disponibile in chiaro (non escludo sia teoricamente possibile risalire alla pass originale per chi avesse a disposizione risorse tipo NSA, ma dovrebbe essere relativamente al sicuro).
In caso di smarrimento o dimenticanza della password da parte dell'utente, l'utente non può chiedere il rinvio in chiaro della password. Dovrà chiedere al sistema la generazione casuale di una nuova password e farsela rispedire in email.


Nota: questo significa che la procedura di reimpostazione della password dovrebbe effettuare un minimo di controllo sull'identità di chi richiede la reimpostazione della password, per scoraggiare i burloni, che conoscendo lo username o l'email di un utente potrebbero divertirsi a rimpostargli la password di continuo chiedendone il rinvio.
Una buona soluzione é quella di ricorrere alle classiche domande di conferma, quali "Nome di tua madre da nubile", "Professore preferito", eccetera. Non garantiscono sicurezza assoluta, in quanto in po' di social engineering può portare un "truffatore" molto motivato a scoprire gusti e informazioni personali della sua vittima. Però stabilisce un criterio di sicurezza aggiuntiva passabile.

Quando l'utente fa il login e inserisce la sua password in chiaro, l'OS non deve decrittare quella salvata nel database, al contrario fa la cosa opposta: critta la password inserita, sempre dopo averle aggiunto il "seme", e quindi la confronta con la stringa alfanumerica contenuta nel database: se le due stringhe coincidono, il login va a buon fine.

Implementazione:

Il file di configurazione contenente la parola "seme" da aggiungere alla pass in chiaro. Questo file dovrebbe essere incluso solo nei file php che riguardano la registrazione dell'account, il login e la gestione della password (reimpostazione automatica e cambio pass dopo il login).

<?php
// FILE: crypt_seed.inc.php

$crypt_seed = "PITON";

?>

Passiamo alla funzione che critta la password. Questa funzione deve ricevere due parametri: la pass in chiaro, ed il seme. La pass in chiaro può arrivare dall'utente che la inserisce manualmente, o da una procedura che la genera a caso, poco importa... importa solo che é la pass che l'utente userà al momento del login, nuda e cruda. Do per scontato la pass, prima di arrivare allafunzione, sia già passata attraverso eventuali filtri per eliminare spazi inutili, caratteri pericolosi, tag html etc.
Il seme (seed) viene recuperato dal file incluso, specificamente dalla variabile $crypt_seed.

/*... codice vario ... */

function pass_crypt($pass,$seme) {
$newpass = $pass.$seme;
/*
Concatena la pass al seme; ovviamente anziché concatenarla può essere anche mescolata alla pass in chiaro con altri sistemi di vostra scelta.
*/
$passcrypt = sha1($newpass); // critta la password
return $passcript;
}

/* ... codice vario ... */

La funzione qui sopra deve essere richiamata ogni volta che serve crittare una password prima di salvarla nel database, o crittare la password immessa dall'utente al momento del login prima di confrontarla con quella estratta dal database.

Il modo di richiamarla, ovviamente é:

$pass_cifrata = pass_crypt($pass_in_chiaro,$crypt_seed);

Si ricorda che se il valore di $crypt_seed viene cambiato (ad esempio se lo si vuole cambiare periodicamente per ragioni di sicurezza) TUTTE le password precedentemente crittate risulteranno inutilizzabili e quindi tutti gli utenti dovranno reimpostare la password.

Nota: per confrontare le due password criptate, ad esempio al momento di impostare manualmente una nuova password (di solito si chiede la vecchia per conferma), é preferibile usare la funzione strcmp($pass1,$pass2) invece che usare gli operatori di eguaglianza ("==" o "===") con un if($pass1 == $pass2), ricordando che strcmp() restituisce ZERO se le due pass sono uguali (il caso che interessa a noi per mandare a buon fine il login).

08/10/2009 01:19:08

Il sistema col seme è poco sicuro in quanto comunque non previeni lo sniffing, col rischio che possono leggere la password in chiaro mentre essa viene passata al server come pacchetto.

Nel database puoi anche archiviarla sotto algoritmo sha1() senza seme, l'importante è evitare lo sniffing generando ad ogni sessione un seme casuale con cui criptare la password lato client, spedirla al server già criptata, poi recuperarla da db e criptare con il medesimo seme casuale quella associata all'account; infine fare il paragone tra le due e autenticare l'utente in caso di successo.

In questo modo anche se con lo sniffing viene intercettato un hash al posto della pass in chiaro, tale hash non sarà mai identico.

https://www.gdr-online.com/readforum.asp?id=88216 ↗


Secondariamente è bene proteggersi dalle Sql Injection filtrando sempre qualsiasi input che un ipotetico utente può manipolare, dalle semplici variabili in get a quelle in post: la regola è non fidarsi mai di cosa ti mandano.

https://www.gdr-online.com/readforum.asp?id=80665 ↗


Altro problema è l'XSS ovvero il cross site scripting, è una tecnica che sfrutta l'inclusione di file javascript maligno da parte dell'utente, questo accade quando v'è l'html abilitato e non filtrato, si può risolvere semplicemente bloccando ogni eventuale possibilità di inserire html da parte degli utenti. Esistono valide alternative come il bbcode per formattare i testi in tutta sicurezza, non vedo perchè non usarli :p

ps: Evitate il bbcode con gli str_replace di gdrcd, quelli si aggirano come burro, eseguite sempre solidi controlli con regular expressions.

https://www.gdr-online.com/readforum.asp?id=80881 ↗

09/10/2009 22:27:08 e modificato da ghennadi72 il 09/10/2009 22:32:59

SSL ha costi che, come dici, forse sono fuori della portata dei mezzi di chi normalmente apre o medita di aprire una land virtuale.

Probabilisticamente parlando, oltre che tecnicamente, quanto frequentemente può accadere che una password venga intercettata al momento dell'invio dalla finestra di login sul browser dell'utente?

E' una domanda da profano quale sono. Credo che fondamentalmente all'aspirante gestore interessi prima di tutto capire quale genere di minacce potrebbe realisticamente incontrare aprendo una land e capire come porvi rimedio, ricordando che difficilmente avrà i mezzi economici per dotarsi di strumenti come SSL, e quindi potendo puntare solo sul codice che é in grado di sviluppare/installare su un provider che nel 90% dei casi sarà Aruba, forse Register se ha un centinaio di euro in più da metterci.

Sono interessato a capire di quali mezzi deve disporre l'ipotetico malintenzionato che volesse intercettare la password di un altro utente e quali siano le condizioni in cui questo può avvenire.

Considerando lo scopo di chi apre una land, é ovvio che c'è un rapporto costi/benefici di cui tenere conto nel momento in cui decide quale livello di sicurezza pretendere dalla sua applicazione e che, senza sottovalutare i rischi ipotetici, potrebbe anche decidere di assumersi il rischio di non dotarsi di contromisure nei confronti di certe categorie di attacchi che assai difficilmente potrebbero essere diretti contro una land amatoriale con 20-50 visitatori al giorno... almeno laddove i "costi" (economici, di tempo, di risorse) di implementazione delle contromisure risultassero del tutto sproporzionati rispetto agli scopi dell'applicazione (far giocare qualche manciata di propri amici e conoscenti in una webchat).

09/10/2009 22:42:19

Certamente il costo di un SSL non è giustificabile per un gdr-online che non sia della mole di DLot ed ELot (almeno chè non hai soldi da spendere) ed è altrettanto sicuro invece che queste community sono le ultime cose prese di mira da hacker e cracker (salvo questioni personali tirate in ballo il più delle volte), tuttavia non serve necessariamente: è possibile farsi da se una semplice protezione che simula il comportamento di un SSL creando un login sicuro da sniffing.

Il primo link che ho inserito nel mio post precedente conduce ad una discussione dove c'è postata una bozza di codice con tanto di descrizione per poter far ciò.

Non è certamente sicuro come altri sistemi dediti proprio allo scopo, ma di certo è funzionale e non ti lascia propriamente scoperto al primo lamer che ha imparato qualche trucchetto metodico ;-)