Newsgroup: it.comp.os.linux.sys
Titolo: shadow crypt

Se qualcuno riuscisse per caso a prelevarsi lo shadow di una macchina, con
un computer potente, un buon programma, o magari un po' di fortuna, potrebbe
riuscire a beccare le password di quella macchina.
Questo perchè la stringa che contiene la password, è cryptata secondo un ben
preciso algoritmo che non dipende da parametri (penso); infatti posso
copiare uno shadow tranquillamente su un'altra macchina (questo è molto
comodo, specialmente per i cluster, ma a me interessa un altro aspetto).
Se io riuscissi a cryptare tale file con una chiave esclusiva, dipendente da
qualcosa (escluderei l'hardware perchè se sposto l'harddisk sto incasinato,
ma il decidere come costruire la chiave è un dettaglio che va analizzato in
seguito), e la funzione di login riuscisse a leggerlo sfruttando quella
chiave, credo che la sicurezza verrebbe notevolmente aumentata.
Cosa ne pensate?
Matteo

Sgranocchiando il cranio di Matteo Rossini, vi trovai inciso:

Che devi stare molto attento a cosa fai e a come intendi realizzarlo. Il
file shadow contiene hash, non password crittate, e la differenza non è
banale.
Un hash è per definizione una funzione non invertibile. Il che vuol dire
che non è possibile realizzare procedure di "traduzione" delle password da
una chiave all'altra, proprio perchè algoritmo non invertibile, e che, se
non hai modo di reperire la chiave su cui vuoi basare la generazione
dell'hash, sei fregato: il db degli utenti è perso. (Ne sa qualcosa
qualcuno, qui, che ha avuto la bella idea di progettare l'autenticazione
degli utenti di un applicativo web basandosi sulla $HOSTNAME. Cambi
l'hostname causa cambio dominio, salta tutto...) Viceversa, se la chiave è
recuperabile all'interno del sistema, hai la posibilità di replicare il db
degli utenti, ma in compenso hai ottenuto solamente di spostare il
problema da un'altra parte: se sono riusciti a leggere il file shadow,
possono leggere praticamente tutto, compreso il posto in cui la chiave
viene conservata.
A questo punto otterresti l'unica protezione aggiuntiva di uno schema di
autenticazione non standard, che però IMHO sa molto da security through
obscurity...
I miei 2 centesimi...
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

scoperta dell'acqua calda!
se ti prelevano lo shadow, accessibile solo a root, possono già fare 
qualsiasi cosa!
-- 
Davide Corrado
Un modello di elaborazione composito è un'architettura che
utilizza un ambiente di esecuzione distribuito e basato
sulla ricerca per mettere a disposizione e gestire una serie
di risorse software orientate ai servizi

 obscurity...
Infatti non è questo che voglio. Come funziona OpenSSH, voglio che la
segretezza dipenda solo dalla chiave e non dall'algoritmo.
Matteo

 qualsiasi cosa!
Non è detto che il tizio riuscirebbe a prendere lo shadow tramite login di
root.
Un banalissimo esempio è questo:
1) configuro un server ftp in modo da accettare login utenti ma solo in sola
lettura (non so se si può fare, ma è solo un esempio)
2) con un ftp client mi connetto come root
3) dimentico aperta la sessione
4) il tizio viene! ora può prelevare tranquillamente lo shadow ma non può
far casini sul computer.
ho preso l'ftp, ma potrebbe anche essere un dipendente a cui viene data una
shell di root per qualche minuto; non può mettersi al momento a fare niente
di particolare.
Oppure sfruttare un baco di qualche programma per riuscire a leggere file
riservati
eccetera
Ma a parte il fatto che aumenti o meno la sicurezza, è fattibile la cosa?
Matteo

 segretezza dipenda solo dalla chiave e non dall'algoritmo.
Ok, quindi, posto che della possibilità di recuperare il db degli utenti
in caso di schianto non te ne frega nulla, mi pare di capire, a te
interessa come poter rendere impenetrabile il file delle password inutile
anche a chi ne venisse in possesso.
Risposta: non c'è modo.
Una chiave da qualche parte deve essere disponibile, al sistema, per
effettuare la generazione dell'hash.
Se il sistema viene compromesso in maniera tale da poter accedere in
lettura con privilegi di root (ed è l'unico caso in cui possano prelevarti
il file shadow), possono anche prelevarti la chiave che il sistema
utilizza, fosse anche analizzando /proc/kcore, e da lì proseguire. L'unica
difesa che hai, appunto è il fatto che possono *non* sapere dove la chiave
è mantenuta, ma non mi pare un granchè. Accedere a /etc/shadow o a
/etc/master-system-key (per fare un esempio) non fa molta differenza.
Quello che al massimo puoi fare è utilizzare strong-encription per le
password.
Ad esempio openbsd critta le password in blowfish. Nulla ti vieta di
configurare pam per fare altrettanto...
Poi, esistono le patch per il mac e le acl sui filesystem, ma qui è
un'altra storia...
Byez.


 far casini sul computer.
5) mi martello le palle fino a che non riesco scrivere la parola CAZZONE in 
aramaico antico.
Root non deve essere usato per ftp e amenità varie, ma solo ed unicamente 
per i compiti di admin. Quando l'admin deve anche solo andare in bagno, è 
bene che chiuda tutto ciò che utilizzi root (servizi a parte ovviamente)
-- 
| /
| \Byte - Andrea Briganti - kbytesys(aaattt)
tiscali.it
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Un errore di lancio o puntamento rende la bomba intelligente stupida

Va bene, ok, scusate... era solo una idea.
Matteo

Cosa ne pensate?
Non e` una buona idea.
In primis, perche` tocca rifare tutti i software che si interfacciano a
shadow per l'autenticazione (pam, you know?).
In seconda battuta perche` e` un'accrocchio. Una volta "trovato" il
metodo di generazione della chiave, hai risolto il trick, il software
non ha piu` nessun giovamento (ne tantomeno la sicurezza), e si e` solo
inserito un layer di confusione (ntlm, you know?).
Infine: da me shadow e` 600. Se puoi copiare shadow, sei gia` root. A
quel punto, non mi pare che il problema piu` serio sia "lo storage delle
password".
-- 
        A bleeding heart can be hell on the carpeting.
Maurizio - Tannoiser - Lemmo
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it