[e-privacy] Password in md5...possibile?

AnyFile anyfile at autistici.org
Mon Jun 4 23:41:25 CEST 2007



Vito Catozzo wrote:
> /ns identify <password in md5>
> in modo da evitare lo sniffing.

Non cambierebbe nulla: anche in questo caso se uno riesce a carpire cosa 
hai scritto, basta che riscriva la stessa identica cosa, per ottenere 
l'accesso.

Se non mi ricordo male dovrebbe esserci quelche sistema piu' funzionante 
descritto in qualche sistema per l'autentificazione al POP per prelevare 
la posta in qualche RFC che riguardano il sistema di autentificazione ai 
POP di posta.

Ovviamente il sistema one-time-one-password (una password vale una volta 
sola) in linea teorica sarebbero meglio per evitare questo genere di 
attacco (ma c'e', altrettanto ovvimente, il problema di stabilire una 
password nuova ogni volta).

La soluzione e' un challange tipo quello utilizzato all'inizio (durante 
la contrattazione) delle SSL. In pratica, stringendo all'osso e sperando 
di ricordarmi bene, si tratta di stabilire una chiave segreta uno dei 
due stabilisce questa chiave (simmetrica) e la spedisce all'altro in un 
modo tale che nessuno in mezzo riesca a leggerla (e questo e' il punto 
delicato - vedi piu' avanti). Una volta trasmessa questa chiave chi 
vuole autenticarsi utilizza la chiave per criptare la password e l'altro 
utilizzando la chiave ottiene la password e la usa per stabile se e' 
corretta. In questo passaggio si puo' anche fare che ad essere criptata 
non sia la password ma la sua "riduzione" in md5 (a questo punto poco 
cambia, ma di nuovo, la cosa non porta vantaggi).

Cosi' facendo il rispedire la stessa identica combinazione di dati non 
portera' ad una successiva autentificazione perche' la chiave sara' 
cambiata (ovviamente qui bisogna essere sicuri che non si ripeta 
abbastanza frequentemente la stessa chiave).

Per trasmettere la chiave in modo che non possa essere letta da un 
intruso, se non mi ricordo male, si opera nel seguente modo. A genera la 
chiave (key) e la cripta con un password che conosce solo A, diventando 
crA(key) e viene trasmessa a B che a sua volta cripta quanto ha ricevuto 
  con una sua passowrd diventando crB(crA(key)) e questo punto 
ritrasmette quanto ottenuto. Il "trucco" di questo algoritmo e' che 
l'algoritmo di criptazione e' tale che invertendo l'ordine della 
decriptazione si riesce comunque a risalire a quanto criptato. data 
questa proprieta' A riesce, usando la sua password a passare da quanto 
ricevuto crB(crA(key)) a crB(key) che passa a B il quale riesce ad 
ottenere key.

Tornando al problema iniziale cioe' ad IRC, non vorrei che cercare di 
proteggere la password senza utilizzare SSL sia un po' inutile. Non 
vorrei, infatti, che finche' la connessione non sia tutta in SSL l'uomo 
in mezzo non possa comunque fingersi il legittimo proprietario ed 
inviare messaggio come se fosse il legittimo proprietario del nick, 
anche se non ha la password. Dal momento che la password viene inviata 
solo in quel comando, tutti gli altri comandi, (compreso i comandi per 
l'invio dei messaggi semplici), chiunque riesca a fingere di essere la 
stessa persona che possiede il nick e che si era autenticata per il 
server IRC sara' appunto quel nick atutenticato.

AnyFile

> 
> Che dite?
> 
> Vito Catozzo
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> e-privacy mailing list
> e-privacy at firenze.linux.it
> https://lists.firenze.linux.it/mailman/listinfo/e-privacy



More information about the E-privacy mailing list