Gli "Ospiti" della Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register
Nota: i miei commenti (quando ci sono) sono in italico

Privacy e Sicurezza 2.0

Una piattaforma web che sto sviluppando prevede il login inserendo nome utente e password. Niente di particolarmente nuovo od entusiasmante. Non ci sono stati requisiti particolari riguardanti la sicurezza, anzi era stata richiesta la possibilita' per gli utonti di recuperare la password senza doverla cambiare. Per cui le password sono memorizzate in chiaro nel database.

Ora, SL e DB si sono posti il problema della privacy e della sicurezza della password.

IO: "Scusate, ma cosa si intende per privacy della password?"
SL: "Se uno come password sceglie 'sonounpedofilo' oppure 'sonofrocio' nessuno deve saperlo, e' un fatto di privacy!"

Giuro, mi ha detto cosi'. Devo aver fatto una faccia di quelle indescrivibili.

IO: "E quale livello di sicurezza si vorrebbe avere?"
SL: "La password non deve girare in chiaro su internet."
IO: "Bene, dobbiamo fare il login https. Le password sul database non vengono memorizzate in chiaro, ma ne viene memorizzato solo l'md5. Un po' come fanno tutti i sistemi seri, anche diversi meno seri".

Dopo diverse riunioni di altissimo livello tra SL e DB, e' emerso che il login https non si puo' fare perche' nessun cliente che acquista la piattaforma ha voglia di comprarsi i certificati SSL.

Quindi se ne esce SL con una idea FOLGORANTE!

"Ma scusa, se trasmettiamo la password gia' in md5 risolviamo il problema, cosi' la password non e' in chiaro e nessuno la puo' sapere!"

La mia osservazione "Si ma scusate, cosa cambia fare il login con una password in chiaro o col suo md5 se comunque la connessione e' in chiaro e si vede passare allo stesso modo la password in chiaro o il suo md5?" e' caduta nel vuoto.

Per cui mi trovo a dover utilizzare una libreria javaschif che calcola l'md5 della password che l'ignaro utonto digita, e poi invia quello al posto della password in chiaro.

Approvata con entusiasmo questa soluzione, si procede con questo favoloso enhancement che aderisce in toto alle direttive della Privacy e Sicurezza 2.0. Se non altro, l'utonto che ha come password "sonofrocio" adesso puo' dormire sonni tranquilli: nessuno potra' mai scoprire il suo orientamento sessuale. Invece la Polizia Postale sara' molto in difficolta', non potendo piu' intercettare l'utente che ha messo come password "sonounpedofilo", di conseguenza lasciando impunito un pericoloso criminale informatico.

D'altra parte stiamo parlando della stessa ditta che anni fa ha venduto un servizio a tantissimi dei big provider italiani, che tra le altre cose prevedeva il trasferimento via ftp di un file facendo login sul swerver ftp IN CHIARO. Pero' il programmatore, esperto di sistemi di sicurezza, aveva criptato username e password nell'eseguibile, cosi' NESSUNO avrebbe potuto scoprirli! La parte forse piu' triste della storia riguarda il compenso smodato di questo genio (perche' alla fine si parla di un vero genio).

Golan Trevize
30/09/2009 13:42

Precedente elenco Successivo

