Newsgroup: it.comp.java
Titolo: RMI: invio password

Salve,sto realizzando un applicazione client/server con RMI,mi chiedevo
se ci sono problemi di sicurezza nell'invio di una password da
client(serve per login) a server e nel salvataggio di una password in
chiaro su un file nel server.
se si,perchč?e soprattutto, avete un *esempio semplice*(non ho tempo per
mettermi da solo con JCA...) che mi illustri come ovviare a questa
situazione?
Grazie!
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Perchè non utilizzi un algo che ti cripta le pwd? anche in modo semplice
basterebbe a creare problemi
a qualche maleintenzionato.
M.

 a qualche maleintenzionato.
Se la cripto(es:aggiungo 57 ad ogni byte) e poi il server la
decripta(es:sottrae 57 ad ogni byte) posso stare più sicuro?
Ma sicuro di cosa poi...?
dov'è che ci possono essere problemi?
scusate la banalità,ma vorrei capire dove e come nascono i problemi.


 scusate la banalità,ma vorrei capire dove e come nascono i problemi.
Il problema nasce quando non vuoi che qualche esterno
messaggio segreto tra due entitrà.
L'unico modo è rendere il messaggio leggibile a patto di
conoscere una chiave di decifrazione.
Nel tuo caso è "shifta ogni ASCII avanti di 57".
O meglio nel tuo caso la chiave è "57" e l'algoritmo
è "cifra l'ASCII in avanti".
E' molto più sicuro un cifrario simmetrico (o asimmetrico).
Ma non sto ad approfondire perchè a quanto ho capito
non hai tempo per andare a vedere le librerie apposite.
Tutto dipende dal grado di sicurezza che ti serve.
Però ripeto che piuttosto che un cifrario come il tuo
è meglio niente!
Luca Paganelli.
PS: Poi ci sarebbe da risolvere il problemino della
password in chiaro salvata sul Server.
Uno che ti si intrufola nel server se le vede tutte!!!

 
Mi sono spiegato male...come fa uno mentre io sto mandando la pwd in un
metodo del mio programma RMI a prendermi la password?!
E inoltre,se riesce a prendermi la password(e vorrei capire come) o ad
aprire i files sul disco del server a questo punto può rintracciare
benissimo il .class del server e vedere come decripta la pwd il server e
lo può fare lui, o no?i conti non mi tornano...
Perdonatemi l'ignoranza e grazie


 lo può fare lui, o no?i conti non mi tornano...
Un conto e' leggere le comunicazioni, un'altro e' accedere al disco del
server. Questo non dovrebbe essere altrettanto facile.
In ogni caso nei .class potrebbe esserci l'algoritmo per
crittare/decrittare la password, ma non la chiave utilizzata.
Un esempio che utilizza un'algoritmo a chiave pubblica:
Il server genera una coppia di chiavi di crittazione/decrittazione
(C e D).
D viene tenuta dal server mentre C viene inviata al client.
Il client cripta la password utilizzando C e la invia al server.
Il server decripta la password utilizzando D.
Come vedi un malintenzionato che legga le comunicazioni riescce a
ottenere C ma non D e quindi non puo' decriptare il messaggio inviato
dal client. Accedere ai sorgenti del programma poiche' questi non
contengono D che viene generata casualmente durante l'esecuzione.
Naturalmente tutto dipende dal livello di sicurezza che vuoi
raggiungere. A chi vuoi impedire di conoscere la password?
Al tuo fratellino smanettone?
Al tuo capo che vuole controllare la tua posta?
Alla ditta concorrente che vuole ottenere i tuoi progetti?
Al tuo governo?
In realta' c'e' chi sostiene che gli unici casi reali (dal punto
di vista tecnico) sono il primo e l'ultimo ;-)
Andrea


 lo può fare lui, o no?i conti non mi tornano...
