[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