Re: Radius: encryption o hashing della password?

[Giuseppe Bianchi < >]

> Dov'è che sbagliamo nel ragionamento?

Sbagliate NON il ragionamento, che mi sembra 
perfettamente corretto da un punto di vista 
meramente tecnico, ma il PUNTO DI VISTA: Radius 
NON e' uno specifico ALGORITMO O SISTEMA di 
autenticazione (ad esempio un PAP), ma un 
PROTOCOLLO GENERICO per supportare soluzioni il 
piu' possibile disparate di autenticazione 
remota. E come tale DEVE essere progettato in 
modo da essere indipendente dalle SPECIFICHE 
caratteristiche dell''algoritmo/sistema di 
autenticazione che uno vuole usare!!

Per capirci meglio:

> Pongo quindi le domande: il server RADIUS 
> registra le password in chiaro o hashate?
> Intuitivamente verrebbe da pensare che la 
> password è salvata in chiaro, in quanto se 
> paradossalmente l'utente dimenticasse la 
> password il server sarebbe in grado di fornirla. 
> Se il server dunque salva la password in chiaro, 
> dal ragionamento fatto al punto 2), Hashing 
> delle password o encryption risulterebbero entrambi metodi validi.

State imponendo, come "intuitiva" una condizione 
SPECIFICA sul modo in cui un database di passwd 
deve operare! In certi contesti (pochi) andra' 
bene memorizzare le passwd in charo, in altri 
(molti di piu') con hash MD5, in altri ancora con 
hash SHA512, in altri ancora in un sistema di 
storage criptato: sono TUTTE cose che NON devono 
interessare a RADIUS, che e' SOLO un protocollo 
per permettere ad un NAS remoto di COMUNICARE con 
un server centrale. That's it! Imporre un limite 
sul tipo di comunicazione, ed in particolare 
rendere irreversibile un messaggio (nel qual caso 
la passwd) sarebbe una scelta decisamente... poco 
lungimirante (per non dire di peggio). Ed in 
questo giudizio non entro nel merito del fatto 
che questa scelta imponga di memorizzare le 
passwd in chiaro. Che di per se e' una ulteriore 
ragione per rigettare questa scelta! Ma voi 
accettereste di memorizzare una password in 
chiaro su un server a cui il system 
administrator, magari gentaglia tipo un tale Zio 
Proto :-) - puo' accedere quando vuole??

Comunque, per vostra informazione, pochissimi 
oggi usano il campo user-passwd per trasportare 
la passwd di utente (peraltro vedremo in una 
prossima lezione che tale approccio e' non 
robusto). Se usano delle passwd di utente le 
trasportano in modo diverso (ovviamente sempre 
dentro radius ma in qualche variante di EAP - lo vedremo).

Hope this clarifies,

GB

At 19.25 13/03/2008, Andrea Magurano wrote:
> Salve prof. Bianchi,
> volevo chiedere maggiori chiarimenti riguardo 
> l'encrypting della password nella richiesta di 
> autenticazione dal NAS al server RADIUS.
> La questione è: perchè sono costretto a criptare 
> la password piuttosto che inviare l'HASH di essa?
>
> 1) Poniamo il caso in cui il server RADIUS 
> memorizzi le password hashate: il NAS invia la 
> richiesta mediante lo XOR tra la password in 
> chiaro e l'HASH(numero casuale | segreto). Il 
> server RADIUS è in grado di decriptare la 
> password, ne fa un HASH e lo confronta con 
> quello presente nel database. Qualora volessi 
> inviare la password mediante HASH(password | 
> numero casuale | segreto), il server non sarebbe 
> in grado di confrontare la sua password hashata 
> in memoria con la stringa che gli arriva. 
> Secondo questo ragionamento il server RADIUS ha 
> bisogno di ricevere la password criptata per riconoscere l'utente.
>
> 2) Poniamo ora il caso in cui il server RADIUS 
> memorizzi le password in chiaro: il NAS invia la 
> richiesta mediante lo XOR tra la password in 
> chiaro e l'HASH(numero casuale | segreto). Il 
> server RADIUS è in grado di decriptare la 
> password, e la confronta direttamente con quella 
> presente nel database. In realtà il NAS potrebbe 
> benissimo inviare la password mediante 
> HASH(password | numero casuale | segreto) e il 
> server RADIUS confrontare la stringa in arrivo 
> con un HASH(password | numero casuale | segreto) 
> da lui stesso calcolato. In questo caso 
> l'HASHING della password sembrebbe una giusta alternativa all'encrypting.