Gli "Ospiti" della Sala Macchine

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

... santapollonia -- Riccardo Cagnasso

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"

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

> 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

> 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

... 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

> ... 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

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

> 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

> 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

> > 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

> 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

E se uno disabilità javascript? -- Jepessen

> E se uno disabilità javascript?

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

-- Golan Trevize

questo vuol dire due cose:

1) hai detto una cosa sacrosanta

2) il tuo cliente e' braccino corto, forse, ma non stupido -- Massimo M.