# cambiare metodo di cifratura

## .:chrome:.

possibile che a nessuno sia mai venuto in mente di abbandonare MD5 per la crittografia delle password in /etc/shadow, ed in generale in tutti quei meccanismi a cui si appoggia PAM?

cercavo il modo di usare SHA-256, ma mi trovo un bel po' spiazzato. la letteratura sull'argomento (metodi di crittografia usati/rinconosciuti da PAM) è abbastanza scarsa.

se qualcuno ha un buon suggerimento... il mio mal di testa ringrazia  :Wink: 

----------

## Frez

La cosa stuzzica un po' anche me. Purtroppo al momento sono sprovvisto di suggerimenti intelligenti (ma posso contribuire al mal di testa  :Smile:  )

Una volta il file delle password era leggibile anche da altri che non fossero root, quindi il contenuto doveva necessariamente essere criptato.

Adesso che solo root puo' leggerlo, la criptazione del contenuto non dovrebbe piu' essere un requisito strettamente necessario, o no ?

Ok, un po' di cifratura non fa mai male (  :Smile:  ) ma e' bene sapere dove metterla e dove invece ha poco significato.

Tutto questo per dire che forse non si cercano metodi di cifratura piu' forti per il file /etc/shadow solo perche' cio' non comporterebbe un aumento sostanziale di sicurezza.

----------

## ProT-0-TypE

 *Frez wrote:*   

> Tutto questo per dire che forse non si cercano metodi di cifratura piu' forti per il file /etc/shadow solo perche' cio' non comporterebbe un aumento sostanziale di sicurezza.

 

In linea di massima se la password è una vera p4s$W0rD, aggiungendoci il fatto che andrebbe cambiata regolarmente e che il file shadow non è accessibile direttamente agli utenti la cosa è abbastanza sicura di per se.

Però sapere come utilizzare altri metodi di cifratura mi sembra una cosa mooolto interessante  :Very Happy: 

----------

## Cazzantonio

L'argomento è interessante... d'altra parte per leggere le password si deve poter accedere a /etc/passwd quindi diciamo che prima l'attaccante deve essere riuscito anche ad ottenere i permessi root (nel qual caso il problema della cifratura diventa secondario direi...)

Semmai una buona cifratura può assicurare agli utenti che il root non legga mai le loro password... il che potrebbe essere utile visto che la stragrande maggioranza della gente usa la stessa password per tutto, compreso il codice del bancomat...   :Rolling Eyes:   :Laughing: 

Direi che più che un problema di cifratura è un problema di cultura...

----------

## gutter

Preciso che non si tratta di MD5 SHA sono degli algoritmi di hashing e non di crypting.

----------

## .:chrome:.

 *gutter wrote:*   

> Preciso che non si tratta di MD5 SHA sono degli algoritmi di hashing e non di crypting.

 

giusta osservazione.

la questione comunque è abbastanza grave...

per la cronaca, /etc/passwd deve necessariamente essere leggibile da cani & porci, ciò che non è necessario leggere per il corretto funzionamento del sistema è l'hash delle password.

ora... va bene che /etc/shadow è leggibile solo dal sottosistema PAM ed in particolare da login, ma gradirei molto il fatto di poter usare algoritmi di hashing più solidi di MD5 e SHA-1.

se si potesse fare questo, sarebbe possibile dirottare qualunque tipo di autenticazione a PAM e lasciare a lui il lavoro sporco. il problema è però fargli digerire qualche sistema di hash che non sia MD5 o SHA-1, perché quegli hash girano "in chiaro" sulla rete, e ciò non è bello...

----------

## Dr.Dran

Mmmm... capisco il problema legato alla sicurezza, ma credo che si possa provare a crearsi un plug di pam ex-novo, prendendo spunto da altri moduli creati sulla falsariga di pam-usb si potrebbe ottenere un sottosistema di autenticazione che magari apre una sorta di tunnel criptato in SHA o altro e poi vada a leggere il file shadow... ma questa è + una idea campata in aria...   :Wink: 

Comunque se qualcuno avesse qualche altra idea migliore si faccia sentire   :Wink: 

----------

## neryo

 *k.gothmog wrote:*   

>  *gutter wrote:*   Preciso che non si tratta di MD5 SHA sono degli algoritmi di hashing e non di crypting. 
> 
> ora... va bene che /etc/shadow è leggibile solo dal sottosistema PAM ed in particolare da login, ma gradirei molto il fatto di poter usare algoritmi di hashing più solidi di MD5 e SHA-1.
> 
> 

 

