[Samba-it] RE: [Samba-it] RE: [Samba-it] RE: [Samba-it] Piccolacuriositàsu autenticazione Samba

[Luigi Iotti]

> From: samba-it-admin at xsec.it [mailto:samba-it-admin at xsec.it]On Behalf Of
> Simo Sorce

> Si ma a cosa serve questo ?

Buona domanda:
Nel mio ragionamento, a togliersi il dubbio accademico sulla
"pammizzabilità" di samba.
Nella pratica, direi che potrebbe servire a usare altri backend di
autenticazione, disfacendosi o estendendo [NT]LM.
Prendiamo il caso dell'OTP "normale" (da cui era nato il thread): non l'ho
mai realmente usato, quindi magari sarò impreciso. Viene passata una
password che però serve una sola volta, quindi se anche viene sniffata
chissenefrega. Potremmo fare un modulo pam-smb-otp che utilizzi come hash HS
l'hash calcolato in base alla OneTimePassword corrente, usandolo per
verificare C ed R che gli sono arrivati da pam. In pratica, il tutto
funzionerebbe come nell'esempio che avevo fatto nella precedente mail, solo
che il client non inserirebbe la sua solita password ma una One Time
password, e il server verificherebbe il response mediante l'hash della One
Time password. In altre parole, sarebbe un rekeying dell'algoritmo di
autenticazione di smb ad ogni autenticazione. Riprendendo l'esempio di
prima:

1) Il client smb (che chiamo CSMB) riceve la One Time password dall'utente,
ne calcola l'hash LM e/o NTLM che chiamo OTHC.
2) Quando CSMB si connette a SSMB, quest'ultimo invia un challenge
pseudocasuale C.
3) CSMB riceve C e in base a questo e ad OTHC che ha appena calcolato
risponde con un response R.
4) SSMB riceve R da CSMB; passa al modulo pam una stringa rappresentante in
senso improprio la "password" costituita da C e da R, separati da un qualche
separatore.
5) il modulo pam per verificare la password prende la One Time password dal
suo repository, ne calcola l'hash che chiamerò OTHS. Se le One Time
passwords usate sono in sincronia ed è stata inserita la password corretta,
OTHS è uguale a OTHC. Si verifica la correttezza di R con C al solito modo.

She poi il tutto sia effettivamente pratico, efficiente, sicuro (o cmq
effettivamente + sicuro che senza OTP)... se ne parla.

> A che pro fare un modulo pam se il calcolo per metà lo devi fare tu e
> comunque il backend deve essere un server samba ?
> A sto punto uso winbind (per le login di client non-SMB) che tiene i
> calcoli dalla parte giusta (dietro pam, non davanti) e usa il repository
> comune senza dover scrivere del codice in più (codice che ovrebbe
> contemplare n-mila casi, uno per ogni backend locale o remoto).
>
> Per intnderci:
>
> caso normale con winbind:
> login nix -> pam -> samba -> repository password
>
> client smb e samba:
> csmb -> samba -> repository password
>
> tua proposta:
> csmb -> samba -> pam -> samba -> repository password

Beh, direi che ci siamo a parte che io non pensavo secessariamente a samba
'dietro' pam: ci potrebbe anche stare qualcosa di diverso, come descritto
sopra, proprio per giustificare l'uso di pam:
OTP -> csmb -> samba -> pam -> pam-smb-otp -> repository One Time passwords

Alla fine, se viene rispettato l'algoritmo challenge/response attualmente
utilizzato, si potrebbe cambiare il significato dell'hash che normalmente è
contenuto in smbpasswd da "hash della password" a "hash di qualcosa
d'altro", che può essere una OTP, una chiave di sessione, un token... avendo
l'accortezza di dire agli utenti di inserire nella casella "password" la
OTP, il token avuto in qualche modo...