miklos ha scritto:colgo inoltre l'occasione, perchè magari si puo' intavolare un discorso a piu' menti, su come ultimamente sviluppo i login per le mie applicazioni web.
fermo restando che niente è sicuro quanto un canale cifrato uno dei problemi piu' rilevanti del login in una applicazione web è lo scambio di username e password tra il browser e il server che se il canale non è sicuro avviene in chiaro.
percio' uso questo sistema che per ora nn da' evidenti problemi dal punto di vista funzionale (o almeno io nn li ho trovati).
praticamente in fase di registrazione al posto del campo password nel database creo un token di sicurezza che è composto dal risultato di una funzione di hashing/cifratura simmetrica della concatenazione di username+password.
in fase di login poi, nel caso di browser con javascript abilitato ,al posto di mandare separatamente username e password in chiaro, viene creato un token con lo stesso metodo usato in fase di registrazione (e sempre concatenando username + password) che viene poi usato in fase di query (select count(1) from utenti where token = 'input_del_browser')
in caso di browser senza javascript si attiva la modalità 'legacy' che manda le due informazioni in chiaro + l'informazione che la modalità è classica, ed è poi il server che in questo caso crea il token e fa la query sul db
in questo modo anche nel caso in cui per necessita/pigrizia/costi nn si possono usare certificati ssl per proteggere il canale comunque si alza di un po' la sicurezza.
che ne pensate!?
che non è sicuro per niente, per esserlo, la stringa di cui fai l'hash deve contenere una sottostringa che cambia ogni volta (UUID ad esempio), che è poi la stessa cosa che fa APOP (
http://tools.ietf.org/html/rfc1460).
Perchè l'hash deve contenere una stringa che cambia ogni volta? perchè se tu crei l'hash semplicemente applicando la funzione di hashing ad una stringa che contenga solo username e password, un eventuale attaccante che sta in mezzo e riesce a leggere l'hash in questione, lo può riutilizzare per loggarsi con l'utente in questione, mentre se la stringa da cui generi l'hash contiene una sottostringa che cambia sempre, anche se l'attaccante riesce a leggere l'hash comunque non lo può riutilizzare; quindi l'algoritmo è il seguente:
1) il client si connette al server chiedendo di iniziare una sessione di autenticazione per un dato utente
2) il server risponde con un token univoco (UUID o altro)
3) il client crea un hash con username+password+token_univoco
4) il server fa una query sul db cercando l'utente che il client ha comunicato al punto 1), si piglia anche la password, crea un hash con username+password+token_univoco (lo stesso token univoco che ha comunicato al client al punto 2) ), infine controlla i due hash, se uguali autentica l'utente, altrimenti lo sfancula
ovviamente si fa prima ad usare https, visto che oggi ci sono anche enti che rilasciano certificati gratuitamente (vedi il certificato che usa slacky)