per me il problema e' interessante, ma non si pone.. sono algoritmi unidirezionali, quindi e' impossibile da un hash(password) tornare indietro.. come ha detto gutter sono di hashing e non di crypting! Quindi la solidita' degli algoritmi di hash e' dovuta solo al fatto che puo esistere un digest duplicato, ma questa possibilita' e' veramente remota, tante' che li utilizzano..

----------

## .:chrome:.

 *neryo wrote:*   

> per me il problema e' interessante, ma non si pone.. sono algoritmi unidirezionali, quindi e' impossibile da un hash(password) tornare indietro.. come ha detto gutter sono di hashing e non di crypting! Quindi la solidita' degli algoritmi di hash e' dovuta solo al fatto che puo esistere un digest duplicato, ma questa possibilita' e' veramente remota, tante' che li utilizzano..

 

hai ragione. quelli di hashing sono algoritmi unidirezionali.

il problema è che sia SHA-1 che MD5 sono BROKEN, e già da un bel po' di tempo, ormai...

tra un po' cominceremo a vedere girare per la rete algoritmi più efficienti del solto script idiota per craccare SSH, e questi andranno a segno.

la situazione è molto più grave di quanto la gente non creda, e penso sia ora di correre ai ripari

----------

## neryo

ti dico solo che le probabilita' vere che con sha-1 si verificano delle collisioni e' di circa 2^80 tentativi, considera che ricava  da un docuemnto di grandezza qualsiasi un hash di 160 bit... è quindi piu' che evidente che esisteranno delle collisioni  (coppie di documenti diversi che generano lo stesso hash)

leggete questo per farvi meglio l idea http://www.cwi.it/showPage.php?template=rubriche&id=11785

----------

## .:chrome:.

 *neryo wrote:*   

> ti dico solo che le probabilita' vere che con SHA-1 si verificano delle collisioni e' di circa 2^80

 

lo so... o meglio... siamo scesi a 2^69.

il problema comunque non è SHA, sono le 8 ore di calcolo che servono per generare una collisione in MD5.

direi che è pochino

----------

## makoomba

 *k.gothmog wrote:*   

> il problema comunque non è SHA, sono le 8 ore di calcolo che servono per generare una collisione in MD5.
> 
> direi che è pochino

 

un conto è generare una collisione conoscendo l'hash, altro discorso è tentare di beccare una password avendo a disposizione un tentativo ogni tot secondi.

----------

## comio

 *k.gothmog wrote:*   

>  *neryo wrote:*   per me il problema e' interessante, ma non si pone.. sono algoritmi unidirezionali, quindi e' impossibile da un hash(password) tornare indietro.. come ha detto gutter sono di hashing e non di crypting! Quindi la solidita' degli algoritmi di hash e' dovuta solo al fatto che puo esistere un digest duplicato, ma questa possibilita' e' veramente remota, tante' che li utilizzano.. 
> 
> hai ragione. quelli di hashing sono algoritmi unidirezionali.
> 
> il problema è che sia SHA-1 che MD5 sono BROKEN, e già da un bel po' di tempo, ormai...
> ...

 

comunque credo che la soluzione sia implementare ldap ed usare quello per l'AAA. shadow & co. sono mal pensati di loro...

ciao

----------

## .:chrome:.

 *makoomba wrote:*   

> un conto è generare una collisione conoscendo l'hash, altro discorso è tentare di beccare una password avendo a disposizione un tentativo ogni tot secondi.

 

errore. basta avere un solo hash una sola volta. poi ci si deve calcolare qualcosa che collida. fine.

applicando non la ricerca esaustiva, ma un po' di crittanalisi, anvendone la possibilità, si ridurrebbero drasticamente i tempi di generazione

----------

## makoomba

 *k.gothmog wrote:*   

> errore. basta avere un solo hash una sola volta. poi ci si deve calcolare qualcosa che collida. fine.
> 
> applicando non la ricerca esaustiva, ma un po' di crittanalisi, anvendone la possibilità, si ridurrebbero drasticamente i tempi di generazione

 

scusa ma non ti seguo.... quale hash dovresti avere ?

----------

## .:chrome:.

 *makoomba wrote:*   

> scusa ma non ti seguo.... quale hash dovresti avere ?

 

l'hash della password che vuoi ottenere.

