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

Salve a tutti, so che ogni tanto questo tema ritorna sul gruppo, ma volevo
porvio la mia questione:
fino ad ora l' autenticazione che uso fa i seguenti passaggi e volevo capire
se è giusto oppure è esagerato, non sarei, vorrei soprattutto opinioni!:P
Sul form di accesso l'utente inserisce login e pwd, come preme submit la pwd
viene traformata da uno scipt in javascript che mi crea l'md5 della
password.
Quindi lato server ricevo la login in chiaro e la pwd criptata!
anche sul db utenti la pwd è criptata!
Quindi  se logine  pwd criptata ci sono nel db l'utente è autenticato e
passo alla fase successiva.
Ho una tabella chiamata autenticazioni nella quale ho 3 campi:idUtente,
cod_dessione e cod_user_agenT; qusti ultimi 2 li creo solo una volta
autenticato mischiando un po' di variabili e ricalcolando l'md5.
Queste infromazioni vengono salvate anche in sessione dopo esere salvate su
db!
Qunindi non mi porto + dietro logine  pwd utente, ma continuo a controllare
questi valori generati all'inizio della sessione!
Secondo voi può bastare?
Inoltre come garantiscono la sicurezza siti come libero che senza offrire
una connessione https sembra facciano passare la pwd in chiaro, a meno che
non la criptino in un modo diverso dal mio (javascript lato client). Il
metodo che uso io ha un piccolo difetto che il js che cripta la pwd lato
client la sostituisce a quella nel campo e quindi se la pwd è pippo e viene
visualizzata con ***** qundo clicco su submit per una frazione di secondo
mi diventa qualcosa tipo: ********************************!
C'è qualcosa di simile senza sostituzione?
Grazie
Mk

 C'è qualcosa di simile senza sostituzione?
Premesso quanto ti ho detto prima circa l'inutilità e i difetti del
sistema da te proposto, per risolvere il problema che menzioni, ti
basta utilizzare un campo hidden, e la password la fai scrivere là.
Contemporaneamente il campo password vero e proprio lo svuoti.
-- 
rob4you
www.outofmind.eu

Concordo perfettamente con quanto detto da rob4you.
Criptando la password lato client crei problemi:
- sostituzione nel campo (risolvibile in realtà con un input hidden)
- tempo di elaborazione lato client per hashare la password
- impossibilita di login per client senza javascript
E, soprattuto, non risolvi nulla:
che passi la password in chiaro o in md5, se pi è quella che
controlli, sniffando il traffico si hanno cmq i dti necessari al
login.
Ho visto gente arrivare ad inventarsi tenciche tipo: algoritmo di
criptazione generato lato server casualmente e passato al client che
cripta la password e poi il server la ricontolla criptata con lo
stesso algoritmo che gli ha passato.... ma la situaizone non cambia,
se c'è uno sniffer sniffa tutto, compreso l'algoritmo.
Se esiste l'SSL, c'è un motivo. L'unico modo (semplice) per il
trasporto sicuro è a livello di protocollo.
Inoltre, non comprendo la necessità dei due codici generati a
posteriori tramite "hash" per storarli su db e in sessione... ti basta
l'idUtente, no?

 Contemporaneamente il campo password vero e proprio lo svuoti.
Grazie anche per questo consiglio, 
Ma voi solitamente come vi comportate sulla questione? Cioè che tipo di 
logica usate?
grazie ancora

 l'idUtente, no?
serviva per creare 2 variabili difficilmente riproducibili! Già per una 
sarebbe abbastanza complesso!
Ma la mia è un'idea! Cmq grazie mille, ma come chiedevo anche in 
precedenza che politica usi quando devo fare una sezione del genere? come 
implementi a livello logico la sicurezza?
Grazie

Primo problema: autenticazione!
Qui l'unico problema specifico è appunto il trasporto dei dati.
Il problema può essere un malicious hacker con uno sniffer nella
stessa LAN dell'utente che si sta loggando... che leggerebbe i
parametri di login.
Come abbiamo già detto le soluzioni sono due:
- SSL
- Te ne freghi. Sono parecchi i servizi che fanno passare la login in
chiaro... dipende dal grado di sicurezza richiesto per quello che stai
implentando. Portare tutto su HTTPS, ad ogni modo, dal punto di vista
applicativo è completamente trasparente, quindi puoi non curarertene
ora e implementarlo quando lo ritieni necessario.
Una volta autenticato l'utente quello che ti serve per controllare se
è autenticato e che permessi ha è semplicemente lo userid. In genere
si controlla la sessione per una variabile userid che se c'è vuol dire
che l'utente è autenticato e fornisce l'id utente, se non c'è...
l'utente non è autenticato.
Le sessioni e il DB sono intrisecamente sicuri, a meno di
compromissioni del server o di buchi enormi nell'applictivo, quindi
non v'è nessuna necessità di criptarvi i dati... tranne ovviamente
l'hashing della password.

ottimo grazie mille!

 però ricripterebbe la pwd inserita (quella criptata che ha sniffato!)
