Newsgroup: it.comp.os.linux.sys
Titolo: fetchmail e password

Salve a tutti.
C'č un modo per non usare le password in chiaro nel file .fetchmailrc?
Se nella directory /home di ogni user metto .fetchmailrc, gli altri user
non lo leggono, ma root sě....
Possibile che fetchmail non preveda l'uso di password criptate?
Il 'man fetchmail' non mi ha aiutato molto, nemmeno google.
Mi sono rimbecillito io per caso?
Saluti e grazie.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Mi sono rimbecillito io per caso?
non ti sei rimbecillito.
in unix root=god
chiaramente l'alternativa potrebbe esistere e dovrebbe essere un hash
md5 al posto della password, ma non so se tale alternativa e` stata
contemplata.
-- 
Massimiliano

 contemplata.
Per quello che ho trovato in giro non mi sembra. Sarebbe bastato solo
quello! :(
Grazie e saluti.


 non lo prevedeva.
Perfetto, ma fetchmail prevede anche l'ssl, che in questo caso torna molto
utile, ma avere le pwd in chiaro in un file di testo è una
contraddizione...
Capisco che root possa avere l'accesso completo a tutto, ma non sono
d'accordo sulla possibilità di ottenere le password degli altri utenti...
Punti di vista diversi?
Grazie e saluti.


 quello! :(
sono d'accordo.
Fra l'altro oggi fetchmail supporta kerberos, ssl (dove la password non
e` piu` sniffabile) .... quindi sarebbe una buona idea usare un hash
-- 
Massimiliano

 Possibile che fetchmail non preveda l'uso di password criptate?
Ovvio.
Devi sapere che per autenticarti ad un server POP, spesso si usano HASH e
per generare un hash, devi sapere la password in chiaro.
Da qui la necessità di conoscere quel dato.
Oltretutto, nel caso tu volessi salvare la password con un algoritmo
reversibile, dovresti avere una chiave da depositare sul server che root
comunque sarebbe in grado di leggere e torni punto e a capo.
Se vuoi proteggere quella chiave con una password, da inserire almeno una
volta, allora fetchmail perde di utilità.
SaluMI,
 Max
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 md5 al posto della password
Ah, beh, continui a litigarci con md5 tu, eh?
Dimmi, cosa ci farebbe fetchmail con un *hash*, visto
che gli serve una password da spedire ad un server pop3?

* whiplash:

 vi /usr/share/doc/fetchyahoo-2.10.2/fetchyahoorc.gz
[cut]....
# this can be a password or an md5_hex hashed password
password = yahoo-password
[cut]....
chiaro no?...ok ... a me non e` del tutto chiaro, perche` mi faccio la
stessa domanda che ti stai facendo tu:
che fa, manda l'hash al sito web??
-> fetchyahoo lavora in perl e fa login sul sito web
COMUNQUE, il modo di usare l'hash c'e`, e l'ho detto proprio pensando a
fetchyahoo.
-- 
Massimiliano

 fetchyahoo.
