Andrea Campi wrote: > 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). ... > 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.
Quello che dici è vero, ma mi sembra il modo sbagliato di affrontare il problema. Prima di tutto la questione della sicurezza della password. Posto che siamo tutti d'accordo che serve un tool di gestione delle password, puoi ottenere la stessa sicurezza aumentando il numero di caratteri o allungando la lunghezza minima della password: eliminare una decina di caratteri dal set di quelli normalmente usati dagli utenti ti cambia quindi realmente poco: passi la lunghezza a dieci caratteri e sei a posto. Peraltro, le regole indicate nel post iniziale non riguardano solo i problemi di validazione dell'input, è evidente se si considerano regole come "non deve avere più di 2 caratteri consecutivi in sequenza crescente/decrescente (ad es.: abc, 987, …)" È corretto che la password dovrebbe essere utilizzata in un solo punto. È corretto che l'input deve essere validato. Sono corrette un sacco di cose, ma non sono "alternative". Ridondanza e difesa in profondità. Tutti fanno errori, anche gli analisti e i programmatori migliori. Trovo molto sano che un project manager non basi la propria progettazione sull'ipotesi di avere a disposizione le migliori menti possibili, e che non abbia la presunzione (questo è) di non fare errori. Quindi, mette più linee di difesa: valida l'input, ma nello stesso tempo evita i caratteri che potrebbero dare più problemi. Anche perché non è detto che abbia il controllo dell'intero progetto, e soprattutto non è detto che i problemi non saltino fuori da componenti acquisiti, come il server http o un linguaggio di scripting. In generale, quando si dice "quella misura di sicurezza non serve, basta quest'altra" IMHO è sempre bene ripensare due volte a quello che si è appena detto. Poi, se c'è un motivo valido (es. la prima misura di sicurezza ha dei grossi difetti, magari di costo) allora se ne può parlare. ciao - Claudio -- Claudio Telmon [EMAIL PROTECTED] http://www.telmon.org
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
