Newsgroup: it.comp.www.php
Titolo: Cifrare dati GET/POST

Forse sono un pò OT ma spero che a qualcuno di voi venga un idea brillante
In pratica da una pagina https (notare la "s") viene caricato un link tipo:
<a href="
http://www.sito_non_protetto?cod=A7X9234
">Connetti</a>
ora, avrete notato che il link punta ad un server senza supposto SSL, il 
ché significa che il dato "cod=A7X9234" passerà obbligatoriamente in 
chiaro quindi sniffabile, il dato in questione è praticamente una one 
time password che una volta utilizzata non è più riutilizzabile, ma come 
impedire che venga sniffata ed utilizzata prima del client legittimo? O 
meglio, secondo voi è possibile che il dato in questione venga trafugato?

 legittimo?
Potresti usare di nuovo https.


premesso che questo link contenente questa one-time password è su una
pagina https accessibile tramite autenticazione, nel momento in cui
questo link reindirizza il browser sulla pagina senza protezione ssl
implica che la one-time password venga utilizzata (e quindi non più
riutilizzabile), quindi anche supponendo che venga intercettata
sarebbe inutilizzabile, giusto?
cmq sono anche io dell'idea che l'opzione migliore sia di trovare un
modo per proteggere tramite ssl anche la seconda pagina.

 sarebbe inutilizzabile, giusto?
L'attaccante potrebbe essere in grado di sfruttarla prima dell'utente
(es. attacco "man in the middle").
-- 
Vuoi distribuire il tuo sito web su CD/DVD?
Prova 
http://www.dwebpro.com/
Vuoi diventare un esperto analista PHP/MySQL?
Vieni a fare uno stage con noi: 
http://www.creativepark.it/stage/

 modo per proteggere tramite ssl anche la seconda pagina.
Anche in quel caso l'invio di dati tramite GET o POST presenterebbe un 
problema in quanto i 2 (clent e server) tecnicamente non si sono ancora 
scambiati le chiavi per crittare la sessione quindi passerebbero in 
chiaro comunque

impedire che venga sniffata ed utilizzata prima del client legittimo?
Con questa architettura non c'e' salvezza. Se posso sorvegliare la
connessione, mi basta aspettare la fine dell'handshake e "prendere
il tuo posto" - e sono dentro... Ovviamente devo poter controllare
completamente la connessione client-HTTP.
Puoi migliorare (un po') le probabilita' facendo autenticare Alice
(il client) con autenticazione Digest presso il server Bob (che e'
HTTP). Bob manda un (dumb link a Charlie) ad Alice che si connette
in HTTPS a Charlie. A questo punto Charlie invia una form ad Alice
via HTTPS, contenente un nonce in un campo hidden. Eve non lo puo'
intercettare, perche' e' stato trasmesso in SSL. Alice invia a Bob
una conferma di essersi autenticata con Charlie, e Bob le invia in
risposta una challenge, che Eve intercetta.
Usando una implementazione AJAX di MD5 o SHA-1, trovi il codice su
http://pajhome.org.uk/crypt/md5/
 , Alice calcola l'hash per quella
challenge e per il nonce di Charlie, e lo invia a Bob.
Bob invia a Charlie la stessa challenge e l'ID di Alice. Eve legge
anche questi. Charlie guarda che nonce ha assegnato ad Alice, e ne
calcola l'hash, lo hasha ulteriormente con un secret condiviso fra
lui e Bob, e invia la risposta. Bob hasha la risposta di Alice con
il secret di Charlie, e se sono uguali vuol dire che Alice conosce
il nonce di Charlie.
In tutto questo ambaradàn, la connessione Alice-Bob e' rimasta su,
e di conseguenza l'autenticazione Digest garantisce che Eve non e'
in grado di effettuare un attacco man-in-the-middle.
Se Alice cede al lato oscuro della Forza, al giro dopo si trova in
una situazione identica a quella di Eve perche' il nonce - essendo
un nonce :-) - e' cambiato.
L'attacco classico con un proxy sovvertito non funziona perche' il
proxy comunque non conosce il nonce spedito da Charlie via SSL. Un
"repeating-attack" non funziona perche' Bob usa challenge che sono
sempre diverse, tra l'altro.
Ho l'impressione d'aver appena cannoneggiato una zanzara, ma cosi'
sui due piedi non mi viene nessun sistema - Java a parte - per una
semplificazione che non scopra il fianco a un attacco banale.
Magari - siccome Bob chiede a Charlie solo DOPO che ha ricevuto la
la risposta di Alice! - il secret fra Bob e Charlie e' ridondante;
ma mettercelo costa poco, il grosso CIC e' lo SHA in JS - e quello
mi sa che ci deve stare.
Leonardo (e non garantisco che cosi' tu sia coperto, eh? :-) )
--
The stars have not dealt me the worst they could do:
My pleasures are plenty - my troubles are two.
But oh!, my two troubles, they reave me of rest:

 HTTP). 
Mea culpa che non spiego...
Scopo dell'intero ambaradam è di creare un sistema di login 
centralizzato e certificato ovvero tradotto in soldoni chi utilizzerà 
suddetto sistema dovrà avere la certezza della controparte come se si 
utilizzasse un certificato digitale su smart card (vedi firma digitale) 
ma senza il token, motivo? si vuole qualcosa di quasi gratuito e che 
consenta anche a chi è in hosting di utilizzarlo.
Quindi si esclude a priori la possibilità di autenticarsi sul server x 
in quanto il proprietario/amministratore/hacker potrebbe modificando lo 
script di login archiviare i dati degli utenti, non da meno 
l'autenticazione Digest è soggetta ad attachi man in the middele quindi...

 l'autenticazione Digest è soggetta ad attachi man in the middele quindi...
