Scusami evidentemente mi sfugge il punto ma.... Il 30 maggio 2010 19.43, Alessandro Romani <[email protected]> ha scritto: > Marco, > hanno chiarificato ampiamente Stefano e Marcello ciò che io ritengo un bug > in senso allargato o, per essere più precisi, una pessima scelta > implementativa. > Dal mio punto di vista "paranoico" avrei preferito una scelta molto più > restrittiva: > > 1) Form inviato in POST (come, d'altronde, si insegna sulla guida base di > HTML).
E questo mi sembra più che sensato. > 2) Hash della password sempre e comunque, a prescindere dalla presenza di un > certificato SSL. Scusa ma l'hash dove lo calcoli? Puoi fare un Javascript che si calcola l'hash dei campi prima di inviare la GET/POST con l'hash appunto. A quel punto fai un match dell'hash che ti è arrivato dal client e l'hash memorizzato....Ma a questo punto la tua credenziale diventa l'hash e non più la password. E allora basta sniffare l'hash! Del resto se qualcuno può sniffare sulla tua macchina il traffico vuol dire che con buona probabilità è un amministratore e allora sei già nelle mani del nemico ;-) > > Questo per il semplice motivo che preferisco avere più livelli di protezione > piuttosto che un unico point of failure. D'altra parte sono già noti, in the > wild, attacchi man in the middle in cui colui che sta nel mezzo può > dichiarsi Vodafone.it, sniffare il contenuto e reinoltrare la richiesta al > sito leggittimo comportandosi, di fatto, da proxy. Esistono gli Extended Certificate che sono ben visibili dagli utenti. Se poi l'utente è talmente tonto da cascare in siti di phishing oppure la rete è talmente bucata che piazzano sniffer ovunque o peggio fare MTM, non è che lo puoi imputare al GET/POST :-) Ma mi viene il dubbio che forse mi sono perso qualche cosa.... ________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
