Newsgroup: it.comp.www.php
Titolo: [OT?] [MYSQL] AES_ENCRYPT...

Ho bisogno di criptare i dati di un database, la funzione che ho trovato che
fa al caso mio è AES_ENCRYPT,
ma dove posso memorizzare la chiave di criptazione per far si che non sia
disponibile a chiunque?
Il sistema è ovviamente un web-server con un applicativo in PHP e DB MYSQL
su sistema UNIX.
Pensavo di memorizzare la chiave in un file non accessibile dal web, oppure
memorizzare l'md5 della chiave direttamente nel DB, avete qualche idea
migliore
-- 
Ciao da
       --§Ska-Man§--
[
ska...@despamming.com
]
----------------
http://www.fantabasketpro.net
http://www.birraesalsiccia.net


Come dicevo prima non è assoluta, ma la qualità della sicurezza è
migliorata; MD5 ti permette di avere una stringa non comune, comunque non
sono sicuro se c'è un limite alla lunghezza in caratteri della $chiave.
Francesco Duca
http://www.goldenweb.it


:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

 qualche idea migliore
L'MD5 e' un sistema di hashing one way, se salvi solo l'MD5 non potri
decriptare il contenuto del DB.
-- 
I am what I am, I do what I can
L'uomo, conscio di sbagliare, persevera.

 decriptare il contenuto del DB.
Argh hai ragione... infatti è proprio il motivo per il quale non uso MD5 per
la criptazione dei dati...
vabbè ci sono rimasto... :-P


 -- 


 ha scritto nel messaggio
news:V_X1d.325974$5D1.14...@news4.tin.it...

no non ci sono rimasto...
ecco cosa avevo pensato... memorizzo la chiave in un file... poi la chiave
per cryptare con l'AES_ENCRYPPT è l'MD5 della chiave...  ma non cambia
nulla, giusto?


 non cambia nulla, giusto?
Beh, se uno ha l'MD5 puo' comunque decodificare il contenuto del DB, se
uno trova la chiave originale idem (ossia fa l'MD5 e via cosi').
IMHO una soluzione valida sarebbe quella di salvare tutti i dati
sensibili in un file PHP come variabili e poi codificare tutto il sito
con un tool come Zend Encoder, SourceGuardian, PHTMLEncoder, Ioncube
etc. etc.
Ovviamente anche questo sistema non e' sicuro al 100% perche' un super
utente potrebbe comunque "fregarlo" con un script tipo:
<?php 
include ('file_chiavi.php');
print_r (get_declared_classes ());
print_r (get_defined_constants ());
print_r (get_defined_functions ());
print_r (get_defined_vars ());
?>


