Newsgroup: it.comp.www.php
Titolo: autenticazione php

Scusate il doppione creato su free.it.programmazione.php, ma lo volevo
scrivere in questo newsgroup!!!
"ciao a tutti!!!
Volevo sapere una cosa...
perchè su molti script nel form di autenticazione si cripta la pwd e la si
confronta con la pwd criptata salvata su db???
solitamente il collegamento http non è sicuro e cmq un possibile hacker
potrebbe prendere tale pwd criptata e accedere cmq alle sezioni
protette ... o sbaglio?
grazie"

libero ha scritto:

Cosi l'amministratore del db non sapra' mai quale e' la password, credo.

mmm... non è detto...
se io sono l'amministratore del db potrei lavorare cmq dove sta fisicamente
la macchina e sniffare quello che arriva dalla post, in questa maniera
effettivamente non so la pwd per accedere alla sezione protetta, ma ho la
pwd criptata che è cmq quella sulla quel viene fatto il controllo...
boh...

 confronta con la pwd criptata salvata su db???
aspé, la password non si cripta nel form, si cripta nello script che sta 
nell'action del form, proprio per confrontarla con quella criptata nel 
db. La password passa in chiaro.
-- 
doh!

ah ok...quindi si cripta lato server?
ma allora a cosa serve criptarla?
grazie

 
Potrebbe essere perche' chi crea lo script puo' non essere 
l'amministratore del db?


Nel database non deve essere in chiaro, altrimenti se una persona accede 
al db (anche l'amministratore) prende le pwd in chiaro e può utilizzarle 
(o provare) in altre mille realtà [1]; la pwd sono criptate one-way 
(prendi per esempio /etc/passwd di linux)
[1] La maggior parte delle persone utilizza la stessa pwd per tutti i 
servizi
	Francesco

quindi parliamo di siti multiutenti nel quale io amministratore dello spazio
devo garantire che non leggo le pwd???
ma in siti nei quali c'è un solo utente che puo gestire il siti e che si
autentica...è cmq necessario?
grazie mille
Francesco F wrote:
...

 db. La password passa in chiaro.
Ma sarebbe molto meglio farlo ... proprio per non far passare in chiaro 
le password sarebbe bene criptarle in md5 con un piccolo javascript 
direttamente nella form prima di spedirle in rete.
ciao
Mauro

 direttamente nella form prima di spedirle in rete.
vero, ma in quei casi in cui sia necessario meglio usare https, anche 
perché credo che non esista in ecmascript/javascript una funzione nativa 
che calcoli l'md5.
-- 
doh!

 autentica...č cmq necessario?
fermo restando che, se la sicurezza č *necessaria*, come diceva Magilla
sarebbe meglio usare https, per quanto detto sopra puň essere *utile*
crittare anche in tal caso.
certo che in passato ho visto siti con autenticazione https inviare poi
la password in chiaro via smtp... dei veri geni! ;-)
Ciao,
Maverick
-- 
«Che non siete piů liberi di non avere una casa con letto per dormire.
 Lavorate voi - schiavi dei soldi - che non sentite la puzza della
 schiavitů!» (a Mario di Monte Mario, Roma) # 
http://libre.netsons.org/

 che calcoli l'md5.
