Newsgroup: it.comp.sicurezza.varie
Titolo: Riflessione su cambio password

Ho notato che diversi siti permettono registrazioni di questo tipo:
Nome utente: il proprio indirizzo email
Password: inizialmente generata dal sistema, dopodiche' l'utente se la puo'
cambiare.
Ora, diamo per scontato che il sistema sia costruito in modo tale da non
generare mai due password identiche, quindi magari le genera del tipo
xyzw1234 (tanto per rispettare il minimo di otto caratteri).
Ma quando l'utente se la cambia, e' assai probabile che inserisca una
password tipo data di nascita, nome del cane, targa della macchina, etc etc.
Quindi, la possibilita' di "indovinare" la password e' maggiore rispetto al
fatto di non lasciarla cambiare (o di farla cambiare dal sistema
periodicamente, ma qui poi si apre il discorso sul come comunicarla in modo
il meno insicuro possibile all' utente).
Tenuto conto che, utilizzando l'email come username, un buon 50%
dell'accesso e' gia' bell'e pronto...

 fatto di non lasciarla cambiare 
Bah, questo lo dici tu. La possibilità di indovinare la password 
dipenderà da quanto facile se la mette l'utente, non dal fatto che c'è 
la possibilità che si metta una password del cavolo.
Tanto per essere chiari: se io mi registro in quel sito, il fatto che la 
maggior parte delle persone usi come password la data di nascita o il 
nome del cane non è che influisca granchè sulla sicurezza del mio account.
D'altro canto la possibilità per l'utente di cambiarsi la password è 
l'unico modo per avere una certa garanzia di essere l'unico a 
conoscerla. Nell'altro caso c'è almeno il generatore che *di sicuro* la 
conosce.

 conosce.
Non e' *di sicuro*.
Esistono sistemi per generare password, con anche alcune regolette
fonetiche per la mnemonicita' della sequenza generata, che non sono
ripetibili, non emettono nulla di visibile, e possono stampare la
password all'interno di un plico sigillato non leggibile in trasparenza.
In quel caso, nemmeno il generatore e' a conoscenza della password.
L'unica cosa che resta nel sistema e' l'hash della password stessa.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 password all'interno di un plico sigillato non leggibile in trasparenza.
Non mi pareva il caso descritto :-)

 Non mi pareva il caso descritto :-)
Perche' no?
A parte sniffer e man in the middle, la password generata da un sistema
remoto e presentata a video e' proprio quella che da piu' garanzie.
E anche qui, i nostri legislatori hanno toppato alla grande,
obbligandoci a far cambiare la password periodicamente all'utente,
trovandosi poi con l'utente rossi con password mario (se la rifiuta
perche' corta, mariomario o mario1234 e' il massimo a cui  si puo'
aspirare), al posto di prevedere generatori di password pseudo random,
di cui nessuno, nemmeno il sysadmin, puo' predire il risultato.


 Perche' no?
Perchč parlava di registrazioni in diversi siti. Non della privacy, per 
intendersi.

 intendersi.
Stavolta non ti seguo.
Faccio riassunto, da come l'ho capito io.
La registrazione sui vari siti ti propone una password generata.
Poi la puoi/devi cambiare.
L'amico diceva che la password che ci si trova, poi, inserita
dall'utente, e' di solito "facile".
Tu (tu?) hai detto che le tuepassword non sono per nulla facili, e che
lasciando all'utente la possibilita' di cambiarla, era l'unico metodo
con cui la password l'avesse saputa solo l'utente, perche' quelle
generate erano a conoscenza anche del generatore.
Io ho detto che non sempre le password generate sono a conoscenza di
qualcuno diverso dall'utente a cui sono destinate, potendo essere
costruite dal computer, e non memorizzate da nessun parte.
Mi ci sono agganciato per polemizzare un filino verso la legge sulla
privacy, che invece *impone* il cambio a cura dell'utente.
Ma la privacy era solo un aggancio, il concetto era sempre quello:
io, te, e mille altri possiamo avere una password robustissima, ma
a me sembra che le probabilita' di trovare la password pippo1234
in questo caso sono ben piu' alte che assegnando una password tosta
direttamente dal sito.
Ho capito male qualcosa io, hai capito male qualcosa tu, oppure
stiamo "litigando" sostenendo esattamente la stessa tesi? :-)



era proprio questo, ad avermi suggerito la (banale, peraltro) riflessione:
che se mario@dominio (indirizzo di posta coincidente con username) si cambia
la password in pippo2005 , magari ci possa anche essere giovanni@dominio che
decide pure lui di cambiarsi la password in pippo2005.
Questo puo' accadere per i soliti motivi triti e ritriti, al che mi stavo
chiedendo se, forse, non sia il caso, qualora username & password forniscano
l'accesso a dati magari un po' piu' importanti dell'account hotmail o yahoo,
di adottare un sistema di password generata di volta in volta in modo
automatico ed univoco e magari comunicata all'utente attraverso una
connessione SSL, ad esempio.

 che *di sicuro* la conosce.
