Newsgroup: it.comp.www.php
Titolo: Criptare un form

Ciao a tutti,
ho creato un form in php per il mio sito internet.
Nello script del form ci sono alcuni dati che vorrei criptare.
Per esempio, mi piacerebbe criptare l'e-mail del destinatario contenuta 
nello script, per evitare che sia usata per spamming.
Sapete se esistono script/software open source utili per questo scopo?
Grazie mille.
Nick

"Nick" <"no address"> ha scritto nel messaggio
news:454a0006$0$19230$
4faf...@reader4.news.tin.it

Qual'è lo scopo? Criptarla per non farla vedere a chi?
-- 
ValeRyo 

ValeRyo Saeba ha scritto:

Lo scopo è impedire che programmi di spamming utilizzino l'indirizzo 
e-mail contenuto nel form per inviare messaggi di spamming.

 e-mail contenuto nel form per inviare messaggi di spamming.
Tutto quello che va e viene dal browser e` insicuro.
Salva l'email del destinatario sul server e processa li` il tuo form.
Bye.

 e-mail contenuto nel form per inviare messaggi di spamming.
L'indirizzo email NON DEVE stare nel form html, altrimenti il form
lo usano per fare di meglio che inviare spam a te...
Mettilo hardcoded nello script e vai sicuro.
-- 
ValeRyo 

 Mettilo hardcoded nello script e vai sicuro.
Forse non ho ben capito io quello che vuole fare Nick, ma immaginando ad 
esempio la procedura di registrazione a un sito, l'utente DEVE :-) inserire 
il proprio indirizzo email (in un form, e dove se no? :-) ). Forse lui 
vorrebbe criptare proprio questo campo, senza ricorrere a trasferimento via 
https.
La cosa che mi viene in mente, almeno in linea teorica, è l'uso di una 
chiave pubblica per criptare sul client (con javascript) e di una privata 
per decriptare sul server (con php) il dato ricevuto via POST. Sempre che in 
javascript esistano valide funzioni di cifratura (altrimenti bisognerebbe 
farsele in casa).
Ad esempio ho trovato qualcosa via javascript solo (non so dirne la validità 
però):
http://www.psi.toronto.edu/~vincent/blog/jscrypt.html
http://www.fourmilab.ch/javascrypt/javascrypt.html
http://www.fourmilab.ch/javascrypt/
rob4you
www.outofmind.eu
 


E more:
http://mysite.mweb.co.za/residents/c.meijer/meringue.htm



In Js lato client:
http://www.ohdave.com/rsa/


grazie mille!
hai perfettamente centrato il punto.
nick
rob4you ha scritto:


 POST.
Ma per far cosa? Per evitare lo sniffing? Mi pare strano che ci
siano spammer a sniffare i moduli di registrazione, recuperano
tante email in altri modi :-)
-- 
ValeRyo 

 
Ma vale la pena implementare una cifratura client side? Se l'utente ha 
il js disabilitato oppure lo script ha problemi con alcuni browser? Opta 
per l'https
	Francesco

 ValeRyo
rob4you
www.outofmind.eu
 

 è possibile usare https?
Mi pare di si, se sei sempre nello stesso dominio.
-- 
ValeRyo 

Salve, io ho invece bisogno di criptare la password prima di inviarla
al server, solamente che i metodi da voi citati permettono anche la
decriptazione... 
Ne conoscete alcuni che non permettono questo?



MD5 e SHA in Javascript. Trovi gli script in rete.
Leonardo
-- 
Dawn is near, the time is short (Human aircraft! Hard to port!)
We eight reindeers of the night work as one in silent flight.
Let not one damn house pass by (Who taught that guy how to fly?)
Each year sees more girls and boys: how many of them can we bring toys?

 decriptazione...
In che senso? Cerchi una funzione one-way? Guarda che alcuni metodi che sono 
stati suggeriti OVVIAMENTE non prevedono lo stesso algoritmo di decifratura 
utilizzato per la cifratura.....altrimenti a che serve!! :-)
Erano stati apposta indicati ad esempio algoritmi a chiave pubblica.
Se poi non interessa affato recuperare la password in chiaro, in nessuna 
situazione, allora Leonardo ti ha indicato due algoritmi possibili, da 
utilizzare via javascript.
Ma come è stato fatto notare...in realtà non serve quasi a nulla....e sai 
perché? Perché se tu vuoi proteggere password da sniffing in questo modo, 
poiché tu la protezione la fai via javascript, a un malintenzionato basta 
inviare la password già cifrata, col nome utente, da un form fittizio. 
Ovviamente il server non può sapere se la password ricevuta è stata criptata 
da js o meno, e quindi il malintenzionato accede al sito con le stesse 
credenziali dell'utente con password cifrata.
Infine bada che TUTTI i metodi permettono una decriptazione........magari 
nessuno spenderà risorse e tempo per decriptare la password cifrata con 
algortimo one-way, utile soltanto al "mio" sito amatoriale! ;-) Fosse il 
sito amatoriale di Bush ancora ancora ci si potrebbe pensare....non so se mi 
spiego....si dice: la spesa non vale l'impresa. :-)
ciao,
rob4you
www.outofmind.eu
 