non si parla solo di SSH, ma di un'infinità di servizi che usano MD5. basta ottenere un hash e con poco sforzo (e gli strumenti giusti) si potrebbe ottenere una stringa che genera lo stesso hash

----------

## makoomba

 *k.gothmog wrote:*   

> l'hash della password che vuoi ottenere.

 

... ma se hai l'hash che sta in /etc/shadow sei già root, no ?

la "weakness" di md5, in questo contesto, influisce veramente poco.

diverso è il discorso delle digital signatures, ma non mi pare si stesse parlando di questo nel 3d.

----------

## .:chrome:.

 *makoomba wrote:*   

>  *k.gothmog wrote:*   l'hash della password che vuoi ottenere. 
> 
> ... ma se hai l'hash che sta in /etc/shadow sei già root, no ?
> 
> la "weakness" di md5, in questo contesto, influisce veramente poco.
> ...

 

non è necessario essere root per leggere l'hash della password in /etc/shadow, esistono parecchi modi per farlo, considerando che la protezione che c'è su quel file è abbastanza scarsa, e poi non devi leggere necessariamente da /etc/shadow, puoi anche stare ad aspettare mentre sei in ascolto sulla rete. l'hash della password passa in chiaro

----------

## neryo

 *k.gothmog wrote:*   

> 
> 
> il problema comunque non è SHA, sono le 8 ore di calcolo che servono per generare una collisione in MD5.
> 
> direi che è pochino

 

con quali risorse computazionali in 8 ore?

----------

## .:chrome:.

 *neryo wrote:*   

> con quali risorse computazionali in 8 ore?

 

nel 2005 è stato dimostrato che bastano 8 ore ad un P4 a 2.1GHz per trovare due messaggi che collidono.

cercherò di farti avere la fonte esattaLast edited by .:chrome:. on Fri Oct 07, 2005 11:19 pm; edited 1 time in total

----------

## comio

 *k.gothmog wrote:*   

>  *makoomba wrote:*    *k.gothmog wrote:*   l'hash della password che vuoi ottenere. 
> 
> ... ma se hai l'hash che sta in /etc/shadow sei già root, no ?
> 
> la "weakness" di md5, in questo contesto, influisce veramente poco.
> ...

 

aspetta aspetta... dipende dal protocollo che usi... l'md5 non viene usato così diffusamente... in generale gli hash vengono comunque crittati con eventuali chiavi di sessione. Questo non esclude che ci siano protocolli bacati. In generale comunque l'hash di una password non deve transitare in chiaro sulla rete a prescindere se è sha1 o md5, eventualmente si fa passare l'hash della password+un numero pseudocasuale conosciuto dai due estremi che varia (tipo i token rsa per intenderci)... ma è già una soluzione non bella e non furba.

ciao

----------

## .:chrome:.

 *comio wrote:*   

> In generale comunque l'hash di una password non deve transitare in chiaro sulla rete a prescindere se è sha1 o md5, eventualmente si fa passare l'hash della password+un numero pseudocasuale conosciuto dai due estremi che varia (tipo i token rsa per intenderci)... ma è già una soluzione non bella e non furba.

 

hai ragione, ma se stiamo a guardare, la storia di protocolli e metodi di autenticazione/protezione è costellata di fallimenti clamorosi dovuti a sviste anche più leggere di questa (WEP, per citarne uno)

----------

## X-Drum

 *Cazzantonio wrote:*   

> L'argomento è interessante... d'altra parte per leggere le password si deve poter accedere a /etc/passwd 

 

nella maggior parte delle distro gnu/linux è necessario accedere anche al file /etc/shadow,

dove la password è contenuta, in /etc/passwd vi sono le informazioni sull'account e non la pwd

----------

## neryo

 *k.gothmog wrote:*   

>  *neryo wrote:*   con quali risorse computazionali in 8 ore? 
> 
> nel 2005 è stato dimostrato che bastano 8 ore ad un P4 a 2.1GHz per trovare due messaggi che collidono.
> 
> cercherò di farti avere la fonte esatta

 

l'articolo dovrebbe essere questo http://eprint.iacr.org/2005/151.pdf e questo in italiano http://www.communicationvalley.it/cryptogramPdf/Marzo2005.pdf

----------

## .:chrome:.

 *neryo wrote:*   

> l'articolo dovrebbe essere questo http://eprint.iacr.org/2005/151.pdf e questo in italiano http://www.communicationvalley.it/cryptogramPdf/Marzo2005.pdf

 

eccolo qui: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf

