[PHP] [MYSQL] sono sicuri i dati?

[Jarno]

a parte tutti i giochettini tramite l'uso delle query string o dei cookies ...che mi sembrano errori grossolani nella progettazione, vorrei sapere se i miei dati sono sicuri se:

1. il login (user+psw) avviene con form senza query string, via https
2. una pagina php verifica la presenza nel database di user+psw
3. se c'è scrivo un cookie di 30minuti con l'id di sessione appena creato e scrivo nel record dell'utente: id + ip del computer + data/ora del login
4. ad ogni pagina faccio il controllo: permetto l'uso della pagina solo se nella tabella è presente gli stessi: id + ip criptato + data/ora del login < 30 minuti

non è sicuro così?

Inoltre, ma è proprio necessario e utile criptare i dati del database per proteggerli dai birboni esterni?

[mark2x]

Gli unici errori di progettazione di un'applicazione sicura li trovi qui: http://phpsec.org/projects/guide/
Gli altri sono giochettini sicuri.

Per i punti 1-4: in generale si fa così infatti. Commenti:
2) no, deve verificare la corrispondenza di MD5(password_originale) (quindi ciò che è su db) con MD5(password_digitata);
3) - 4) certo, ma non vedo proprio il motivo dei 30 min. Irritare i tuoi clienti??

Inoltre, ma è proprio necessario e utile criptare i dati del database per proteggerli dai birboni esterni?

Sì.

[andr3a]

1. il login (user+psw) avviene con form senza query string, via https
meglio se invii non in chiaro user e password, anche su https



2. una pagina php verifica la presenza nel database di user+psw
meglio se verifica la presenza di sha1(user)+sha1(psw) che dovranno arrivare gia' hashati dalla form e non in chiaro



3. se c'è scrivo un cookie di 30minuti con l'id di sessione appena creato e scrivo nel record dell'utente: id + ip del computer + data/ora del login
le sessioni sono insicure, soprattutto su server virtuali.
Qualunque dato sensibile andrebbe salvato mai in chiaro su un cookie, il cookie non e' sicuro, il PC dell' utente potrebbe essere pieno di worms, spyware o altro, per questo non si salvano i dati in chiaro, per la data ed ora ok, per la sessione, usi quelle in database e lasci perdere $_SESSION (se di $_session parlavi).
Ogni pagina dovrebbe filtrare o controllare la validita' di user e pass, non con $user = MD5(user) ma con $user = user, in database i dati dovrebbero gia' essere hashati e non controllati e rihashati ogni volta



4. ad ogni pagina faccio il controllo: permetto l'uso della pagina solo se nella tabella è presente gli stessi: id + ip criptato + data/ora del login < 30 minuti
l' ip non serve a niente, se 2 utenti di un' azienda escono sullo stesso modem / router / connessione avranno lo stesso ip, l' IP non e' un campo affidabile poiche' e' facilmente camuffabile e praticamente mai univoco



