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

Salva, una domandona...
in questi giorni due utenti (che devo controllare se erano lo stesso utente)
hanno avuto problemi di sicurezza, o meglio, mi spiego
e' come sequalcuno si sia intrufolato nei loro nickname ed abbia spedito
messaggi ad altri utenti utilizzando il loro nick.
adesso quello che mi chiedo io e' cosa dovrei fare per rendere piu' sicuro
il sito, e cosa succede se qualcuno riesce ad indovinare la password (che
per ora e' salvata in modo esplicito, ma mi sa che ci devo applicare l'MD5)
di un utete e poi l'utente inizia ad urlare di violazione della privacy..
esiste qualche cosa particolare da utilizzare in PHP, oppure sono OT e devo
solo scrivere una pagina che mi toglie qualsiasi responsabilita'? (dove
trovo una bozza?)
grazie
--
--
Fabrizio Parrella
http://www.bibivu.it
TWiN

 trovo una bozza?)
La scelta di password 'poco intelligenti' non e' la responsabilita' del
sito.
Sensibilizzare utenti e qualche disclaimer non fanno sicuramente male.
--------------------------------
Inviato via 
http://usenet.libero.it

 wrote in message
news:194Z185Z94Z45Y1...@usenet.libero.it...


ma di legge la password nel DB deve essere criptata?
Ho idea di si'. Nel senso che, se lo puoi fare e non lo fai, allora non
stai impiegando la diligenza del buon padre di famiglia.
Leonardo

 stai impiegando la diligenza del buon padre di famiglia.
qualsiasi tipo o il massimo di decriptazione?
esempio, se uso l'MD5 non posso piu' recuperare le password per chi la
perde, quindi dovrei cambiarla se qualcuno la perde, e se qualcuno fa il
calssico scherzhezzo (me lo hanno fatto a me), cambia la password alle
persone, che si riceveranno la nuova pws sulla email, ma spesso non
controllano la email tutti i giorni, e quindi credono che il sito non funzi
o altro
Se invece posso decripare la password come mi pare, potrei usare un semplce
algoritmo, magari a chiave variabile con altro algoritmo che si basa su un
dato certo, in modo da poterla tirare fuori quando l'user la richiede...
help please, ty


 snip >
Ho trovato un discreto testo sul sito dell'owasp ( 
http://www.owasp.org
credo... ).
Non è proprio inerente al tuo problema ma sicuramente è una lettura
interessante.
Ciao,
	Nicholas

 ma di legge la password nel DB deve essere criptata?
no. ma se io do la mia password strong a qualcuno che mi chiede di usare la 
password strong, e poi questo non me la cripta, è proprio una faccia di 
m***a, se c'ha un buco nel sito, tutti possono venire a sapere la mia pwd 
strong! :-)
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://marketing.tenagra.com/rfc1855.html

 ma di legge la password nel DB deve essere criptata?
In realta' no. Ma dovresti mettere nel disclaimer di non usare password
critici (tipo PIN, di lavoro ecc.).
Saluti
Jurgen
P.S.: Your quoting sucks sometimes...
-- 
I'm not a signature.

nessuno la lasciava in giro!
E' una soluzione che ho adottato anch'io con enorme successo. Il mio
problema era che gli impiegati perdevano il badge per l'accesso a un
locale "sicuro", lasciando detto badge in giro non si sa dove :-(
Leonardo

qualsiasi tipo o il massimo di decriptazione?
Dunque - tu dovresti prendere ogni precauzione per impedire che si possa
recuperare la password. Il che significa che potresti tenere la password
in DUE campi: in uno, l'hash MD5; nell'altro la password criptata con la
tua GPG Public Key.
Cosi', solo tu puoi leggere la password in chiaro facendoti inviare quel
campo.
Leonardo

diventa un po' piu' difficile.
Stavo pensando al seguente scenario:
Carico pagina PHP in chiaro, la pagina PHP contiene 2 frames di cui la
prima frame nascosta, dove un codice Javascript genera una chiave che,
ovviamente, sara' casuale a strabestia, ed una chiave complementare.
La seconda pagina chiede al server di inviare i risultati criptati con
la chiave complementare.
Il server obbedisce.
A questo punto, puoi intercettare tutto quello che ti pare, *pero'* se
l'algoritmo e' abbastanza robusto, e abbastanza veloce da poter essere
implementato in Chiavascript client-side, ci fai la birra anche se sai
l'algoritmo usato dal server, perche' l'informazione chiave (ovvero la
chiave privata) non lascia mai la frame nascosta, che e' nella memoria
del client.
Sostanzialmente avremmo SSL-over-Javascript :-)))
Quanto sopra stavo elucubrando di poterlo fare in modo trasparente con
l'output buffer callback. Pero' la gestione dei frame e' abbastanza un
incubo (posso aggirarla in parte con BASE HREF, che mi crea altre noje
per gestire gli HREF fuori pagina...)
Leonardo mumble mumble
-- 
Time's angles, mages tell, conceal a place
incredible, beyond the mundane mind;
night-shrouded and between the seas of space
dread creatures drift in the ageless winds.