Re: [Hackmeeting] problema con dati sensibili

gmail@??? wrote:
> per accedere agli account Twitter degli iscritti ovviamente devo avere i
> loro username e password in chiaro, ma salvarli così come sono nel database
> non mi sembra sicuro..

comprensibile :)

> per evitare che qualche attaccante possa impadronirsi di questi dati ho
> pensato di implementare un meccanismo di cifratura diviso in due parti:

dal punto di vista "filosofico" ti è impossibile ottenere con sicurezza
lo storage di questi dati. perché:

. in qualunque modo tu li conservi, a te serve riottenere la coppia
login/password in chiaro
. in qualunque modo tu li recuperi (dischi cifrati, utilizzo di server
remoti, dati frammentati e sparpargliati, 20 chiavi di crittografia,
ecc...) se l'attaccante ha preso il controllo della macchina, potrà
recuperarli anche lui facendo le stesse cose che fa il tuo software.

> 1) password cifrata & una delle due chiavi di cifratura nel database
> 2) seconda chiave di cifratura contenuta direttamente in un file PHP
> così anche se si riuscisse a fare SQL Injection non si ariverebbe comunque
> a ricostruire la password in chiaro senza avere accesso ai sorgenti dei
> file..

questo sistema puo' essere sufficente, come giustamente dici, a fronte
di una SQL injection. puoi anche stimare (è necessario raffigurarsi un
modello di minaccia per poter organizzare la difesa) che tu non avrai
una mole così imponente di dati da rappresentare un valore di mercato
importante, e quindi di non doverti proteggere da attacchi piu' radicali
di un attacco web.

il tuo sistema va quindi bene, a patto che l'algoritmo di crittografia
sia sicuro, l'output crittografico sia della stessa dimensione per tutte
le password, la chiave di cifratura sia differente per ogni password.

quest'ultimo punto si risolve cosi': prendi la password che hai storato
nel file (che non sarà un file .php che banalmente chiamerai
password.php e leggerai con include('password.php'); perché gli attacchi
web lo raggiungerebbero senza problemi), la ACCODI all'username, fai
sha1sum di questo blocco (ottieni l'equivalente di un salt del des, solo
molto piu' lungo) e la usi come chiave di cifratura per la password.

in fase di rilettura hai gli stessi dati, non risulta un problema.

altrimenti, molti attacchi crittografici si possono portare su porzioni
di dati relativamente piccoli partendo dal presupposto che sono stati
cifrati tutti con la stessa chiave. con questo accorgimenti li puoi evitare.


ciao,
v