Il giorno 09/giu/2010, alle ore 12.08, Stefano Zanero ha scritto: > > Ma se io ho accesso al server SU CUI ti stai autenticando (e da cui, fin > troppo spesso, hai accesso al DB degli utenti in chiaro...), il modello > di minaccia e' un altro. si ,vero ma pensavo anche al seguente fatto: L'accesso al db delle utenze sarà rigorosamente controllato, ma l'accesso al db delle statistiche o altro che memorizza le url magari non è così controllato come il db delle utente, proprio perchè _si crede_ che dopotutto sono _solo_ URL.
> Siccome "spoofing" significa il simmetrico di "sniffing", non e' slang: > e' sbagliato. Sad but True. Ho detto una vaccata. > >> cmq mi aspettavo una riposta nel merito e non sulla terminologia. > > Ti ho risposto nel merito in un altro messaggio. Se la comunicazione non > e' protetta da SSL, il tuo metodo non serve a nulla (giacche' tutto cio' > che accade lato javascript puo' a sua volta essere fatto saltare). Se la > comunicazione e' protetta da SSL, il tuo metodo non serve a nulla, a > meno che l'aggressore a) controlli il server (e allora non serve a nulla > per altre ragioni), oppure b) controlli il client (e allora non serve a > nulla per altre ragioni). Si verissimo. Ma io proponevo solo il meccanismo HMAC in seguito alla proposta di passare un HASH normale al posto della pw in chiaro. Ovvio che se mettiamo in post il tutto siamo tutti felici, come tutti stiamo dicendo (e come hanno fatto). > >> GET a POST è indice che qualcosa dopotutto è servito. Poi magari >> cambieranno anche la pw in chiaro. > > Che non e' in chiaro da nessuna parte (specie avendo cambiato da GET a > POST), ma vabbe', inutile ripetersi ulteriormente. vero. NM
smime.p7s
Description: S/MIME cryptographic signature
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
