Newsgroup: it.comp.www.php
Titolo: MySql Criptato Password

Ciao a tutti,
per motivi di privacy dovrei memorizzare dei dati criptati in Mysql. 
Inoltre, con la password di gestore, dovrei averne accesso, e dovrebbe 
avere accesso anche l'utente normale per eventuali modifiche!
Mi spiego meglio!
Password utente gestore: decripta tutti i dati contenuti in una tabella 
del database!
Password utenti normali: decripta solo il record specifico di tale utente.
Come posso fare?
Grazie anticipatamente
Ale

Come posso fare?
Se non sbaglio (pero' controlla), il requisito e' che tu non abbia i
codici di accesso dell'utente. Nulla e' detto circa i suoi dati e la
possibilita' di decriptarli.
Quindi potresti aggiungere alla tabella Users due colonne di 32 char
contenenti, l'una, una chiave random di 16 byte criptata via AES con
la password dell'utente, e l'altra la stessa chiave e criptata nello
stesso modo con la chiave dell'amministratore.
Quando aggiungi un record, generi una chiave random di 16 byte, e la
salvi nelle due colonne: una criptata, l'altra in chiaro usando come
prefisso 'ENCRYPTINGNEEDED'. Quando si logga l'amministratore cerchi
tutte le chiavi con quel prefisso, ne cripti l'altra meta', e la usi
per sovrascrivere la chiave stessa. Per criptarla usi una chiave, di
16 byte, criptata con la pass dell'amministratore:
		Password	UserKey		AdminKey
admin		pippo		(tsh,pippo)	(kzk,pippo)
lserni		pluto		(qqz,pluto)	(qqz,kzk)
mrossi		minni		(pth,minni)	(pth,kzk)
gverdi		aida		(qwy,aida)	ENCRYPTINGNEEDEDqwy
La chiave usata per criptare i dati personali dell'amministratore e'
"tsh" (in realta' sono 16 byte), la chiave universale e' kzk. Queste
non cambiano pressoche' mai (costa, cambiarle).
L'utente lserni con la password pluto puo' decifrare UserKey e cosi'
scopre che la chiave dei dati e' qqz, e con quella legge solo i suoi
dati, ma non puo' scoprire che la chiave universale e' kzk.
Quando viene creato il record di gverdi si crea la chiave qwy, e non
e' disponibile la password di admin per ricavarsi kzk, quindi dentro
AdminKey finisce una versione meno sicura con qwy in chiaro. D'altra
parte l'alternativa e' peggiore (lasciare disponibile a tutti kzk).
Appena admin si logga, cripta tutti gli AdminKey rimasti scoperti.
Quando un utente (o l'amministratore) cambia password, deve ricreare
UserKey e, nel caso dell'amministratore, anche AdminKey (ma solo del
suo record, non su tutti i record di tutti gli utenti).
L'amministratore non conosce la password degli utenti (io l'ho messa
in chiaro per chiarezza <grin>, ma in realta', quello e' l'MD5 della
password). *SE* un utente si logga e MD5(suapass) corrisponde a quel
che trovi nel campo Password ALLORA E SOLO ALLORA puoi usare suapass
per decifrare il suo UserKey e accedere ai suoi dati.
Complicato e arzigogolato, ma DOVREBBE funzionare.
Leonardo, S.E.&.O.
-- 
And where the black and corkscrew towers climb,
Lost and athirst the ragged pack abides,
Old as the aeons, trapped in tombs of time,
Sailing the tortuous temporal tides


Premesso che mysql cripta usando una sola password...
vedi esempio 
http://62five.com/blog/?p=24
devi implementare delle policy del tipo:
se l'utente ha accesso al record passi la password e decritti, se non ha 
accesso stampi un msg di errore al ché viene da chiedersi se sia 
realmente necessario crittare i dati sul db, considerando che nel server 
apache/php dovrai comunque scrivere la password in chiaro (salvo l'uso 
di strumeti tipo "obfuscator") e che in ogni caso la variabile "key" 
viene memorizzata in @GLOBALS e comunque i data apache->mysql 
passerebbero in chiaro (salvo uso di SSL)
Se esponi chiaramente il progetto potresti avere indicazioni utili su 
come realizzarlo nel modo più consono (anche php può crittare/decrittare 
dati)

apache/php dovrai comunque scrivere la password in chiaro
Perche'? Si', certo, la password di accesso al database.
Ma se i dati nel DB sono cifrati, con quella password puoi impedirmi di
accedere al mio home banking - o puoi sapere che l'MD5 della mia chiave
di accesso e' 58ee09937d51f3886dcd0c0ea91c053e [1].
Se non sono cifrati, puoi svuotarmi il conto corrente.
C'e' differenza! :-D
Leonardo
[1] non e' sicura, si trova con googlemd5 :-)


 
Innanzitutto bisognerebbe comprendere cosa deve fare l'applicazione e 
quali campi dovrebbe o vorrebbe mantenere crittati e perché.
In secondo luogo va considerato che applicazioni in php de facto 
utilizzano un middleware quindi serve a poco crittare i dati sul db se 
poi si lascia il postit attaccato al monitor con username e password.
Francamente pensare di utilizzare una username/password come credenziali 
di accesso ad un sistema che dovrebbe mantenere un elevato grado di 
sicurezza/riservatezza fa sorridere indipendentemente da come queste 
vengano salvate nel database, sia che usi un semplice hash MD5 o un sha1 
il problema sta alla fonte.

>> su come realizzarlo nel modo piů consono
ma a quel livello di dettaglio, non sono indicazioni: e' un piano completo
di deployment. Diverso e' l'impegno per buttarlo giu' e diverso, diciamolo
pure, il costo di progetto :-)
Leonardo


 Ale

 Come posso fare?
che alla fine hai un casino da gestire, per la normativa fai prima a


alxnc2000 ha scritto:
Grazie a tutti,
Ho messo assieme tutti i consigli e sono riuscito nell'intento!
Grazie ancora a tutti

 Ho messo assieme tutti i consigli e sono riuscito nell'intento!
come ?