Newsgroup: it.comp.www.php
Titolo: PHP, MySQL, PGP e firma dei record

Non so se sia fattibile o no, vorrei sapere se qualcuno l'ha fatto.
Prendiamo un applicativo PHP+MySQL con una propria userbase.
Ogni utente ha un proprio set di chiavi pubbliche e private generate da PHP
quando viene creato l'utente richiamando da shell PGP.
Quando un utente inserisce un record in una tabella particolare, il PHP crea una
stringa partendo dai record della tabella, chiede la password di sblocco della
chiave privata dell'utente, lancia PGP in shell per firmare la stringa e
registra la firma in un campo apposito del record.
Questo per garantire (entro limiti umani, non in maniera assoluta) che "quei"
dati siano stati modificati o scritti da "quel" utente.
Qualcuno ha provato una follia simile? Sto facendo del casino per nulla? Esiste
gia' qualcosa di fatto?
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
There are two kinds of people in the world: those who believe there
are two kinds of people in the world, and those who don't.

 firmare la stringa e registra la firma in un campo apposito del record.
Non ho mai fatto niente del genere, ma questo metodo presuppone che tu 
sul server abbia sia le chiavi pubbliche che quelle private dell'utente.
A questo punto forse potrebbe essere altrettanto sicuro ma piu` semplice 
e performante un normale hashing a seed (la password) come firma, 
piuttosto che una a chiave pubblica.
Se ho capito bene cosa vorresti fare, naturalmente. :)
Bye.

gia' qualcosa di fatto?
Io ho fatto qualcosa di simile, ma non basato su chiave asimmetrica.
Se ricordo bene:
Users:	username	nome utente
	password	hash della password
	decrypt		(1)
	recover		(2)
(1) il campo decrypt è ottenuto in fase di creazione utente generando una
    chiave random detta "userkey" e cifrandola con AES, usando "password"
    come chiave.
(2) il campo recover è ottenuto in fase di creazione utente, compiuta dal
    superuser, ed è AES(data: userkey, key: masterkey). "masterkey" non è
    altro che la userkey di superuser. Il campo recover di superuser è la
    masterkey criptata con la MIA password <grin>.
Tutti i dati utente sono criptati in AES con la userkey. E quindi possono
essere letti dall'utente o al limite da superuser.
L'utente si logga inviando PASSWORD, il sistema verifica che sia valida a
mezzo hash, e la usa per decriptare il campo decrypt, recuperando userkey
e mettendola in sessione.
Se l'utente cambia la propria password, decrypt viene aggiornato, ma cio'
non influenza nessuno dei dati criptati. La userkey non viene mai mandata
in rete, e le sessioni sono su una heap table.
Per AES_* e heap table, mi sono appoggiato, spingendo, su MySQL :-)
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 Se ho capito bene cosa vorresti fare, naturalmente. :)
Il mio scopo e' di dire che un record di una tabella e' stato creato/modificato
da un utente, che l'utente sia proprio lui e che nessun altro lo abbia modificato.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Success is 99% failure.
    --Soichiro Honda

 e mettendola in sessione.
Pero' anche qui per verificare che i dati non siano stati cambiati ho bisogno
della password dell'utente, vero?
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Chi bibe s'emborracia,
chi s'emborracia v'al suelo,
chi v'al suelo duerme,
chi duerme non peca,
chi non peca va in cielo;
posto che in cielo vamos,
bevamos, bevamos, bevamos!!!

della password dell'utente, vero?
Hummm...
"Il mio scopo e' di dire che un record di una tabella e' stato
creato/modificato
da un utente, che l'utente sia proprio lui e che nessun altro lo abbia
modificato."
...questo lo fai con un log, per esempio. Oppure il sistema stora lo hash
della funzione SQL che fa l'update (tolto il campo hash, si capisce) e lo
concatena con un secret e con lo username dell'utente:
	function my_UpdateSQL($tuple, $username)
	{
		// SELECT ... $tuple->primaryKey
		// $checktuple['signature'] = 'secret'.'.'.$username;
		// $md5	= md5(serialize($checktuple));
		$tuple->signature = "$username.$md5";
		UpdateSQL($tuple);
	}
o qualcosa del genere. Se solo l'applicazione puo' accedere al DB... però
in questo caso ti conviene sempre di più usare un log.
	INSERT INTO sql_log ... date, ip, username, table,
		 $serialized_fields...
con array_map('md5', $arry) si sanitizza $arry nel caso contenga roba non
pubblica (non è salato, quindi è vulnerabile a un google-brute-forcing).


 concatena con un secret e con lo username dell'utente:
Siamo sempre li': per fare una verifica hai bisogno di una parte "segreta".
Gli algoritmi di crittazione asimmetrica hanno il grande vantaggio di essere,
appunto, asimmetrici.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
A truly wise man never plays leapfrog with a Unicorn.

 concatena con un secret e con lo username dell'utente:
Ad ogni modo questo valore secret risiede sempre sul server e quindi chi 
ha accesso al pc... può cambiare sempre le carte in tavola.
Dipende sempre da QUANTO vuoi essere sicuro.
Per quanto sia difficile modificare un bel file di log, aggiungendo una 
stampa cartacea di quest'ultimo complichi di molto le carte ai cattivi.

 cartacea di quest'ultimo complichi di molto le carte ai cattivi.
BRAVO!
Lo scopo della procedura sarebbe proprio quello di evitare 10 faldoni pieni di
carta ogni anno ;)
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Central Intelligence Agency... Now, there's a contradiction in terms.
    --Bart Mancuso, "The Hunt for Red October"

Dipende sempre da QUANTO vuoi essere sicuro.
Yesss.


 Leonardo
Stò facendo una cosa -simile- proprio in questi giorni, volevo
chiederti che libreria hai utilizzato per criptare/decriptare in AES
in php (cbc, cfb o ctr).. facendo una breve ricerca sembra non ce ne
siamo poi molti

in php
Come puoi leggere là sopra, nessuna. Ho usato le funzioni di MySQL.
Lo scopo dell'operazione, lo dico senza vergogna [1], era costruire un
sistema di cui si potesse dire "Cià i dati criptati, ccià!", cosi' che
il cliente potesse farci la ruota a mo' di pavone.
Oddio, è vero che se uno ottiene root sul server e copia i dati, ci fa
la birra; ma è anche vero che r00tando il server, ci vuole zero a fare
una modifichina al file di login perché salvi una copia delle password
degli utenti.
Leonardo
[1] non è vero: mi vergogno come un ladro


 [1] non è vero: mi vergogno come un ladro
ah ok... io stavo considerando una cosa, invece: a me serve un sistema
di criptazione e decriptazione che funzioni sia su python che su php.
AES su python non ci sono problemi, su php invece devo ancora trovare
una soluzione "degna".
Così, per fare qualche prova, mi sono scritto una classe di
criptazione in php e python, e mi domandavo: anche se la mia
funzioncina scritta in 5 minuti sicuramente non sarà avanzata come AES
o simili, non potrebbe paradossalmente essere più sicura?
Mi spiego, siamo tutti d'accordo che per decriptare le stringhe un
attaccante deve avere la stringa criptata e almeno uno dei due
fattori:
1. Hash utilizzato (che sarà diverso per ogni stringa)
2. Funzione di criptazione
Ora, usando funzioni di criptazione comuni, un attaccante ha già un
elemento in mano, invece usandone una 'customizzata' o creata da zero,
anche se riesce a scaricarsi un dump del db e a trovare gli hash,
dovrà capire come sono stati utilizzati per la criptazione.
E' la prima volta che mi trovo a dover criptare dei dati per poi
poterli decriptare, di solito andavo di sha512, quindi non sono molto
esperto..


Fossero 10 faldoni/anno io me li terrei
Fossero 10.000 faldoni allora studierei una procedura informatica.
Ad ogni modo puoi anche salvarti il log mediante invio tramite posta 
certificata ogni tot righe di log ( ma anche ad ogni riga )

 esperto..
una volta cifrato il dato devi avere tutto cifrato, vpn, filesystem, 
record se qualcosa va a donnine non recuperi nulla, fai prima a montare 
un mysql su truecript x tutto il db.
il problema diventa certificare l'utente che fa le modifiche, quindi 
devi fornire all'utente una "chiave pubblica" che tiene in cassaforte 
per cifrare i dati e ti tieni la sua privata per le verifiche ma tuttoil 
sistema deve essere cifrato
anti ne metti 2 di chiavi una lo autentichi al server e l'altra la usi 
per i dati

o simili, non potrebbe paradossalmente essere più sicura?
No :-) ... "Mai, per nessun motivo, implementate la vostra propria
funzione di (de)criptazione", credo l'abbia detto Wietse Venema, o
Gutmann; comunque gente che sa di cosa parla.
Se ti serve AES, suggerisco l'estensione mcrypt, oppure se non hai
modo di mettere estensioni, googla "AES in pure PHP". Ci sono vari
plugin.
Leonardo


 plugin.
Stavo guardando mcrypt, ma non trovo il cipher in AES, ma solo questi:
http://www.php.net/manual/en/mcrypt.ciphers.php
Googlando ho trovato un paio di librerie pure php..proverò.