Non č universale. E questo dovrebbe bastare.
fetchyahoo usa un singolo sistema e non deve smazzarsi tonnellate di server
pop/imap o tonnellate di tipi di autenticazioni.


 
/chiaro come il giorno
c'e` una cosa che stavo pensando (ho gia` risposto a wiplash).
vi /usr/share/doc/fetchyahoo-2.10.2/fetchyahoorc.gz
[cut]....
# this can be a password or an md5_hex hashed password
password = yahoo-password
[cut]....
cioe` puoi usare un hash... lui lo chiama 'md5hex', e lo generi sempre
usando fetchyahoo: fetchyahoo --md5hex
Mi sta sfuggendo qualcosa.... (fetchyahoo fa login sul sito web e non
capisco cosa fa con l'hash).
/chiaro come una notte di luna nuova
-- 
Massimiliano

 
Il punto non e` questo: fetchyahoo _non_ puo` mandare l'hash.
Non fa login su un pop, ma fa login sul sito web (tramite script in perl).
-- 
Massimiliano

 Non fa login su un pop, ma fa login sul sito web (tramite script in perl).
Riproviamo.
Il punto è:
per fare Login su pop/imap puoi usare diversi metodi.
Ti incollo un pezzo della conf di dovecot.
# Specifies how the client authenticates in the IMAP protocol.
# Space separated list of permitted authentication mechanisms:
#   anonymous plain digest-md5 cram-md5
#
# anonymous - No authentication required.
# plain - The password is sent as plain text. All IMAP/POP3 clients
#  support this, and the password can be encrypted by Dovecot to match
#  any of the encryption schemes used in password databases.
# digest-md5 and cram-md5 - both encrypt the password so it is more
#  secure in transit, but are not well supported by clients, and
#  require that the password database use a matching encryption
#  scheme (or be in plaintext).
OK?
se dovessi scrivere un programma tipo fetchmail, lo farei universale.
Universale => avere password in chiaro, anche per avere MENO problemi.
fetchmail NON è stato scritto con lo scopo di "imboscare" le password da
root che, per altro, potrebbe comunque sgamarle con un bello sniffing.
Se uno deve fare un programma lo fa flessibile.
Se deve curare la "sicurezza" lo fa a ragion veduta e con un pò di sale in
zucca.
Sniffando può root può comunque fare login o sgamando quello che passa
(passqord o hash compresi).
Se proprio vogliamo esagerare, root si copia fetchmailrc da un'altra parte
e si succhia le email senza cancellarle, sia con la pass in chiaro che con
la pass oscurata.
Insomma: secondo me c'è poco da farsi le seghe mentali sugli hash o sulle
password e sul metodo di conservazione. Non ha senso ne pratico ne tecnico.


 Non fa login su un pop, ma fa login sul sito web (tramite script in perl).
Non ho la più pallida idea di cosa faccia fetchyahoo, quindi mi limito
al protocollo pop3.
Non puoi partire da un hash MD5, ti serve comunque la password.
Su questo non si transige. Per la stessa ragione, non puoi utilizzare
meccanismi CRAM su sistemi che mantengano le password sottoforma di hash
MD5.
Peraltro, se anche per assurdo l'MD5 *da solo* fosse sufficiente per
tramite di qualche magia a garantire l'autenticazione, non avresti
risolto assolutamente nulla, ad inserire nel file l'hash invece della
password: in entrambi i casi, sarebbe tutto quanto necessario ad
accedere al servizio.
Ergo, il problema non si sposterebbe di una virgola.


non e` questione di sale in zucca ne' di sicurezza, ma di *riservatezza
di dati personali*.
-- 
Massimiliano

 Non puoi partire da un hash MD5, ti serve comunque la password.
Lo so questo e so che anche tu lo sai. Non discutiamo di queste cose.
Mi spieghi adesso come fa lo script in perl a usare l'hash?
Dici che si tratterebbe di una protezione debole e reversibile, tanto per
dirsi che c'e` qualcosa?
Sta di fatto che lo chiama md5 e che per generarlo usi:
fetchyahoo --md5hex
p.s.: ho provato se per assurdo il sito di yahoo accetta l'ash per fare
login. Opzione inverosimile, ma tecnicamente possibile... difatti non ha
funzionato.
-- 
Massimiliano

 a leggere le password degli altri.
Riproviamo.
O siamo su .sys e parliamo di roba tecnica o siamo da altre parti e
parliamo di quello che vogliamo.
Sulla privacy non ci piove, concordo, ma in questo NG è OT e imho è OT
anche in questo thread.
Se poi vuoi capire perchè fetchmail non prevede quello che auspichi, allora
rileggiti i post che te lo hanno spiegato.
Il resto non solo è OT ma mi pare tanto un modo per spostare il discorso su
altri campi dove *forse* puoi var valere altre ragioni.


 funzionato.
Ora, se vuoi fare altri test, sei libero di farlo.
Però magari prova a spiegare come lo hai fatto !
Io non ho provato ma ti assicuro che col javascript trasformare una
password in un hash md5 e fare il post è una cazzata.
Se tu come password hai inserito l'hash, allora hai spedito l'hash
dell'hash.
I test li devi fare provando con telnet a fare il post dei dati, simulando
di essere un client.


 problema dello sniffing si pone solo parzialmente.
