Newsgroup: it.comp.www.php
Titolo: Criptare password: questo procedimento è corretto?

Sto realizzando un sistema di login per il mio sito.
PEr la criptazione della password, leggendo qua e là, sono giunto
all'ideazione di questo procedimento:
- inserisco i dati di login (utente e password) in un form
- PRIMA di fare inserimento nel db la stringa della password la passo a
md5, in modo che nel db ci sia la password criptata
Quando vado a fare il login, prima di fare la query, passo la stringa
password a md5 e poi faccio il confronto tra le due password.
E' il procedimento "corretto"?
Sergej
-- 
http://www.ildeposito.org
Canti di protesta politica e sociale
Archivio di testi e accordi

 E' il procedimento "corretto"?
Dipende dalle necessita.
-- 
I am what I am, I do what I can
Sei un newbie? Leggi questo 
http://url.repository.biz/go/3C
Vuoi supportarmi? 
http://url.repository.biz/go/3E
Do. Or do not. There is not try.

 Dipende dalle necessita.
E' un piccolo sito, niente di che.
E' giusto per non scrivere in chiaro la password nel db...
Credi possa andare??


 Credi possa andare??
Si.
-- 
I am what I am, I do what I can


> Dipende dalle necessita.
Sono d'accordo

 E' il procedimento "corretto"?
No, perhce' gli utenti si dimenticheranno la password, e tu dovrai
inserirne un'altra "123456789" e comunicargliela invitandoli a modificarla
al primo login, loro non lo faranno mai, e in capo a qualche mese di
questo andazzo ti ritrovi il DB pieno di hash tutti uguali...
Volendo si puo' ovviare salvando nel DB un seme casuale e l'MD5 della
password concatenata al seme.
Comunque, cosi' ti perdi la possibilita' di inserire nel sito la
solita "Hai dimenticato la password?" che risolve tutti i problemi
del sistemista.
Ciao,
 ___ 
/_|_\  Umberto Salsi
\/_\/  
www.icosaedro.it

 del sistemista.
IMHO se fai delle obiezioni del genere significa che non hai mai
sviluppato un sistema del genere in vita tua.
Per risolvere qualsiasi problema e' sufficiente generare una password
random quando l'utente richiede di recuperarla.


 del sistemista.
Non è vero.
Ma almeno i siti degli altri li visiti?

 -- 
scusate se mi intrometto.
Se la password viene cifrata lato client, sempre in md5, è più sicura o 
peggiora la situazione? 

 peggiora la situazione?
Sarebbe anche meglio. Eviti il passaggio in chiaro.

 peggiora la situazione?
No... anzi, imho aumenta di un livello la sicurezza nel caso in cui c'è un 
qualche sniffer malefico di mezzo tra il server e il client...
fermo restando che se qualcuno intercetta la pass cifrata può già, volendo, 
entrare nel tuo sito (basta appunto che la spedisce al server già 
cifrata)... ma magari non verrà a sapere la password in chiaro che potrebbe 
essere comune ad altri servizi (è un livello di sicurezza in più non per il 
tuo sito, ma per il cliente stesso insomma).
l'unica cosa è che devi stare attento nel caso in cui il client abbia 
disabilitato il javascript (immagino che la cifri con quello).
Devi comunque fare un controllo lato server, per esempio confermare che la 
lunghezza della pass passata per POST sia di 32 caratteri... altimenti l'md5 
lo fai stesso sul server e pazienza se è andata cosi' :)
ciao,
Luca(riello) 

 peggiora la situazione?
Avevo risposto frettolosamente che era più sicura, in realtà non è 
propriamente esatto per cui ho spedito dritto dritto un cancel.
Generando l'hash lato client eviti sicuramente di passare la password in 
chiaro. Ma siccome il sito a quel punto accetta l'hash, se lo sniffano 
può essere usato per fare direttamente la logon.
Dal lato server poi si torna al problema originale, ovvero che memorizzi 
esattamente ciò che ricevi per autenticare, come se tu memorizzassi la 
password in chiaro. Ovvero, se qualcuno ti legge le hash queste sono 
pienamente valide per fare la logon.

 cifrata)... 
Infatti :-)

 password ma l'hash. Quindi lo sniffer ha ciò che gli serve, comunque.
soluzione:
in fase di registrazione dell'utente MD5 lo fà il client e manda l'hash 
al server
in fase di login il client manda la pass in chiaro e MD5 lo fà il server.
ovviamente se c'è uno che sniffa "sempre" non c'è nulla di sicuro
ciao
Alesi_27

 
ho risposto di corsa, è ovvio che ho detto una sciocchezza
ciao
Alesi_27

[CUT totale]
La butto lě, anche perchč mi č venuta in mente cosě solo dopo aver letto le
risposte di tutti gli altri.
Lato client potresti combinare la passward o l'md5 della password con un
valore "temporaneo", ovvero un time stamp (in fase di login devi passare
username, risultato della manipolazione della password e timestamp), oppure
l'id di sessione di php, o qualunque dato che puoi condividere tra server e
client. Lato client combini i valori in tuo possesso con suddetto valore e
lato server applichi una procedura di verifica. Come tutti i sistemi non č
sicuro al 100% ma di sicuro č piů difficile risalire alla password perchč
comunque non passeresti  quasi mai due valori identici per lo stesso utente.

 quasi mai due valori identici per lo stesso utente.
IMHO e' totalmente inutile.


Iw7 wrote:

Non serve a nulla. Complichi la soluzione di fantasia, ma la complichi 
solo per te. Non per chi vuole violare il sistema che impiega sette 
secondi a capirlo.
Non c'č da inventarsi nulla, chi vuole la sicurezza nella connesione usa 
https.

 https.
infatti, certe cose le hanno studiate apposta.
Ciao ciao

"Setec Astronomy" <setec@_NO_NOSPAM_freemail.it> ha scritto nel messaggio 
news:xAeXe.7281$9l.2...@twister1.libero.it...

Grazie a quanti hanno dato il loro parere.
Dunque, visto che lato client il codice è in chiaro, è inutile scervellarsi 
a trovare un algoritmo più o meno sofisticato, tanto è replicabile.
Quindi, riassumento, se c'è uno sniffer è indifferente passare la password 
in chiaro o cifrata.
L'unica differenza è che, nel caso di cifratura lato client, per impersonare 
l'utente si deve creare una pagina ad hoc copiandoci i vari valori di 
sessione, ecc. e sostituendo la password con quella sniffata.
Giusto?