Aggiungo..
Ho trovato 
www.clipperz.com
 che fa uso di javascript crypto library 
potrebbe essere la soluzione, ora vedo.

l'autenticazione Digest è soggetta ad attachi man in the middele quindi...
Attacchi man in the middle sull'autenticazione Digest ce li hai solo se
ipotizzi uno pseudo-proxy capace di forzare un'autenticazione Basic per
poi riforwardarla in digest; crib attack e plain text attack funzionano
solo nei sogni bagnati della NSA.
A questo punto puoi pure ipotizzare che il CLIENT sia compromesso: a un
simile livello di PEBKAC, e' assai piu' facile introdurre un trojan via
email che non un proxy vigliacco.
Quanto alla compromissione/infedelta' al server Bob, embe'? Se ipotizzi
che Bob sia compromesso, li' sopra ci sono gia' tutti i dati; a che pro
furtare un accesso? Sarebbe come dire che se un tizio riesce ad entrare
in casa tua, puo' attaccare un telefono alla tua presa, e scroccarti la
bolletta. E' vero, ma a quel punto fa prima a usare il tuo telefono e a
svuotarti il frigo gia' che c'e' :-)
Quello che vuoi far tu non e' implementare una sessione sicura; mi pare
che tu voglia una specie di SSL dei poveri :-)
Quand'e' cosi' puoi fare una cosa di questo genere... Alice e Bob usano
una connessione HTTP plain text. Bob invia ad Alice (sotto forma magari
di Javascript) una challenge, Alice fornisce la password in locale (ma,
se il server e' compromesso... ma andiamo avanti!); da challenge e pass
viene creato un hash SHA1. Alice invia l'hash e una propria challenge2.
Verificando l'hash, Bob sa se Alice conosce la password.
Bob a questo punto (es. mediante un filtro in PHP) applica il 3DES all'
output, inviando ogni pagina HTML sotto forma di un "preambolo" HTML JS
con il codice di decodifica, criptato con lo SHA1 di challenge2 e pass;
oppure via XMLHTTPRequest.
Alice recupera l'hash SHA1 di challenge2 e pass che ha salvato - sempre
in locale - e decifra il bolo spedito da Bob, mostrandolo a video. Puo'
farlo con una qualsiasi versione di 3DES in JS:
http://scripts.filehungry.com/product/javascript/security_scripts/javascript_des_implementation
Anche avendo intercettato lo scambio di challenges, non ci si fa nulla,
perche' per avere la chiave del 3DES occorre sapere l'hash di challenge
con una password, che non circola mai.
Questo sistema sembra sicuro ma e' vulnerabile a un MITM attack, basato
sulla sostituzione del codice JS che effettua la decifrazione, e che e'
per forza di cose trasmesso dal server al client.
Per tornare a quel che dicevo prima - "con questa architettura non c'e'
salvezza". Anche SSL, perche' funziona? Perche' il codice SSL c'e' gia'
sul client. Se fosse spedito dal server, addio mi' noccioli.
Leonardo IHVHO


Aggiungo..

Eh, magari :-)
http://www.clipperz.com/users/marco/blog/2007/08/24/anatomy_zero_knowledge_web_application
"In order to avoid storing readable data on the server a zero-knowledge
web application should encrypt and decrypt the data inside the browser"
Siamo d'accordo. Ma il CODICE DELLA WEB APPLICATION da dove arriva, dal
mondo iperuranio di Platone? Nein: arriva dal server.
E cosi' Alice chiede al server Bob "Mandami /".
Eve intercetta la richiesta, la manda a Bob, riceve /, e la spedisce ad
Alice.
Alice chiede al server Bob "Mandami il codice con cui io possa crittare
tutti i miei dati sensibili".
E riceve un codice che critta i dati sensibili, dopo averne spedito una
copia a Eve.
Certo, il codice di Bob si auto-controlla e si auto-verifica. Ma quello
che gira da Alice non e' il codice di Bob, e' quello di Eve, che *DICE*
di autocontrollarsi -- mentendo.
E il codice di Bob e' open source, e non contiene trojan. Naturalmente,
infatti i trojan sono nel codice di Eve.
"The whole source code must be downloaded to the browser before the user
signs in."
Ecco, questo potrebbe essere un buon sistema... ma, chi perde tempo per
farlo? Inoltre, la richiesta di download potrebbe essere riconoscibile;
Eve potrebbe mandare codice onesto, a meno che lo richieda il browser.
Sicche' di nuovo ti serve SSL per poter usare un sistema simile in modo
sicuro... ma se hai SSL, questo sistema non e' necessario :-)
Leonardo "la ruota triangolare elimina uno dei quattro sobbalzi"


 
blowfish php
http://forum.html.it/forum/showthread.php?s=&threadid=786252&perpage=15&highlight=&pagenumber=4
blowfish js
http://www.oclib.com/library/com/oclib/javascript/security/encryption/blowfish/20070210/test.html
non testato!!
il problema e che da https devi fornire la chiave di DEcifratura
all'utente e poi costui deve copiarla dentro a un form per decifare
la password e fare un send form
comunque a IMHO il tuo problema non si pone in quanto la sniffatta e'
rarissima e si ha solo su una wifi/azienda e il men in the middle e'
una cosa rarissima
se NOTI i provider ti mandano la password di accesso per e-mail
ftp, http, imap, pop3, emule, nntp sono tutti SNIFFABILI con wireshark
se il tuo problema e' la ciffratura ti conviene andare coi pizzini
con quelli ci impiegano 30 anni a prenderti con i sistemi cifrati
una settimana; da dove a dove e' sempre in chiaro. anche in https
thor serve a questo non far sapere dove
altra cosa, si sa che cosa e' cifrato dai primi 8 byte
<?
<?php
<?xml
MZ4
PKz
%PDF