questo non è necessariamente vero, anzi. Prendi il caso di un sistema 
automatico che genera un numero random (puoi farlo con semplici 
funzioni PHP) e un sistema che verifica tale numero sempre in 
automatico. tieni prensente che poi per un sys-admin lasciare un 
sistema non automatico è solo una perdita di tempo .. 
-- 
Ciao, Dmitry

 sysadmin, puo' predire il risultato. 
srand((double)microtime()*1000000);
$activecode = intval(rand()/getrandmax()*10000000);
sfido qualunque sysadmin ad indovinarla :)
-- 
Ciao, Dmitry

 dell'accesso e' gia' bell'e pronto...
i sistemi di crack delle pass e di forzatura prevedono di solito un 
dizionario noto o un algoritmo sul quale vengono generate le pass e/o 
le coppie user e pass in riferimento ad almeno un elemento noto.
ora ... tutto si può fare ma rimane il fatto che un buon sistema, ad 
esempio un buon mail server, dovrebbe prevedere il blocco di 
connessione per un utente che tenta X tentativi falliti in Y tempo.
e' qualcosa di semplicissimo da implementare ma di efficace e credo 
misura minima di prevenzione. Nulla toglie che ovviamente l'uso di 
password "forti" è di per se già una buona protezione.
-- 
Ciao, Dmitry

 sistema non automatico è solo una perdita di tempo .. 
Non ho detto questo.
Parlavo, *dal punto di vista dell'utente*, della sicurezza di avere una 
password complessa generata dal sistema e una autoassegnata.
Poi se volete mi metto anch'io a inventare un sistema che genera una 
password, la imprime su un ologramma coperto da uno strato di argento 
tipo gratta-e-vinci, la chiude in una busta sigillata in ceralacca e la 
consegna all'utente con un blindato sotto scorta armata.

 connessione per un utente che tenta X tentativi falliti in Y tempo.
Normalmente, i server di posta rispondono con alcuni secondi di ritardo 
alla password errata, cosicchè un eventuale attacco di forza bruta può 
fare solo pochi tentativi al minuto.

 scorta armata. 
esagerato! :)
-- 
Ciao, Dmitry


beh, no
il tempo di risposta del server e' una cosa che posso usare a mio 
vantaggio...
1) se vedo che ci mette tanto il server ad autenticarmi tronco li' la 
connessione io...
e questo lo vedo facendo stima del tempo medio di arrivo dei pacchetti
se dopo che invio la password passano (roudtriptime_medio*2) secondi 
tronco ... ed e' una stima ottimistica...
2) apro X connessioni al server...
-- 
Alessandro Sappia

 2) apro X connessioni al server...
E anche questo è usarlo a tuo vantaggio?

 
l'idea e' che un server ha "localmente" nel tempo... lo stesso tempo di
risposta..
se il codice e'
char *errore="-ERR authorization failed";
if (password_inserita!=password_giusta) {
	sleep (3);
	send(sock, errore, strlen(errore), 0);
} else {
// bla
}
so di per certo
che il server non mandera' pacchetti per 3 secondi se la password e' 
sbagliata
se il tempo medio di un pacchetto
misurato
mentre invio (syn) e ricevo (synack)
mentre invio (ack) e ricevo "+OK <21271.11...@domain.tld>"
mentre invio "user pippo" e ricezione di "+OK"
(tre prove)
e' non paragonabile alla sleep
posso ragionevolmente pensare che
quando invio
"pass falsa" e aspetto il doppio del tempo (e' un tempo ipotetico, 
potrebbe essere tempo_medio*1.2 o qualunque cosa) allora la pass
e' sbagliata...
difficilmente se ho gia' scambiato pacchetti (anche se pochi)
il server in quei 2 secondi diventa molto piu' busy
ovvio che posso fare questo discorso se il nodi intermedi non sono 
"intasati"
questo
combinato a X connessioni puo' facilitare la cosa..
se si trova il giusto equilibrio...:-)
Dimmi se faccio errori veramente grossolani, ma in linea di massima 
riprendo il concetto di un attacco time based ipotizzato contro openssh
che faceva aspettare tempi diversi (a parita' di password sbagliata)
se l'utente era esistente in /etc/passwd oppure no.
una soluzione e'
mettere una sleep comunque anche in caso di autenticazione positiva...
o randomizzare la sleep in base al round trip time della connessione...
tra le due ha senso la prima...
ciao
Alessandro Sappia