non è sicuro così?
non e' mai sicuro, parti da questo presupposto, quindi per essere virtualmente sicuro piu' cose fai meglio e' ... non c'e' un "basta fare cosi' e vai tranquillo" poiche' le strade per entrare possono essere veramente tante.
Dicono, comunque, che il posto piu' sicuro dove mettere dei dati sia un database ... questo e' vero finche' non ti entrano nel server, senza passare da http per intenderci, pero' significa che piu' sfrutti il db piu' puoi stare tranquillo, quindi sul cookie metterei solo la sessione univoca e temporanea del database e nient altro ( e magari qualche accoppiata ip , informazioni del browser o altro potrebbero essere utili per avere maggiore univocita' ... ma il solo ip non serve a molto )



Inoltre, ma è proprio necessario e utile criptare i dati del database per proteggerli dai birboni esterni?
se ti entrano nel database sei gia' con le pezze al (non parlo delle banali sql injections o meglio non parlo solo di quelle, parlo di entrare proprio nel db non via http) ... pero' i dati user e pass , o almeno quelli, non saranno reversibili ... se hai carte di credito o altri dati da verificare idem, salva sempre tutto hashato, tutto quello che puoi e che non ti serve recuperare, ovviamente, cosi' il cliente se o quando invia hashato puo' stare piu' tranquillo

[nik600]

perdonate la gianata ma:

se un algoritmo di hash non permette di "tornare indietro" come faccio a leggere i campi che sono nel db se sono hashati?

grazie nik

[mark2x]

Come avviene anche in ogni SO, le password in chiaro non vengono mai memorizzate, ma, al loro posto, viene memorizzata la loro "firma" (one way hash) con una funzione di digest, tipo MD5.

La logica sottostante è che è computazionalmente veloce ricavare dalla password in chiaro la firma, ma computazionalmente impossibile il verso opposto, dacchè l'inversione dell'algoritmo di firma è "matematicamente difficilissima".

Ciò che viene confrontata è quindi la firma della password scelta dall'utente e la firma di quella digitata. Se queste coincidono, ciò vuol dire con elevatissima probabilità (certezza) che anche le password in chiaro coincidono, dato che la lunghezza della firma finale è in genere grande.

[mark2x]

Note su "elevatissima probabilità" del post di cui sopra. Ci si potrebbe chiedere: "Elevatissima probabilità vuol dire che cmq potrebbe succedere che due firme siano uguali? E la probabilità che succeda dipende dall'algoritmo o dalla lunghezza della firma?"

1. Se e solo se l'algoritmo ha una "funzione di uscita" con densità di probabilità costante per ogni configurazione di bit (ovvero non preferisce, a fronte di ingressi vari, certi bit di uscita anzichè altri), l'algoritmo è totalmente ininfluente.

2. Ovviamente più lunga è la firma meno è probabile che due firme facciano capo ad una stessa password in chiaro. Se n è il numero di bit con cui viene codificata la firma, es. 256, lo spazio delle possibili firme sarà composto di 2^256 elementi. La probabilità di trovarne due uguali è 1/(2^256).
Che sarebbe 1 probabilità su 1.000.000.000.000...altri 62 zeri...000. Probabile no? Oi.

Ovvio è che se l'ipotesi 1. non è soddisfatta, quanto detto in 2. si riduce, ovvero sarà un poco più probabile di 10^-77, ma.. non stiamo a guardare il capello...

[nik600]

ok ok ma x le password ci sono, quello che dico io è se dovvessimo hashare tutti i campi di un post... poi come si estraggono?

[mark2x]

Non li estrai, infatti NON li devi hashare...
Al limite criptare. Non è certo la stessa cosa...

[buba88]

non si estraggono!

ciò che devi hashare sono i campi che nn dovrai mai recuperare dal database, ma solo usarli per un confronto.
hai mai fatto caso al fatto che praticamente tutti i siti che gestiscono utenti, quando dici di esserti dimenticato la passworde e rispondi alla domanda segreta, dopo nn ti dicono qual'era la tua pass, ma semplicemente ti danno la possibilità di cambiarla, in quanto neanche loro sanno qual'è la password che avevi scelto, ma ne conoscono solo l hash.

[andr3a]

Originariamente inviato da nik600
quello che dico io è se dovvessimo hashare tutti i campi di un post... poi come si estraggono?

nessuno ha detto di hasharli tutti, io ho detto di hashare i sensibili che non necessariamente saranno solo utente e password, anche se per la maggiore saranno sufficienti questi.

Un esempio? Le banche spesso usano codici univoci per effettuare delle transazioni on-line ( Unicredit ad esempio rilascia una carta con 30 o piu' codici univoci richiesti random ) ... ecco, quei codici sono in chiaro solo sulla tua carta poiche' in database saranno cryptati o hashati, quindi anche quei dati non devono essere scoperti, in quanto sensibili ma non necessariamente utili da sapere, tanto quanto utente e pass, a te non deve interessare saperli, ti basta verificare che coincidano, hashati, con l' hash già presente in database.

Va meglio ora ?