On 16/06/2010 15:17, alexagosto62 wrote: > Il 14/06/2010 17.00, Alessio Cecchi ha scritto: >> >>>> Noi quando installiamo un mail server per questo genere di contesti >>>> facciamo presente al cliente che è possibile mantenere in chiaro una >>>> copia della password, se lui lo ritiene opportuno ci specifica che vuole >>>> avere anche le password in chiaro. >>> >>> Male. State rendendo un sistema vulnerabile e sicuramente siete al di fuori >>> di ogni criterio di gestione della sicurezza. C'� *SOLO* un caso in cui ciò >>> sia utile, ed nel caso in cui si stia facendo il debugging >>> dell'applicazione, in fase di sviluppo. Mai in produzione. > > Vero !! In assenza di sistemi pi� efficaci della password � bene che gli > utenti siano responsabilizzati sulla gestione delle stesse. > Soprattutto, al di la della complessita' dekka password occorre che, per > policy, questa venga cambiata con una certa periodicita' (che so, 60 > giorni ad esempio). Le tecniche per costruire delle password complesse > ci sono. Su questo credo manchi formazione.
Tra l'altro il garante, se la memoria non mi inganna, stabilisce che l'unica persona a dover conoscere la propria password e` l'utente stesso. Correggetemi se sbaglio. >> >> E' la stessa coda che noi diciamo al cliente per disincentivare questa >> pratica. Molti chiedono questa possibilit� , molto rinunciano, qualcuno la >> vuole ugualmente. >> >>>> Poi a livello di sistema questa >>>> password in chiaro non è mai utilizzati dai software che fanno sempre >>>> riferimento ad un hash per il confronto delle password fornite >>>> dall'utente, si tratta solo di un campo extra nel DB. >>> >>> Un bellissimo campo extra che in caso di bug di sicurezza, p.es. una bella >>> sql injection, svela all'attaccante TUTTE le password in chiaro e oltre a >>> questo probabilmente anche i criteri di scelta delle password dei vari >>> utenti. >> >> Giusto, si potrebbe mettere in un DB separato con privilegi diversi, grazie >> per il suggerimento. >> >>>> Ritengo opportuno che a livello di contratto ed utilizzo dei nostri dati >>>> sarebbe opportuno che l'ISP specificasse se archivia o meno le nostre >>>> password in chiaro. >>> >>> Non deve farlo e punto. >> >> Mi ma di fatto accade. > > Quello che mi preoccupa e' che stiamo parlando di PEC ... Se e' vero che > le cose dette prima potrebbero essere "accettate" storcendo un po' il > naso su una mailbox di hotmail, di libero o che altro, questo non e' > vero per la PEC. Ci stanno obbligando praticamente a possederne almeno > una per ciascuno. Dico "almeno" perch� oltre a quella di Poste, di ACI e > di INPS ci potrebbe essere l'ordine degli ingegneri che ti obbliga ad > avere la sua PEC, poi l'associazione x che ti fornisce la sua, etc etc. > Alla fine, oltre ad avere un certo numero di caselle "normali" rischiamo > di avere pi� caselle di PEC. E questo, a mio modestissimo parere, e` la cazzate principale della PEC rispetto all'adozione, come ho detto piu` volte, di altri standard e soluzioni. > > Comunque io per mitigare il problema dell'autenticit� del mittente > propongo di fare piu' uso dei certificati digitali. Infatti essi possono > essere "tranquillamente" abbinati alla PEC, a patto che si disponga di > un client evoluto (thunderbird, outlook, etc etc) e non di una Webmail. Anche in questo caso puoi "banalmente" utilizzare il certificato come metodo di autenticazione alla webmail. > In questo modo, al di la' della password della casella, se voglio > "certificare" meglio l'autenticit� del mio messaggio, lo firmo > digitalmente (e me ne fotto del certificato della PEC, che garantisce > solo l'autenticit� dei peer). Verissimo. > > Alessandro Feltrin > > > > ________________________________________________________ > http://www.sikurezza.org - Italian Security Mailing List
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
