Newsgroup: it.comp.www.php
Titolo: Proteggere il DB

Salve,
sto realizzando un'applicazione per un cliente il quale ha paura che io 
possa andare a leggere il contenuto del DB.
Come potrei fare per rassicurarlo ed ad esempio crittare i dati, ma in caso 
di problemi avere la possibilitą di accedervi?
Pensavo di crittare solo alcuni campi (quelli che contengono le informazioni 
riservate), ma comunque la chiave dovrą essere archiviata da qualche parte 
in chiaro...sono un po' confuso. Potete darmi qualche consiglio?
Grazie 

 
Premetto che credo di non aver capito benissimo... ma penso tu possa 
risolvere in questo modo...
Per avere accesso al db occorre fare "login", quindi, sul db ci sarà una 
tabella con username e password, la cui password può essere ad esempio 
cryptata in md5()...
una volta loggato la password è modificabile... se ti dimentichi la 
password sono azzacci tua... ma.. lol voglio dire... il "realizzatore" 
deve pur avere un account di accesso... come ci accedi a sto db? tramite 
phpmyadmin ad esempio ?
qual'ora perdessi la password potresti sempre andare a ri-cambiartela... 
ma non ha molto senso una richiesta di quel genere...

possa andare a leggere il contenuto del DB.
L'unico sistema che mi viene in mente e' questo: mantieni una chiave
segreta (es. in sessione).
Questa chiave viene archiviata nella tabella utenti, criptata con la
stessa password dell'utente.
Quando l'amministratore crea un utente, gli assegna una password per
cominciare, e imposta sia la password, sia la chiave cifrata. Quando
l'utente si cambia la password, imposta sia password che chiave.
Tutti i record sensibili sono criptati con la chiave segreta.
A questo punto, qualsiasi utente registrato puo' accedere ai dati, e
puoi prevedere degli utenti "poveri" che hanno il campo della chiave
a NULL; questi non possono fare niente.
Perche' i dati vadano perduti, bisogna aver perso TUTTE le password,
di TUTTI gli utenti non "poveri". E' tantarobba.
La chiave non e' conservata in chiaro da nessuna parte, e nel DB hai
solo i campi con l'MD5 della password e con la chiave criptata.
Se cambi la chiave cifrata ti tocca riscrivere tutto il database, ed
anche i campi utente... ma non lo puoi fare finche' non hai tutte le
password. Come a dire che, se cambi la chiave, devi dire a tutti gli
utenti che gli hai resettato la password e che la rimettano :-)
Ovviamente, basta che tu abbia UN utente con una password banale, ed
e' immediato:
	-> dal campo MD5 risalire alla password mediante un semplice
	   reverse dictionary attack
	-> dalla password decriptare la chiave cifrata
	-> dalla chiave cifrata decriptare ogni bene
===
Per esperienza: descrivi la cosa all'utente e spiegagli che dopo non
sarai piu' in grado di accedere ai dati; e fatti FIRMARE la cosa. Ho
visto utenti che ESIGEVANO che il programmatore *potesse* accedere a
tutti i dati, naturalmente senza potervi accedere, leggendo tutto ma
senza leggere niente.
E, a volte, incazzarsi come faine perche' dei dati "sicuri" e temuti
persi per sempre (ululati! Terrore! Raccapriccio!) erano stati, dopo
ore di bestemmie, recuperati grazie a una svista dell'utente ("Ma la
segretaria che se ne ando' l'anno scorso aveva messo una data... ora
si prova tutte le date dal 1900 ad oggi, chissa' se..."), strillando
"MA ALLORA, I MIEI DATI NON ERANO SICURI!!! MI AVEVA DETTO CHE ERANO
SICURI!!!" :-D
Leonardo
-- 
Next in importance to freedom and justice is popular education, without which neither can be permanently maintained.
James A. Garfield (1831 - 1881)

 SICURI!!!" :-D
Beata l’ignoranza che se sta bene de core de mente e de panza!!! :-)
--
rob4you


l'utente cambia la passoword ?

in mysql esiste la possibilita di usare x509
i dati li devi cifrare con https / autenticazione x509 di mysql
potresti anche usare delle tabelle con crypt e una per le chiavi
dell'applicazione
pero persa la chiave persi i dati


dell'applicazione
Be', si'... in effetti e' il sistema che descrivevo. Quanto alla tecnica
di cifratura, in linea di principio un qualsiasi sistema 2-way va bene.