Andiamo un po' OT ma credo che sia un argomento interessante, quindi 
segnalo ad esempio
http://pajhome.org.uk/crypt/md5/
oppure
http://www.webtoolkit.info/javascript-md5.html
entrambe ti forniscono uno script per calcolare md5 lato client e ti 
evitano la scocciatura di utilizzare https (che se non hai un 
certificato validato non fa una gran bella figura) ... tanto se basta 
criptare la password sono piu' che suff.
ciao
Mauro

 
Forse mi sono perso parte della discussione, ma qualcosa non torna.
Se invii l'md5 della password dal client al server, il server 
verificherà l'md5 inviato con:
1 - L'hash (md5) della pwd memorizzato sul database
2 - L'md5 calcolato dalla pwd in chiaro memorizzato sul db.
Se la connessione client-server è via http, sniffando la rete, prendi 
ciò che passa, e ottieni la pwd (in questo caso, se la pwd è "pippo" 
oppure un hash di 32 char, non c'e' differenza); un conto è la 
connessione, un conto è la memorizzazione della pwd sul database. Se la 
connessione è cifrata (via httpS) i dati vengono cifrati ed è più 
complesso risalire ai dati inviati.
Tornando alla domanda originale, memorizzare un hash della password al 
posto della pwd in chiaro, secondo me ha i seguenti vantaggi:
- chi accede al db (sia l'amministratore che il "furfante") non conosce 
la vera password e, visto che la maggior parte degli utenti usa la 
solita pwd per tutto, ti preservi per eventuali problemi
- uniformi le password alla medesima lunghezza (per l'md5 a 32 bit)
	Francesco

criptare la password sono piu' che suff.
Se usi l'MD5 della password, lato client, una password transita in chiaro
e basta sniffare il traffico (o leggerla dal database) per averla :-)
Per rimediare bisogna che tu usi un sistema a challenge/response, con tre
MD5 in tutto (due sul client, uno sul server).
Leonardo
-- 
 What do you make, so fair and bright;
 What do you build with sails for flight;
 What do you weave with wool so white?

 2 - L'md5 calcolato dalla pwd in chiaro memorizzato sul db.
Impossibile darti torto
-- 
doh!

se criptaimo tramite javascript è leggibile lato client...quindi poco ci
vuole a sniffare il paccheto criptato e una volta capito l'algo di
criptazione decriptarlo...
https..è a un altro lvl, non è minimamente neanche simulabile... :P
Mk


Quindi il nocciolo della questione č che su sitemi multiutente č necessario,
+ che altro per privacy la criptazione della pwd alrimenti se ne puo fare a
meno?!?!?
ciao
mk


 
NO, questo non e' vero, io onSubmit leggo il campo password e lo 
riscrivo con il md5 della password stessa. In rete viaggia solo lo 
username e md5(md5(password) + session_id).
Criptando la password + session_id sono ragionevolmene sicuro che 
nessuno mai riuscira' a sniffare qualcosa di utile perche' md5(password 
+ session_id) cambia ad ogni collegamento.
Lato server leggo hash md5 della password che ho memorizzato sul db, ci 
calcolo md5( hash + session_id) e confronto con quello che mi arriva dal 
browser.
che te ne pare?
ciao
Mauro

 ciò che passa, e ottieni la pwd 
Nel mio esempio quello che ottieni e' md5(password) con cui non te ne 
fai molto ...
ciao
Mauro

 criptazione decriptarlo...
provaci, ti danno il nobel in matematica se ci riesci :-) , md5 non e' 
invertibile, in rete trovi i sorgenti dell'algoritmo in qualsiasi 
linguaggio, ma non c'e' modo (in tempi ragionevoli) di risalire da has a 
password.
ciao
Mauro

ops... grande osservazione...: P

che te ne pare?
C'e' un rischio: immagina che il sito abbia un sistema di ripristino della
sessione *E* che non ci sia legame fra IP e session_id (del resto se c'e',
il sistema diventerebbe inutilmente incompatibile con molti sistemi per il
c.d. "anonimato in rete").
Io invio il session_id sniffato su una pagina purchessia... e il server mi
collega alla sessione. A quel punto mi loggo sul database, quindi mi viene
richiesta una password. Se invio l'hash doppio, sniffato al giro prima, il
sistema mi autorizza... nonostante io non sappia la password.
Se il challenge e' generato ogni volta diverso, questo rischio non c'e'. E
nemmeno se distruggo la sessione quando chiudo il collegamento, ma, in tal
caso, ci sono sistemi per buttarmi fuori senza consentire di sloggarmi (e'
necessario un accesso alla linea piu' forte del solo sniffing, certo).


 le password sarebbe bene criptarle in md5
MD5 e' un algoritmo di hashing, non di criptazione.
-- 
Falco Stellare - DeepVoid
www.deepvoid.it