E qui ti sbagli:
1) non vedo perché l'hacker deve necessariamente passare per il form (a
meno chela variabile che viene passata dal server al form, e poi
rispedita al server al momento del submit, non è univoca, e quindi
resta traccia sul server nel frattempo)
2) se proprio mi assicuri che l'hacker debba passare necessariamente
dalla pagina contenente il form, mi basta che disabilito javascript sul
browser, e quindi non mi cripta nulla, e la password viene quindi
inviata "criptata" così come la ho sniffata, e il server me la prende
per buona. E siamo al punto di partenza.
Se vuoi fare in modo che si debba passare per forza dalla pagina,
allora fai inviare dal server una sorta di gettone a scadenza,
trasmesso attraverso un campo hidden, valido una sola volta (quindi
univoco, tipo l'md5 del tempo più qualche altra cosa random ecc ecc.).
Ovviamente di questo gettone devi tener traccia, ad esempio in sessione
sul server. Quando l'utente ti rispedisce il form, controlli che il
valore in sessione sia uguale a quello inviato dal client tramite form.
Ma tutto questo discorso non risponde alla questione della sicurezza
dei dati trasmessi.
Non so se sia valido come sistema, ma potresti pensare a una sorta di
algoritmo con criptazione univoca. Ti dico cosa mi è venuto in mente,
posto che potrebbe essere una grande c...ata. :)
Andiamo per ordine.
L'utente si connette alla pagina di login.
Il server crea una parola random univoca (chiamiamola "cacca"), e la
memorizza in sessione (o in db), invia al client il form da compilare,
in cui tra gli altri campi, è presente questo campo hidden "cacca".
A questo punto l'utente compila il form, con nome utente e password.
La password viene hashata (o md5-ata, o l'agoritmo che ritieni più
opportuno) via javascript, ma è qui la differenza: viene effettuato
l'md5, non solo della password, ma della password concatenata alla
parola "cacca". Esempio, se la password è "albi", viene effettuato
l'md5 di "albicacca" (simile al frutto) :) .
A questo punto il form viene inviato al server.
Giunto al server, esso, che conosce la parola generata univocamente
"cacca", prende la password in chiaro nel db (corrispondente al record
avente quel nome utente), la concatena a "cacca", e calcola l'md5. Se
questo md5 e quello inviato dal client coincidono, allora vuol dire che
tutto è andato bene.
Il vantaggio è che la parola "cacca" vale una volta sola, la prossima
volta sarà diversa (magari "diarrea"). Quindi anche se ti sniffano il
traffico, non se ne fanno niente, perché non sarà più valido.
Se poi non vuoi mantenere nel db la password in chiaro, la questione
cambia di poco: ti basta lato client, calcolare prima l'md5 della
password, poi concatenarla a "cacca", e calcolare così l'md5
risultante. COsì lato server vai ad eseguire la stessa operazione:
recuperi dal db l'md5 della password, la concateni al valore di
sessione univoco (la nostra amata "cacca"), e ne calcoli l'md5.
Lo svantaggio di questo sistema, oltre il fatto di richiedere un tempo
di elaborazione lato client (ma credo sia trascurabilissimo), è sempre
quello: se un utente ha javascript disattivato non potrà mai loggarsi.
Se magari qualcuno ha letto questa mia idea e la ritiene obiettivamente
una cacata (tanto per restare in tema) :) non me ne voglia, è colpa
della stitichezza. LOL
Resta sempre valido il fatto che SSL è la migliore soluzione.
-- 
rob4you
www.outofmind.eu

 anche sul db utenti la pwd è criptata!
Ciao, io uso un metodo simile al tuo ma perfezionato.
Resta il limite come ti hanno gia' detto che se uno disabilita js non 
puo' fare login, ma a parte questo dovrebbe essere molto robusto.
Quando creo la form ho un campo hidden con il valore di session_id e poi 
faccio
MD5(MD5(username+password) + session_id);
in questo modo un eventuale attaccante che sniffa il traffico vede un 
md5 di cui non se ne fa niente perche' cambia ad ogni sessione, inoltre 
non puo' risalire in alcun modo alla password ne' ricreare "in casa" un 
md5 valido perche' non conosce md5(username+password) e non dovrebbe 
essere in grado di estrarlo dalla stringa sniffata.
dico bene?
ciao
mauro


Riprendiamo in considerazione lo scenario.
L'unico problema è un tizio che sniffa. Il tizio che sniffa deve
trovarsi all'interno della stessa LAN, anzi della stessa subnet del
tizio che si sta loggando. Per rendere le cose semplici, inoltre, la
lan deve essere realizzata con semplici hub, gli switch infatti non
inviano i pacchetti in broadcast (sono sniffabili anche le reti
switched ma è molto più complesso).
Quindi in uno scenario reale il problema è se l'utente si sta loggando
da un Internet point poco sicuro... o se il collega del'ufficio ce
l'ha con lui.
Posto questo...
Vi state dimenticando tutti una cosa... una volta autenticato l'utente
la sessione sarà valida.
L'id di sessione viene propoagato, tramite cookie o tramite get, ma
comunque in chiaro....
Quindi uno che sniffa (detto così sembra che stiamo parlando di un
cocainomane), non ha neppure bisogno di occuparsi del login, in quanto
può semplicemente ottenere un ID di sessione valida... e una volta
ottenuto quello accedere all'applicativo come se fosse già loggato.

grazie mille a tutti!
Effettivamente so che alcuni discorsi fatti sono proprio quasi da matti!
Ma purtroppo se non si ha un certificato ssl e si deve fare un sito per 
utenti non esperti e si vuole evitare che compaia la finestrella di 
accettazione del certificato non ci sono molte altre soluzioni! O sbaglio?
grazie ancora