credenziali dell'utente con password cifrata.
In teoria, tu puoi tenere sul server la password criptata con MD5. Quando
vuoi validare un utente, gli mandi una challenge (es. "obluraschi?").
L'utente inserisce la password in javascript e genera l'MD5 della "somma"
fra l'MD5 della password e quello del challenge: MD5(CONCAT(ch), MD5(pw))
e invia questo al server.
Il server non conosce la password - ma conosce la challenge e l'MD5 della
password; gli basta, per capire se l'utente conosce l'MD5 della password,
il che vuol dire che conosce la pw... anche se questa non e' sul server e
non passa mai sulla rete, ne' in chiaro ne' criptata (ci passa hashata al
quadrato :-) ).
Certo, se entri in possesso del database DEL SERVER, dopo puoi entrare. E
pero' a quel punto probabilmente non ti serve piu' :-)
Ma sniffando MD5(CONCAT(challenge),MD5(password)), ci puoi fare il brodo,
dato che la challenge sara' di tipo unique e non sara' piu' usata.


 dato che la challenge sara' di tipo unique e non sara' piu' usata.
E la challenge come me la conservo sul server ogni volta per fare il 
matching con ciò che è inviato dal client? In sessione?
rob4you

matching con ciň che č inviato dal client? In sessione?
O la tieni in sessione, oppure la generi ogni volta diversa. Per esempio
puoi usare come challenge un altro MD5: secret piu' data(YmdHi). Data la
possibilita' che "scatti" il minuto, farai due o tre giri, partendo da 3
minuti prima:
	$md5pass = SQLFetchValue("SELECT md5pass FROM users WHERE
user='$escape_user';");
	$ok	= false;
	$serial	= (int)(time() / 60) - 3;
	for ($n = 0; $n < 4; $n++)
	{
		$challenge = MD5("$secret:" . ($serial + $n));
		if ($_REQUEST['response'] == md5("$challenge:$md5pass"))
		{
			$ok = true;
			break;
		}
	}
Un attaccante non puo' prevedere a priori la stringa $challenge dato che
non conosce $secret, e non gli serve a molto intercettarla, perche' dopo
cinque minuti non sara' piu' riconosciuta come valida. Fermo restando il
fatto che potrei usare $secret:$_SERVER[REMOTE_ADDR]:$serial, in modo da
legare il challenge anche all'indirizzo IP della controparte. Cosi', uno
che volesse forgiare una credenziale dovrebbe non solo intercettarmi una
connessione, ma riuscire ad effettuare un attacco man-in-the-middle (del
tipo: intercetta la connessione a livello di ADSL, e al momento buono mi
butta fuori.
Il trucco con la password in chiaro potrebbe fartelo il netadmin che per
esempio vuole farti un scherzo (!); per forgiare un'autenticazione cosi'
pero' bisogna che abbia predisposto tutto in anticipo... non e' qualcosa
come lanciare un felino 'ngrep "GET.*Authorization: Basic" port 80...'.
Se c'e' questo rischio, credo che SSL sia l'unica alternativa (oppure si
puo' provare con l'autenticazione Digest).


O la tieni in sessione, oppure la generi ogni volta diversa.
Se mai fanno un campionato per una frase che non vuol dire un cazzo,
con questa entry non c'e' storia :-(
Volevo dire (suppongo) che, o la tieni in sessione, oppure la generi
in modo deterministico. E' chiaro che se non la generassi ogni volta
diversa, tanto varrebbe usare una challenge vuota.


 fatto che potrei usare $secret:$_SERVER[REMOTE_ADDR]:$serial, 
Questa idea mi piace abbastanza.
Devo provare il tutto per vederlo bene in pratica.
rob4you

problema si tratti) del tempo?
Si'. E puoi fare entrambe le cose: lo generi su base casuale o temporale,
e poi lo salvi in sessione. Il dato esiste solo server side. A quel punto
per la possibilita' che sia intercettato e simulato il cookie di sessione
puoi salvare l'IP del client; a meno che uno usi uno di quegli anonymizer
che mandano ogni richiesta tramite un proxy diverso, il controllo mi pare
piuttosto completo.
Certo: uno determinato riesce lo stesso a fare qualcosa, ma questo ti sta
ad insegnare che non devi rompere i coglioni all'FBI o alla Mafia :-)


 ad insegnare che non devi rompere i coglioni all'FBI o alla Mafia :-)
Direi che questo è il sunto perfetto di tutta la conversazione! :-)
grazie per tutti i preziosi consigli....nel caso torno a romperti un 
po' più in là. ^__^
rob4you