Grazie k.b, era questa la sicurezza di base che intendevo, perché presumo che il sistema da te descritto metta al riparo legalmente da tentativi di violazione.
Grazie k.b, era questa la sicurezza di base che intendevo, perché presumo che il sistema da te descritto metta al riparo legalmente da tentativi di violazione.
Alhazred, quello che mi interessa capire è anche, se io che gestisco un sito con db utenti ai fini della privacy sono obbligato ad avere una SSL o se dimostri che hai cercato di mettere un minimo di criptazione sei apposto?
Bene, come espertone di sicurezza PHP (cioè in pratica niubbo) ecco come la vedo
1) non spedisco nè password nè nome utente in chiaro, per i motivi sopra spiegati (utilizzo in particolare di reti wifi non sicure, tipo quelle degli aeroporti).
Uso una libreria js che mi consente di calcolare l'SHA1 sia dell'utente che della password, e in realtà lo itero 3 volte (per rendere inutili per quanto ne so le rainbow table).
Passo poi a PHP i due hash, e lato PHP mi preoccupo di verificare che siano solo caratteri esadecimali (A...F..0...9) della lunghezza stabilita.
Così evito (penso) ogni possibilità di XSS indiretto (come effetto collaterale)
Edit: ovviamente nella pagina HTML si vede bene la chiamata al JS che calcola l'hash, quindi "chiunque" sa bene qual'è il procedimento per passare da password in chiaro a hash. A me interessa l'intercettazione, ovvero il traffico comunque non contiene nè utente nè password in chiaro.
2) nel PHP non cerco con una query il dato, bensì = SHA1(SHA1(SHA1... con limit 1 e statement PDO
3) uso https dove posso (i certificati costano) per aggiungere un ulteriore livello (sempre per l'uso di wifi insicure) di affidabilità
4) e tanto per fare "filotto" pure un .htaccess (per le applicazioni aziendali) per bloccare gli spider che son sempre pronti a "cachare" qualsiasi cosa
Poi non ti so dire, questo è quanto faccio io dopo aver lurkato parecchio, ma come detto potrei cambiare nick in njubbominkia
Ultima modifica di brancomat; 27-10-2015 a 16:10
Così facendo non risolvi nessun problema. L'utente non invia direttamente la password in plaintext? Va bene, ma se l'attaccante controlla il tuo traffico gli basta inviare l'hash in questione per autenticarsi. Non sei più sicuro di quanto non lo fossi prima. Se già usi https, aggiungere questo meccanismo è inutile.Uso una libreria js che mi consente di calcolare l'SHA1 sia dell'utente che della password, e in realtà lo itero 3 volte
Certo che piglia l'hash, ma almeno non ce l'ha in chiaro (che so "pippo123") se viene usata per altri siti.Originariamente inviata da .Kurt
Meglio di niente... e "costa" poco (ci son riuscito perfino io!).
In generale lo lascio comunque con o senza https (male non fa, o almeno non credo)
https come detto è bello ma costoso
Come gia' detto ovviamente quando e' possibile e' meglio sempre usare SSL, ma non sempre e' possibile perche' comunque i certificati hanno un costo, oppure si deve lavorare su hosting base che non lo prevedono, etc.
Poi si e' una sicurezza in piu' ed anche molto semplice da implementare, visto che non serve fare praticamente nulla, ma proprio per questo non e' molto interessante a livello di architettura lato PHP.
Detto questo, volevo commentare un altro paio di cose:
- la legge sulla privacy indica quali sono e come devono essere trattati i dati sensibili, non dice come implementare un sistema di login (almeno non c'era nell'ultimo documento che mi ha passato uno studio legale): se pero' devi registrare dati sensibili la questione e' un po' piu' complessa di quello che abbiamo detto in queste pagine
- fare gli hash lato client ha l'unico effetto di non mostrare mai al server la password vera: anche se un'applicazione si salva gli hash delle password, in teoria potrebbe registrarsele anche in chiaro visto che gliele mandi, quindi e' una forma di protezione dal server e non da attacchi esterni, questo perche' come ho gia' detto inviare la password in chiaro o il suo hash ai fini dell'intercettazione non fa nessuna differenza (li' solo SSL risolve) e non vedo cosa c'entri XSS in questo contesto
- se si vuole fare le cose per bene allora non ha senso fare SHA1(SHA1(SHA1... n volte perche' SHA1 e' comunque un algoritmo estremamente rapido anche per molte iterazioni, la soluzione piu' sicura e' bcrypt
Riguarda all'abitudine di qualcuno (non mia) di scrivere
echo "ciao utente".$utente." come sei bello";
e dentro $utente uno può metterci di tutto (se non lo controlla blablabla).
Se $utente che arriva dal client vale 012923AABBDBDEE2323 hai voglia a metterci dentro un link a un sito
Di nuovo solo una precauzione, non una pallottola magica
Non voglio fare tante iterazioni, quanto evitare le rainbow table.- se si vuole fare le cose per bene allora non ha senso fare SHA1(SHA1(SHA1... n volte perche' SHA1 e' comunque un algoritmo estremamente rapido anche per molte iterazioni, la soluzione piu' sicura e' bcrypt
I programmi di crittazione lo fanno anche per 50.000 o più iterazioni, e da javascript non è che sia poi così veloce (anzi non lo è affatto).
E, soprattutto, è poi difficile fare una query del genere (o meglio dovrei far pre-calcolare le varie iterazioni SHA1 e fare una ricerca con quello).
Ma ci vuole più codice (e quindi potrebbe essere sbagliato e dare altre porte per entrare), mentre con le SHA1 "incapsulate" faccio una query SQL punto e basta (meno il codice di sicurezza è lungo, meglio è)
Magari non è l'approccio migliore, però per ora mi sembra che abbia il suo "perchè".
Non ho capito il punto, in quale circostanza uno dovrebbe scrivere in una pagina (presumibilmente visibile ad altri o il problema non si pone proprio) il valore di uno username inserito per tentare un login?Riguarda all'abitudine di qualcuno (non mia) di scrivere
echo "ciao utente".$utente." come sei bello";
e dentro $utente uno può metterci di tutto (se non lo controlla blablabla).
Se $utente che arriva dal client vale 012923AABBDBDEE2323 hai voglia a metterci dentro un link a un sito
Di nuovo solo una precauzione, non una pallottola magica
Per quello la soluzione migliore e' un salt.
Ultima modifica di k.b; 27-10-2015 a 17:49
Ad esempio per scrivere
"spiacente l'utente".$utente." non c'è o la password non va bene" o qualcosa del genere.
E sì, ho visto anche di peggio
Ho letto qualcosa, ma non è proprio immediato da gestire (o almeno non lo è per me). Vedrò di approfondire e migliorarePer quello la soluzione migliore e' un salt.
E chi se ne frega, l'ha scritto lui, viene mostrato solo a lui e se c'e' qualche XSS se lo becca lui
Permessi di invio
Rispondi quotando