2013-01-02 10 views
11

Sono nel bel mezzo della codifica di un modulo di login "ricordati di me", e finora le esercitazioni che ho letto (in parte per assicurarmi che lo stia facendo bene) dicono tutte di memorizzare la password crittografata in un cookie insieme al nome utente. Quindi, ogni volta che PHP controlla se l'utente corrente non ha effettuato l'accesso, controlla i loro cookie e cerca quei valori. Se il nome utente corrisponde alla password, ti trovi.Errore di sicurezza PHP "Remember Me"?

Per me, questo è un buco di sicurezza. Se qualcuno dovesse hackerare il database o in qualche modo ottenere l'accesso alle password crittografate, non avrebbero nemmeno bisogno di craccarle. Basta impostare i tuoi biscotti e andare. Sono corretto o semplicemente paranoico?

Il mio sistema di login utilizza le sessioni per tenere traccia dell'ID utente corrente e un 1/0 per un controllo rapido di accesso/disconnessione. L'utente non può modificare le sessioni AFAIK, quindi questo è sicuro (se non lo è, per favore fatemelo sapere). Stavo pensando di archiviare l'ID di sessione in un cookie, per poi riprenderlo, ma anche questo non è sicuro.

Mi preoccupo molto della sicurezza dei miei utenti, come posso proteggere adeguatamente le loro informazioni pur mantenendo un sito Web funzionante?

+0

Non memorizzare la password crittografata, solo l'ID utente in un cookie che scade tra X giorni. Per le aree "sensibili" (gestione account/profilo, ad esempio), è possibile richiedere loro di accedere se non hanno un $ _SESSION valido (che è necessario impostare quando effettuano l'accesso). – JennyDanger

+1

Come si sta attualmente memorizzando l'ID di sessione se la memorizzazione in un cookie è "non sicuro?" –

+0

@georgefox al momento, non sto memorizzando l'ID di sessione in niente, stavo solo dicendo che è una possibilità per la funzione remember me. – Scott

risposta

11

Di solito, quando il server è richiesto di ricordare all'utente, emette un cookie aggiuntivo oltre al cookie di sessione normale, e questa nuova stringa contiene il nome utente e una quantità ragionevole di caratteri casuali che lo rendono difficili da indovinare. Questo è ovviamente salvato nel database (per motivi di sicurezza si consiglia di trattarlo come una password e quindi saltarlo e cancellarlo), e la volta successiva che l'utente si connette allo stesso browser (supponendo che la vecchia sessione sia scaduta) l'applicazione riceve il stringa casuale, controlla il database e se c'è una corrispondenza l'utente è autenticato.

Un'alternativa sta spostando la scadenza della sessione prima di un certo importo.

Quali sono i buchi di sicurezza qui? Se si utilizza un buon generatore casuale, l'unica cosa che può succedere è che l'utente accede all'applicazione da un browser condiviso e non si disconnette manualmente quando finisce.

I normali regole si applicano sempre da quando si è su un canale insicuro: utilizzare HTTPS, altrimenti chi si siede in tra il computer e il server può rubare i cookie (o la sessione di uno o l'ricordare-me uno) e agisci come se fossi in te.

Bonus, this must-read by Jeff Atwood

+0

Questo sembra un buon modo per andare, grazie! Inoltre, leggendo quel post di login mostro ora! – Scott

-3

Ho riscontrato questo stesso problema mentre lavoravo sul mio sito Web, il modo migliore per risolverlo era semplicemente non ricordare password, solo nomi utente, fornendo un accesso più veloce ma non meno sicuro. Il fatto è che non esiste un modo sicuro per mantenere le password assolutamente sicure. Oltre ai nuovi browser, l'utente può avere il proprio browser per ricordarlo.

Ma se è necessario disporre di una password salvata, provate questo:

avere più cookie, 2 sarebbe il più facile, e utilizzare uno per una password crittografata, mentre l'altro tiene una chiave di cifratura. La password nel database contiene un'altra password crittografata, ottenuta utilizzando le chiavi di crittografia memorizzate. Quando sei pronto per controllare la password, estrai i valori e cripta la password.

Spero che questo sia stato utile. In bocca al lupo!

Modifica: potrei aver frainteso questo, se l'utente è ancora loggato, è buona pratica memorizzare una variabile di sessione.

+1

Non salvare mai la password in alcun modo (password crittografata che può essere utilizzata per accedere è ancora una password) sul client. Salva solo la chiave memorizzata sul server. Queste chiavi possono essere revocate in seguito, ma la password crittografata sarà valida fino alla modifica. –

+0

Questo non è necessariamente vero perché si imposta una data di scadenza; tuttavia, preferirei non usare il mio secondo metodo. – Zero

0

Se si desidera proteggere, non avete consentono agli utenti di tenerli registrati.

Quando si imposta la sessione, assicurarsi di impegnare la IP address per l'ID di sessione, in modo che se qualcuno prende una sessione successiva, può essere eseguita solo dallo stesso indirizzo IP. Yo può farlo mantenendo un database con ID di sessione (con hash) + hash ipaddresses. Uso la funzione php http://php.net/manual/en/class.sessionhandler.php per impostare un gestore di sessione e abbinare le sessioni con indirizzi IP.

+1

Gli indirizzi IP non sono destinati ad essere utilizzati per la sicurezza e non è possibile affidarsi agli indirizzi IP. Il controllo IP, come fai notare, rende comunque la vita più difficile per i cattivi. –

2

Non salvare mai le password in alcun modo (password crittografata che può essere utilizzata per accedere è ancora una password) sul client.

Utilizzare la chiave generata in modo casuale, memorizzata in modo sicuro sul server. Queste chiavi possono essere revocate in seguito a differenza delle password crittografate che saranno valide fino a quando non verranno modificate.

Utilizzando php è possibile generare una chiave casuale come questa md5(uniqid(mt_rand(), true)). Per una maggiore sicurezza, conservarlo salato e hash in db.

tabella Esempio:

login_keys (
    user_id int, 
    key char(40), # sha1 
    salt char(15) 
) 

noti inoltre è necessario attivare l'HTTP unica biscotto opzione.

Problemi correlati