Sono presenti anche alcuni campi longtext, è un DB vario come tipi di dato.
Il problema e' che ovunque tu metta la chiave, chiunque ha accesso al
sistema la puo' leggere.
In pratica ti "difendi" solo da qualcuno che arriva al database senza
passare da PHP (che ha la chiave: un errore di injection nel PHP e la
crittografia non ti serve a nulla) e senza avere accesso al disco.
Una possibilita' un po' stupida e' quella di archiviare la chiave dei
campi criptati nella tabella degli utenti.
Mi spiego: cripti (con AES o ENCRYPT) la password "dei dati" dentro a
un campo "dbpass" di ciascun utente, usando come password la password
dell'utente, ed immagazzini nel campo "userpass" l'MD5 della password
dell'utente.
L'utente ti manda la propria password ("pippo"), tu ne fai l'MD5 e se
userpass==$md5 la password e' buona; la usi per decriptare $dbpass, e
a questo punto, lo script PHP conosce la password del DB... che pero'
non trovi in chiaro ne' sul disco, ne' nel database.
Se un utente cambia la propria password, aggiorni sia la sua userpass
che la sua dbpass.
C'e' un problema logistico... nel senso che se cambi $dbpass non c'e'
modo di aggiornare la $dbpass del database utenti, perche' non hai le
password degli utenti. Quindi se una volta cambi la password globale,
sei costretto a resettare tutte le password di tutti gli utenti.
L'implementazione e' qualcosa tipo:
	$md5	= md5($pass);
	$exec	= SQLExec($conn, "SELECT * FROM users WHERE user='$user'
AND pass='$md5';");
	if (1 != SQLNumRows($exec))
		trigger_error(...);
	$_SESSION['auth'] = true;
	$userdata = SQLFetchTuple($exec, 0);
	SQLFree($exec);
	$okpass	= SQLGet($conn, "SELECT AES_DECRYPT('$userdata[dbpass]',
'$pass');");
	SQLFree(SQLExec($conn, "SELECT @aeskey:='$okpass';");
	unset($pass, $okpass);
...da qui in poi puoi usare @aeskey per AES_ENCRYPT() senza dovertela
portare dietro - e' solo nella memoria del server MySQL. $pass non ce
l'hai piu', ma che l'utente e' valido lo vedi da $_SESSION['auth'].
Ovviamente se l'host viene espugnato per bene non ti salva neanche il
Rijndael, perche' al primo utente che si logga, il file per auth puo'
essere stato taroccato e mandare una copia della pass in mail a Giggi
er Craccher...
Leonardo
-- 
Avere studiato senza mettere in pratica e' inutile;
mettere in pratica senza avere studiato e' pericoloso.
                                                - Conphpucio


Allora se uso:
ENCRYPT($testo, MD5($chiave))
e poi
DECRYPT($testo, MD5($chiave))
non funziona?


 non funziona?
Funziona ma a quel punto avere l'MD5 o avere la chiave e' la stessa
cosa.



E se utilizzo flock, cambiando i permessi ai file, lo script di cui sopra
funziona ancora?

 sopra funziona ancora?
Lo script PHP che contiene le chiavi deve poter essere letto dal web
server (altrimenti tutto il sito non funziona) per cui qualsiasi tipo
di protezione a livello file venga aggiunta comunque uno script
eseguito del web server sara' in grado di leggerlo (esattamente come
gli altri script del sito).


 > sopra funziona ancora?
Non mi pare.
Andiamo al dunque.
Ma lo vogliamo bloccare questo super user che vuole accedere al file chiave
tramite lo script seguente(script posseduto da un altro gruppo e da un altro
user)?
[]
include ('file_chiavi.php');
print_r (get_declared_classes ());
print_r (get_defined_constants ());
print_r (get_defined_functions ());
print_r (get_defined_vars ());
[/]
se utilizzato adeguatamente flock all'interno dei file della directory in
questione, cosi' da permettere l'accesso al file chiave solo da uno script
posseduto dall'utente ska-man e dal gruppo ska-man e presente nella
directory in questione, può fermare lo script di cui sopra?

 sopra?
Ammesso che tu faccia il locking all'inizio dello script PHP, al
termine dell'esecuzione che succede?
	A. Non chiudi il locking? 
         Allora il tuo sistema fallira' alla seconda chiamata, infatti 
         nessun altro script sara' in grado di accedervi.
      B. Chiudi il locking?
         Da quel momento in poi qualsiasi script sara' in grado di 
         leggerne il contenuto.
Tralasciando il fatto che, come super utente, posso sempre terminare
eventuali processi che fanno il locking del file ...
P.S.
Incompetente come mai hai cambiato nick? Non sponsorizzi piu' il tuo
tanto amato sito?



Ogni tanto bisogna pur cambiare adesso vado in cerca di cavolate, anche tu
ne scrivi tante, e devo dire che dribbli abilmente sulle tue (in)competenze.
D'altronde tutte cose non si possono sapere.
L'incompetente (non incompetente come scrivi sopra)
Non credo che la netetiquette contempli l'insulto come elemento del
newsgroup.

 newsgroup.
Di grazia, come mai ti sei spostato dal tecnico alla netiquette? Non e'
che ti sei accorto che L'incompetente ha nuovamente detto una cavolata?


"Setec Astronomy" <setec@_NO_NOSPAM_freemail.it> ha scritto nel messaggio
news:cica37$lk7$2...@fata.cs.interbusiness.it...

Dribbling

 Dribbling
Scusa, ma ora chi e' che "dribbla abilmente sulle proprie
(in)competenze" ?
