Uno dei punti di forza dal punto di vista della sicurezza dei sistemi *nix è la gestione di utenti e password.
(Le configurazioni e gli esempi si riferiscono a Ubuntu standard).
Per i primi è possibile all'admin limitarne privilegi ove necesario opure, definire parametri obbligatori per l'impostazione delle stringhe pw (lunghezza, scadenza).
Solitamente il file che contiene le password, passwd, è posto nella cartella /etc; ma non sempre è così.
Il problema di questo file, oltre a quello di contenere le pw in chiaro è che è (e deve essere) leggibile, e questo lo rende particolarmente vulnerabile ad eventuali intrusioni.
Per ovviare a questo problema dei sistemi lnx è stato adottato l'uso delle shadow password (password shadowing), come default. Il file passwd esiste sempre e contiene le password come asterischi e inserite in righe composte da campi separati da ":" e in questa forma: nome_utente:pw_asterischi:num_utente:num_gruppo_utente:nome_completo_utente_sistema: (non spezzare con cio che segue) directory_utente_in_home:programma_da_avviare L'identificazione dell'utente è affidata ad una funzione che cripta la stringa inserita e la confronta con quella memorizzata.
Se il campo password risulta vuoto, non sarà necessario l'uso di pw per l'accesso (DEPRECATO).
Altrimenti può essere presente un asterisco che indica che l'account è disabilitato.
Ma non è a passwd che è affidato il compito di custodire le nostre password criptate, Con lo shadowing la password in passwd è visualizzabile con un'asterisco, mentre la potete trovare criptata nel file shadow, sempre in /etc. Il file shadow non è che una replica di alcuni dei campi presenti in passwd più qualche campo aggiuntivo, ma può essere letto solo da chi ha l'account di root, quindi molto più sicuro.
I campi che conserva sono user e password (criptata), quelli che aggiunge, o meglio, che è possibile aggiungere riguardano attributi alla password. da passwd => Username come passwd(8 char-min, case-sensitive) Password solo in shadow (sempre separati da ":") => -Numero di giorni (dall' 1-1-1970) dall'ultima modifica della pw. -Numero di giorni prima che la password possa essere nuovamente modificata. Per far si che sia sostituibile quando si vuole settare 0. -Numero di giorni dopodichè la password deve essere obbligatoriamente cambiata.
Per impostare scadenze demandate di anni settare 99999. -Numero dei giorni in cui l'utente verrà avvisato della pw scaduta 7 indica una settimana. -Numero dei giorni dopodichè la pw scade e l'account viene disabilitato. -Numero di giorni trascorsi da quando un account è stato disabilitato (dall' 1-1-1970) -Possibilità di un'ulteriore campo destinato a implementazioni CRIPTAZIONE DELLA PASSWORD Prima parlavo di "funzione" che si occupa di criptare la pasword che noi inseriamo e di verificarne il successivamente l'autenticità, anche se di funzione si tratta è in realtà una libreria gnu utilizzata da linux per la gestione degli account e dei login.: libcrypt.
Esempio, consideriamo questo hash: $1$th8mjsZ5$y4W3WZI3taJcMCgvF2zfH0 Le parti incominciano con "$": - 1 indica che è stato usato MD5, - th8mjsZ5 è il "salt" generato casualmente dal clock - la vera stringa della pw sarà dopo il terzo $ y4W3WZI3taJcMCgvF2zfH0. Quindi basta decriptare questa?
No, serve anche decriptare il salt che è servito con MD5 a criptare la password. METODI DI FORZATURA Considero il Brute force come un modo da DEPRECARE, SEMPRE E COMUNQUE, basato sul "provo tutto" ... prima o poi..., forza bruta senza un briciolo di intelligeza tenete conto che il poi, anche su macchine veloci può durare mesi, dipende dalla lunghezza della pw. Esiste un metodo più affinato del Bruteforce che è l'appoggio a uno o più dizionari di possibili password che vengono anche inserite nelle loro varianti ma anche questo viene complicato dal "moltiplicatore di possibilità" che è il salt che ci costringerebbe a mettere nel nostro dizionario una serie di combinazioni supplementari che lo renderebbero gigantesco, troppo pesante.
Così si sceglie un'altra strada, prima si recupera il salt e lo si decripta, poi si inseriscono le pw del dizionario criptandole con la stringa in chiaro ottenuta. Anche qs operazione non è breve, infatti il salt non è messo per chi vuole decriptare le password, così come qs righe sono scritte per conoscere non per suggerire modi. Inoltre un'altro vantaggio di utilizzare un "codice" salt è che nello stesso sistema possono coesistere utenti con la stessa password perchè sarà diverso l'hash finale.