Ti voglio vedere a trovare un qualsiasi ISP che autentichi pop con
kerberos... O__o
Per quanto riguarda SSL, ok. Ciò non toglie che, se vuole, root fa anche
quello, "semplicemente" sovvertendo le librerie SSL del sistema.
Come se non bastasse, una volta downloadate le mail stan pur sempre su
un hard disk, e -indovina- root guarda quel che vuole e modifica quel
che vuole, quindi anche qui si apre una lunga parentesi... :-\
La verità è che puoi fare quel che vuoi, ma il superuser continua a
poter fare tutto, compresa la sovversione della tua privacy.
Quand'anche "crittassi" le password nei file di config, come detto
sopra, non servirebbe a nulla: se il sistema può da quelle info
funzionare, anche root può farlo.
A meno di non utilizzare sistemi MAC (non Apple...) e restringere le
possibilità dello stesso root, ma poi chi è che amministra il MAC?
Torniamo lì, no?

 altri campi dove *forse* puoi var valere altre ragioni.
-- 
Massimiliano

 che vuole, quindi anche qui si apre una lunga parentesi... :-\
questo lo ha detto anche l'autore del post.
Ma io credo che la password in chiaro sia una cosa un po` piu` cruciale.
porca miseria, ti dico una cazzata .... io sul lucchetto del mio notebook
ho una combinazione che corrisponde al codice del mio bancomat.
Francamente se "root" dovesse leggere la combinazione del mio lucchetto mi
romperebbe veramente er cazzo :)
Questo e` piu` o meno il concetto.
-- 
Massimiliano

 romperebbe veramente er cazzo :)
Vediamo.
Parliamo della posta di yahoo.
Se fetchyahoo manda un'hash della password, secondo te, dall'altra parte,
yahoo ha memorizzato la tua password in chiaro o hashata ?


 yahoo ha memorizzato la tua password in chiaro o hashata ?
chiaro che sei io mando un hash, dall'altra parte deve esserci un hash.
Dovrei guardare quello script per benino, ma poniamo il caso che yahoo
offra la doppia possibilita`:
1) mandare l'hash.
2) mandare la password e far generare l'hash al server yahoo.
installati fetchyahoo, ci vuole un attimo :)
-- 
Massimiliano

 funzionato.
bhe, ovvio, la form vuole la password in chiaro non l'hash

 Punti di vista diversi?
Il problema sta nel protocollo POP3 e simili.
Fetchmail e' un client POP3: si
Il protocollo POP3 prevede l'invio della password in chiaro: si
Vuoi che Fetchmail faccia il suo sporco lavoro senza alcuna interazione da
parte dell'utente: si
L'and di queste 3 richieste produce come risultato -> password in chiaro
sul fs
password in chiaro sul fs produce come effetto secondario -> root puo'
leggerle
bye

 
? Cos'e` questo ? A me non torna.
Ragioniamo in un altro modo, allontanandoci un pochettino da quella
discussione:
-> io non ho mai guardato il codice di server pop3, esistono inoltre
degli standard per i pop3 come per tutto il resto.
-> la password del pop3 alla fine e` la password di sistema: ergo (visto
che l'hash non e` reversibile) il pop3 dovra` generare l'hash per
confrontarlo con l'hash in /etc/shadow: ergo pop3 deve essere in grado
di generare un hash (tramite librerie e sarca$$o).
PERTANTO, almeno teoricamente, riscrivendo il pop3 (o vedendo se esiste
un pop3 che fa questo), invece di inviare la password in chiaro, si
potrebbe mandare una stringa del tipo hash:blablabla
A quel punto il pop3 sa che non dovrebbe piu` fare la conversione e
dovrebbe solo confrontare gli hash.
Facile no? Talmente facile che mi pare assurdo che non sia mai stato
implementato...................guarda, giusto per curiosita` vado su
gUgol a cercare.
Tradotto in pratica sarebbe una cosa del tipo:
telnet host 110
user blabla
pass hash:blabla
list
quit
-- 
Massimiliano

 discussione:
evito il cancel del messaggio, ma tutta questa cosa non servirebbe
assolutamente a niente, in quanto l'hash sara` sempre uguale e puo`
essere sniffato e, anche se irreversibile, potra` essere utilizzato per
eseguire il login :) :)
ciao ciao.... :)
-- 
Massimiliano