le storie degli ospiti sono in ordine sparso, quindi 'precedente' e 'successiva' possono portare su storie di altri autori

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli (io o l'autore della storia) e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

In aggiunta: se il vostro commento non viene pubblicato non scrivetemi al riguardo, evidentemente non era degno di pubblicazione.

16 messaggi this document does not accept new posts
PaoloMD5 is not so bad Di Paolo - postato il 30/09/2009 17:38
Secondo me MD5 non è cosė male... riveduto e corretto.

Nel DB ti tieni l'md5 della pwd, cosė gli admin non possono scoprire gli orientamenti sessuali dei tuoi utenti (LOL).

Nella pagina di login fornisci dal server un numero univoco ogni volta (una challenge associata alla sessione) e lato client fai
md5(md5(pwd)+challenge)
Chiaramente lato server verifichi la stessa cosa per capire se il login sia ok.

Risultato: non fai girare la pwd in chiaro, non fai girare sempre lo stesso md5, e un "man in the middle" che sniffi il traffico non può riutilizzare l'md5 che ha letto perché ogni volta la challenge cambia.

Problemi:
1. md5 non è più considerato sicuro al 100%, meglio sha1
2. mi sfugge come fargli cambiare la pwd, in un certo momento dovrai spedire via web l'md5 della sola pwd (ma per esempio potresti generargliele tu e mandargliele via email, cosė cambierebbe il canale)

Cmq concordo, HTTPS è meglio. Se vai su Godaddy un certificato SSL base (es. per uso interno, non per ecommerce, giusto per non dover importare il certificato ed evitare l'errore di certificato errato) costa meno di 20 euro l'anno...

Ciao!

--
Paolo


Riccardo Cagnassoo.. Di Riccardo Cagnasso - postato il 30/09/2009 21:00

... santapollonia

--
Riccardo Cagnasso


Eugenio Dorigatipassword di default Di Eugenio Dorigati - postato il 01/10/2009 22:16

Perché non hai proposto al boss di mettere una password di default uguale per tutti gli utenti?!? Ovviamente trasmettendo direttamente l'md5 ^_^

--
"Unix IS user friendly. It's just selective about who its friend are"


KestySpedire password in hash Di Kesty - postato il 02/10/2009 00:03

In realtà criptarele password tramite javascript prima di spedirle tramite una connessione sicura non è una cosa stupida da fare.

Sicuramente non per l'assurdo motivo che descrivi nella tua storia.

Molta gente usa le stesse password per più cose. Farla passare già criptata, prossibilmente con un salt, permette che se la connessione viene intercettata chi fa l'attacco riesca solo a beccare un hash che può funzionare solo per la tua applicazione.

Andando oltre potresti provare ad usare un salt basato sul tempo, che permetterebbe all'hash ntercettato di essere valido per solo un tempo limitato.

Certo chi attacca può risalire al salt usato per quell'hash in quanto si troverebbe più o meno offuscato dentro un Javascript e quindi facilmente leggibile. Da li ricreare un dizionario usando il salt trovato e provare a fare un bruteforce sull'hash per risalire alla password, ma gli complicheresti senz'altro di molto la vita.

E l'https non è che sia la soluzione finale a tutti i mali, anzi.

--
Kesty


Golan Trevize@ Kesty Di Golan Trevize - postato il 05/10/2009 08:42

> Sicuramente non per l'assurdo motivo che descrivi nella tua storia.

Ecco, fammi aggiungere ROTFL.

> Andando oltre potresti provare ad usare un salt basato sul tempo, che permetterebbe all'hash ntercettato di essere valido per solo un tempo limitato.

Implementata cosė avrebbe un senso. Altrimenti non serve a niente secondo me.
Comunque, una cosetta del genere sarebbe il classico caso di PAP.
(Perle Ai Porci)

--
Golan Trevize


Val3r10@ Kesty Di Val3r10 - postato il 23/03/2010 00:02

> In realtà criptarele password tramite javascript prima di spedirle
> tramite una connessione sicura non è una cosa stupida da fare.

Non si capisce il senso di spedire un hash, visto che diventerebbe essa stessa la password IN CHIARO...
Il challenge sarebbe effettuato sulla pwd in chiaro, che è appunto un hash md5. Non sul suo hash

--
Val3r10


AngkarnDomande... Di Angkarn - postato il 02/10/2009 12:29

... ma se sul db salvi l'md5, non puoi più far recuperare la password all'utente. Dunque immagino che il prerequisito iniziale sia stato cassato in nome della "privacy" (questa poi della password che deve essere nascosto per privacy, e non per motivi di sicurezza è proprio curiosa...)

Ad ogni modo, un simil-https casalingo per l'autenticazione, si può simulare facendo l'md5 della concatenazione della password con una stringa random generata dalla pagina di autenticazione e memorizzata come variabile di sessione sul server. Quantomeno la chiave che passa sulla rete è one-shot, e non valida per sempre, come nel caso di un semplice md5 della password stessa.

Per altro, sarebbe meglio SHA-1 che MD5.

--
Angkarn


Golan Trevize@ Angkarn Di Golan Trevize - postato il 05/10/2009 08:44

> ... ma se sul db salvi l'md5, non puoi più far recuperare la password all'utente. Dunque immagino che il prerequisito iniziale sia stato cassato in nome della "privacy" (questa poi della password che deve essere nascosto per privacy, e non per motivi di sicurezza è proprio curiosa...)

Ora infatti l'utente deve richiedere il cambio password. Riceve una mail con un link da schissare e può reimpostare la password.
La cosa divertente è che uno dei requisiti era ridurre AL MINIMO l'utilizzo delle email in quanto considerate NON affidabili (leggi: il server di posta s-configurato da SL non è affidabile, viene blacklistato un mese sė e l'altro anche)

> Ad ogni modo, un simil-https casalingo per l'autenticazione, si può simulare facendo l'md5 della concatenazione della password con una stringa random generata dalla pagina di autenticazione e memorizzata come variabile di sessione sul server. Quantomeno la chiave che passa sulla rete è one-shot, e non valida per sempre, come nel caso di un semplice md5 della password stessa.

L'idea non è male, ma come nel commento precederente: PAP.

--
Golan Trevize


KurganOddio... Di Kurgan - postato il 02/10/2009 23:10

Perche` hai permesso che questa geniale soluzione passasse? Perche` non hai tagliato a pezzi il boss e poi l'hai dato da mangiare ai maiali?

--
Il massimo danno con il minimo sforzo


Golan Trevize@ Kurgan Di Golan Trevize - postato il 05/10/2009 08:51

> Perche` hai permesso che questa geniale soluzione passasse? Perche` non hai tagliato a pezzi il boss e poi l'hai dato da mangiare ai maiali?

Ho smesso di lottare anni fa affinché le cose siano fatte in modo sensato.
L'unica cosa che ne ho ricavato è stato il raddoppio della dose del farmaco contro il reflusso gastro-esofageo e un fastidioso eczema che va e viene.

Per cui lo schema è:

repeat
DB ha un nuovo requisito
IO dico come lo implementerei in modo sensato
DB lo vuole in un altro modo assurdo
IO lo faccio come dice DB
TFU
ClientiIncazzati=NumeroClienti
sleep(qualche mese)
IO lo rifaccio in modo sensato
ClientiIncazzati=0
until fired=true

It's an IT world.

--
Golan Trevize


Kurgan@ Golan Trevize Di Kurgan - postato il 05/10/2009 11:13


> until fired=true


Oppure until you_quit=true.

Io mi cercherei un altro lavoro, con calma, ma ne cercherei un altro. Non puoi vivere di ansiolitici, medicine per l'ulcera, eccetera.

Non che io sia piu` sereno di te, intendiamoci, pero` un tentativo...

--
Il massimo danno con il minimo sforzo


Golan Trevize@ Kurgan Di Golan Trevize - postato il 05/10/2009 12:04

> > until fired=true
>
> Oppure until you_quit=true.

Mi sogno di notte questo momento.

> Io mi cercherei un altro lavoro, con calma, ma ne cercherei un altro. Non puoi vivere di ansiolitici, medicine per l'ulcera, eccetera.

Son già due anni che con calma sto cercando. Non è cosė facile quando si impilano molte cose nel curriculum, si ha una certa età, si prende un determinato stipendio (e si vorrebbe quanto meno mantenerlo... non dico prendere di più!)

Molti vogliono la competenza, vogliono chi gli risolva i problemi ma poi pretendono la vita in cambio (nessun orario, dedizione totale alla causa) e storcono il naso sullo stipendio a dir loro troppo alto.

Non è un gran momento, almeno per le realtà con cui sono in contatto... speriamo bene!

--
Golan Trevize


Kurgan@ Golan Trevize Di Kurgan - postato il 06/10/2009 11:47

> Molti vogliono la competenza, vogliono chi gli risolva i problemi ma poi pretendono la vita in cambio (nessun orario, dedizione totale alla causa) e storcono il naso sullo stipendio a dir loro troppo alto.

Mi ricorda qualcosa... un mio cliente che mi dice "Guarda, io te lo dico chiaro: con te ci troviamo benissimo, sei sempre presente nelle emergenze, risolvi tutti i problemi, e anzi da quando lavori per noi i problemi sono tutti spariti, pero` costi troppo, o ci fai lo sconto o andiamo da un altro".

La mia risposta: "Andate da un altro, poi quando tutti i problemi salteranno fuori di nuovo, tornate da me, che in quell'occasione dovro` rimettere a posto tutti i casini e vi costero` 3000 euro di consulenza solo per tornare ad avere qualcosa che funziona".

Sono rimasti con me.

--
Il massimo danno con il minimo sforzo


Jepessen... Di Jepessen - postato il 29/10/2009 12:56

E se uno disabilità javascript?

--
Jepessen


Golan Trevize@ Jepessen Di Golan Trevize - postato il 30/10/2009 08:42

> E se uno disabilità javascript?

Si rompe tutto come la maggioranza dei siti "moderni".

--
Golan Trevize


Massimo M.@ kurgan Di Massimo M. - postato il 21/01/2010 15:42

questo vuol dire due cose:
1) hai detto una cosa sacrosanta
2) il tuo cliente e' braccino corto, forse, ma non stupido

--
Massimo M.


16 messaggi this document does not accept new posts

Precedente elenco Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gort