mi ricordavo male. la macchina è un P4 a 1.6 GHz (di bene in meglio  :Very Happy:  )

ancora più preoccupante: due certificati X.509 "diversi" che collidono: http://www.win.tue.nl/~bdeweger/CollidingCertificates

e qui ci sono due ps interessanti http://www.cits.rub.de/MD5Collisions

----------

## neryo

 *k.gothmog wrote:*   

>  *neryo wrote:*   l'articolo dovrebbe essere questo http://eprint.iacr.org/2005/151.pdf e questo in italiano http://www.communicationvalley.it/cryptogramPdf/Marzo2005.pdf 
> 
> eccolo qui: http://cryptography.hyperlink.cz/md5/MD5_collisions.pdf
> 
> 

 

ottimo ora me lo leggo!!   :Wink: 

----------

## makoomba

I contesti di autenticazione non sono affetti da problemi di collision fintanto che lo "shared secret" resta tale.

Se l'hash dovesse transitare in chiaro sul mezzo insicuro, tanto varrebbe trasmettere direttamente la password. 

Viceversa, considerate il caso in cui distro X distribuisca le iso attraverso il p2p, mettendo sul sito l'md5sum delle iso stesse: un utente scarica i cd tramite bittorrent e verifica che l'md5sum corrisponda all'originale per assicurarsi che il contenuto non sia stato alterato.

La weakness di md5 permette di generare una iso diversa dall'originale ma che restituisce la stessa hash.

Oppure, preparo due documenti che "collidono": una petizione e un pagerò di  5000; ti invio la petizione e tu la firmi digitalmente.

Se l'algoritmo considera l'md5 del documento, l'applicazione della tua firma digitale risulterà identica anche per il pagherò.

----------

## neryo

 *makoomba wrote:*   

> 
> 
> Viceversa, considerate il caso in cui distro X distribuisca le iso attraverso il p2p, mettendo sul sito l'md5sum delle iso stesse: un utente scarica i cd tramite bittorrent e verifica che l'md5sum corrisponda all'originale per assicurarsi che il contenuto non sia stato alterato.
> 
> La weakness di md5 permette di generare una iso diversa dall'originale ma che restituisce la stessa hash.
> ...

 

Si, queste secondo me sono i problemi reali che potrebbero verificarsi con la rottura di un algoritmo di hashing piu' che problemi nell autenticazione remota..

----------

## Dr.Dran

Mi intrometto da profano, e chiedo scusa per il mio primo intervento perchè non avevo capito il problema sollevato da k.gothmog, ma un tipo di intercettazione del genere lo si può ottenere stramite degli sniffer, in modo tale da fare dei tcpdump e poi analizzare quello che è stato trasmesso nel pacchetto tcp... xò il fatto di corrompere l'hash richiederebbe l'intercettazione della stringa cosificata e l'utilizzo di un software tipo john the ripper e comunque la cosa sarebbe esclusivamente interessata se il nostro sistema subisse un attacco "man in the middle", no?

La cosa è molto interessante anche per un nubbio come me   :Wink: 

----------

## makoomba

 *DranXXX wrote:*   

> ma un tipo di intercettazione del genere lo si può ottenere stramite degli sniffer, in modo tale da fare dei tcpdump e poi analizzare quello che è stato trasmesso nel pacchetto tcp... xò il fatto di corrompere l'hash richiederebbe l'intercettazione della stringa cosificata e l'utilizzo di un software tipo john the ripper e comunque la cosa sarebbe esclusivamente interessata se il nostro sistema subisse un attacco "man in the middle", no?

 

l'utilizzo di meccanismi "challenge-response" su connessioni non criptate (tipo il cram-md5 utilizzato in pop3 e imap) rende l'intercettazione dell'hash inutile.

Ciò che viene trasmesso è il digest risultante dall'applicazione di una funzione hmac (md5,sha-1,etc) al challenge (che è random) utilizzando come chiave lo shared secret (la password)

poichè il digest varia ad ogni connessione, appare evidente come un'eventuale "compromissione" dello stesso sia del tutto irrilevante.

----------

## neryo

 *makoomba wrote:*   

> 
> 
> poichè il digest varia ad ogni connessione, appare evidente come un'eventuale "compromissione" dello stesso sia del tutto irrilevante.

 

confermo   :Wink: 

----------

## Luca89

Girovagando per la rete mi è capitata nel browser questa pagina. Forse si tratta proprio di ciò che richiedeva k.gothmog.

----------