Un meccanismo supportato da POP e IMAP per trasmettere le password
sottoforma di hash, senza che questo sia riutilizzabile, c'è: CRAM-MD5
Che però *richiede* che sia il client che il server abbiano accesso alla
password in chiaro.

 sottoforma di hash, senza che questo sia riutilizzabile, c'è: CRAM-MD5
... si in questo caso utilizzano un challenge, che cambia sempre.
-- 
Massimiliano

 eseguire il login :) :)
esatto! :-)
in piu', sempre restando in ambito unix, le password di sistema sono
combinate con un salt. salt che non e', di solito, a conoscenza del client
pop3.

* david mugnai:

mmmhh ... si/no ....
con un po' di immaginazione:
1. tu scrivi la password.
2. il sistema ti passa il salt e ti consente di calcolare l'hash in base
a quel salt.
3. i risultati vengono confrontati.
Cioe`.. se il salt puo` usarlo login, (ammesso che sia utile) potrebbe
usarlo anche pop....
-- 
Massimiliano

 usarlo anche pop....
Il salt non lo usa login, lo usa PAM, almeno nei sistemi che usano PAM.
Ergo, se pop autentica su PAM, lo usa anche pop.
E' esattamente quello che accade su un qualsiasi sistema che autentichi
via pop utenze di sistema...
Ciò non toglie che sia cosa interna al lato server: il lato client deve
pur sempre mandare la password in chiaro...
Si potrà dire: vabbè, allora pop manda il salt al client, che lo usa per
hashare la password e poi manda l'hash.
Poichè il salt però è sempre quello (è memorizzato in /etc/shadow sul
server, e non cambia se non cambia la password), anche l'hash sarà
sempre quello, e torniamo al fatto che basta sniffarlo per poter accedere.
Allora facciamo in modo che il salt non sia costante:
- il server invia un salt casuale al client
- il server hasha la password con il salt mandato al client
- il client piglia il salt e la password e li hasha insieme
- il client invia l'hash al server
- il server confronta i due hash e se sono uguali permette autenticazione
'sta cosa però funziona solo se sia il server che il client conoscono la
password in chiaro, poichè entrambi devono essere in grado di ottenere
da essa un hash diverso di volta in volta.
Abbiamo appena inventato (più o meno) CRAM.
Però consiglierei di riprendere un minimo di basi di crittografia: se
c'è una cosa che questo thread dimostra, è il fatto che incarognirsi a
voler inventare la ruota non è una grande idea, poichè un sacco di gente
ci è già passata prima e può testimoniare che esagonale non funziona bene...

 dovrebbe solo confrontare gli hash.
Geniale.
Spiegami quale sarebbe la differenza rispetto ad una dannata password in
chiaro, te ne prego.

 
beh si.
-- 
Massimiliano


scusa ah... ma il tuo newsreader scarica i thread a meta', oppure vuoi
far credere ai posteri un po` sbadati che io mi ero auto-riposto dopo
aver letto il tuo post, oppure vuoi far credere ai posteri piu` sbadati
che tu hai scritto questo messaggio senza aver letto la risposta che io
ho dato a me stesso ;)
Guarda che la differenza di tempo fra il mio primo messaggio e la
risposta che mi sono dato e` di solo 8 minuti.... considera anche il
tempo di scriverla e capirai che mi sono autorisposto in un attimo.
Insomma, tu arrivi 24 ore dopo a ripetere la cosa che ho gia` detto io.
-- 
Massimiliano

 C'è un modo per non usare le password in chiaro nel file .fetchmailrc?
Credo non si possa, al momento.
Ma una semplice soluzione potrebbe essere quella di ricompilare fetchmail
modificandogli la gestione del campo 'password', in modo da poterla 
inserire anche in formato SSHA, come fa ldap.

 Possibile che fetchmail non preveda l'uso di password criptate?
A parte che non sarebbe fattibile, sarebbe anche abbastanza irrilevante:
root non avrebbe certo bisogno di leggere la password in .[TuoMUA]rc per 
poter leggere, se lo volesse, la posta scaricata dagli utenti.
Fabio

 poter leggere, se lo volesse, la posta scaricata dagli utenti.
eh, ma allora vivi....

 Punti di vista diversi?
Se ti piace soffrire, puoi studiarti SELinux per impedire a root di leggere
alcuni file degli utenti.
-- 
Per rispondermi, togli il nome del poeta


Come no... alive and clickin' :-)