Re: [ml] Homebanking password security

On Mon, Oct 29, 2007 at 04:44:40PM +0000, A. R. wrote:
> Se decidi di accettare caratteri non alfanumerici nelle password (es.:
> il singolo apice) hai sicuramente aumentato la sicurezza a fronte di un
> bruteforce, ma preparati a dover controllare tutti i posti in cui quel
> dato viene utilizzato, per essere sicuro che quei caratteri, in tutte le
> loro potenziali codifiche, non possano interferire in maniera imprevista
> con la logica dell'applicazione (nel nostro esempio, prestarsi ad
> attacchi di SQL Injection).
...
> Quando hai un'applicazione molto complessa (come una di home banking)
> individuare tutti i possibili side-effect dell'accettare un dato
> potenzialmente pericoloso non e' un problema di facile soluzione. E'
> molto piu' semplice (e aggiungo efficace) sanitizzare il dato il piu'
> possibile appena questo viene ricevuto.

Se l'applicazione usa la password in piu' di una manciata di posti,
allora direi che l'applicazione e' un disastro in attesa di accadere.
Le best practice, nonche' la logica, suggeriscono di controllare la
password una volta, poi usare la miriade di metodi esistenti per
mantenere una sessione permanente (e verificare che sia ancora
valida), e poi *accuratamente azzerare la memoria* che conteneva la
password.

Forse ricordi un articolo di Bruce Schneier in cui riferiva di una
societa' che ha un tool in grado di fare brute force di password ad
una velocita' davvero sorprendente. Uno degli strumenti che usa e'
molto semplice: prova tutte le stringhe che trova su disco.
Se l'applicazione mantiene la password in memoria, questa finira' su
swap; se lo swap non e' cifrato, e' li' bello a disposizione; e se non
e' in una partizione separata, prima o poi i suoi blocchi verranno
rilasciati e usati da file, e la tua password sara' disponibili dopo i
dati "utili" di quel file...

Questo  e' solo un esempio divertente anche se non direttamente
applicabile (se qualcuno puo' leggere l'hard disk della macchina dove
gira un home banking, la banca ha ben altri problemi :-) ) ma rende
l'idea: la sicurezza non si inventa, e un software insicuro non puo'
essere patchato, va riprogettato, non c'e' scampo.

Ciao,
	Andrea

-- 
If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.