Sì, però nella crittografia ciò che conta non è l'algoritmo - infatti sono
tutti pubblici - ma la chiave segreta.
Nello scenario più semplice Client e Server si inventano due numeri
a caso ed utilizzano il protocollo di scambio di Diffie-Hellman per cui
perverranno ad una stessa chiave comune (un altro numero) come
risultato di un'operazione di esponenziazione modulare.
Quindi si pattuisce una stessa chiave senza scambiarsela!!!
Nessun'altro oltre a loro potrà evincere tale numerello perchè è
funzione dei due numeri a caso scelti in precedenza!
A questo punto puoi usare tale numero condiviso - o parte d'esso -
come chiave per un cifrario simmetrico.
Ora cifri la password e la dai al Server!
Per l'immagazzinamento della password puoi, ad esempio, sfruttare
le proprietà della codifica Hash.
E' facile ottenere l'hash (ad esempio SHA-1) di un messaggio in chiaro,
è difficilissimo (per non dire impossibile) fare il processo inverso.
Quindi se anche uno ti trova il file e quindi la password trova solo
l'hash e non può risalire alla password vera e propria!
Luca Paganelli

 Al tuo governo?
no,è un progetto a fine didattico che non ha nemmeno questa
specifica,però mi sembrava bello considerare anche l'aspetto della
sicurezza,anche perchè potrebbe essere sempre utile...per il fratellino!
;-)


 l'hash e non può risalire alla password vera e propria!
qui non ti seguo,se salvo l'hash come fa il server stesso a risalire al
messaggio originario di cui ha salvato solo l'hash...?


 messaggio originario di cui ha salvato solo l'hash...?
Non lo fa. Tu invii la password al server, lui ne calcola l'hash e lo 
confronta con quello salvato. Se sono uguali OK, altrimenti la password 
e' sbagliata.
Anche se uno accede al file con gli hash delle password non puo' 
risalire alle password (se sono scelte bene) e quindi non se ne fa nulla.
In questo modo ad esempio funziona l'autenticazione di Linux e Unix.
Nell'implementazione originale, se non sbaglio, addirittura il file 
delle password (o meglio degli hash) e' leggibile da tutti gli utenti 
(adesso di solito si utilizza il sistema delle shadow password, che 
utilizza un file protetto per la memorizzazione degli hash).
Unico inconveniente di questo sistema e' che se uno si dimentica la 
password non puo' semplicemente farsela ridare dall'amministratore 
perche' neanche lui puo' scoprirla. L'unico modo e' impostare una nuova 
password (cosa che l'amministratore puo' invece fare).
Andrea

 risalire alle password (se sono scelte bene) e quindi non se ne fa nulla.
Ancora una volta molto chiaro :-)
Perň non capisco una cosa:se io conosco l'algoritmo per calcolare
l'hash(ad es. perchč lo leggo nel .class) e il valore dell'hash (perchč
lo leggo da file) non credo sia cosě difficile fornire una password
,magari diversa dall'originale,che abbia lo stesso valore hash...o no??


 ,magari diversa dall'originale,che abbia lo stesso valore hash...o no??
E invece e' quasi impossibile.
Ci sono funzioni che e' molto difficile invertire. Ti faccio un esempio:
e' molto facile fare il prodotto di due numeri primi molto grandi.
E' molto piu' difficile dato il prodotto trovare i fattori.
Adesso non so dirti come funziona il calcolo dell'hash ma so che
utilizza una funzione molto difficile da invertire.
Poi se hai una grossa potenza di calcolo e qualche secolo a
disposizione si puo' anche fare...
Andrea


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrea Polci wrote:
| E invece e' quasi impossibile.
Confermo.
A patto, ovviamente, che sia un hash "fatto bene".
Ti consiglio di usare SHA1 ("Secure Hashing Algorithm", e il nome non č
un eufemismo) o, ancora melgio SHA-256.
Sarebbe inoltre consigliato applicare un sale e hashare ripetute volte,
in modo da aumentare il tempo di calcolo all'attaccante ancora di piů...
in caso ti interessasse piů nello specifico, rimanderei la discussione
su it.comp.sicurezza.crittografia
| Adesso non so dirti come funziona il calcolo dell'hash ma so che
| utilizza una funzione molto difficile da invertire.
Se vi interessa approfondire, su it.comp.sicurezza.crittografia se ne
parla spesso 0=)
| Poi se hai una grossa potenza di calcolo e qualche secolo a
| disposizione si puo' anche fare...
Se le cose sono fatte bene no, non con i computer e la matematica
attuali, quantomeno 0=)
Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj/+uYIACgkQaJiCLMjyUvuz7gCgyMoSqv3/ytd52x9hUbKR62qV
v5cAnRUM3MvDNB0dpo/oP5b0YkRWht5R
=BD+y
-----END PGP SIGNATURE-----

mi avete fatto capire un po' di cosette... :-)
