Sistema di login PHP

Question

Sto creando un sistema di login per un'applicazione web usando PHP. La mia domanda è, è sicuro memorizzare solo le informazioni di accesso dell'utente nella sessione corrente? Ad esempio, se un utente di nome John si collega correttamente al mio sito, posso semplicemente memorizzare $ _SESSION ['Username'] = 'John' e $ _SESSION ['LoggedIn'] = 1 quindi controllare $ _SESSION ['LoggedIn'] è uguale a 1 su ogni pagina per verificare che l'utente abbia effettivamente effettuato l'accesso? O c'è un modo migliore per farlo? Non sono a conoscenza di problemi che potrebbero causare problemi, ma volevo essere sicuro che non avrei lasciato un grosso buco nel mio sito che avrebbe causato problemi lungo la strada.

Inoltre, sto memorizzando un hash MD5 della password dell'utente + sale nel database, non la loro password di stringa effettiva in modo che sia una cosa in meno di cui preoccuparsi.

Fatemi sapere se avete bisogno di ulteriori informazioni o se questo non è chiaro. Grazie!

Answer 1

Questo è un approccio perfettamente ragionevole. I tuoi visitatori non saranno mai in grado di modificare i dati della sessione sul tuo server (a meno che il server stesso non sia sicuro, nel qual caso tutto è fair game), quindi un valore di LoggedIn = 1 nella sessione è perfettamente sicuro.

Tuttavia, tenere presente il rischio che un visitatore dirotti la sessione di un altro (rubando la chiave di sessione). Un modo per proteggersi da questo è anche memorizzare l'indirizzo IP del visitatore (da $_SERVER['REMOTE_ADDR']) nella sessione e poi in richieste successive confermare che non è cambiato.

Answer 2

Suoni OK; potresti voler pensare di impostare un tempo di scadenza (quindi se qualcuno si allontana e lascia il browser aperto non sono nello troppo molto pericoloso).

Answer 3

Considerare SHA1 o un hash ancora più forte anziché MD5. Lo stai salendo, però, va bene.

Torna alla tua domanda: si, va bene. Tuttavia, attuare misure per assicurarsi che le sessioni non vengano dirottate. Wikipedia actually has a fairly good article on it.

Nella maggior parte dei sistemi che ho scritto, ho incluso la logica per verificare che l'IP remoto non sia cambiato. Puoi memorizzarlo anche nella sessione, dato che le vars di sessione non vengono passate all'utente (solo l'ID di sessione). Se vuoi davvero diventare creativo, puoi aggiungere altri assegni: user-agent e cosa no.

È inoltre necessario tenere conto degli attacchi di sessione. Controlla i referrer. Se si dispone di un'operazione disastrosa, chiamiamola POST a DeleteMyAccount, posso scrivere una submission di modulo più javascript per premere DeleteMyAccount in un post del forum su un sito non correlato, contando su quella sessione per essere presente nelle informazioni dell'utente.

Answer 4

ci sono una serie di rischi da considerare: dirottamento

1. Sessione: questo è dove qualcuno ruba cookie dell'utente e finge di essere loro. Alcuni suggeriscono il filtraggio IP per contrastare questo, ma questo può avere effetti collaterali scomodi. Le persone utilizzano i siti Web da dispositivi mobili o computer portatili che vengono utilizzati negli hotspot Wi-Fi, casa e lavoro e ci sono altri casi in cui gli indirizzi IP possono cambiare. Quindi il mio consiglio è di farlo solo per i siti sensibili di (ad es. Online banking);
2. Il tuo sito è compromesso: in questo caso l'utente avrà comunque accesso al tuo database quindi non c'è alcun rischio aggiuntivo con la memorizzazione delle informazioni di autenticazione nella sessione.Possono anche cambiare facilmente chi sono inviando le istruzioni UPDATE al tuo database;
3. Un sito di co-hosting è compromesso: se si utilizza l'hosting condiviso, un sito completamente non correlato potrebbe metterti a rischio (con o senza questo schema) perché un sacco di siti sono tutti in esecuzione sulla stessa istanza di Apache e può quindi accedi ai file degli altri (anche se può essere difficile capire a quale sito appartengono). Quindi, se un sito di cui non hai mai sentito parlare è compromesso, può avere un impatto sul tuo sito;
4. Un sito di co-hosting è dannoso: simile a (3) tranne che la minaccia è interna ma è comunque simile.

Quindi direi che va bene (soggetto a (2)) ma solo essere consapevoli dei rischi. Seguire, come minimo, queste best practice:

1. Non memorizzare mai password non crittografate;
2. Utilizzare un algoritmo di hashing forte (preferibilmente SHA1 o MD5);
3. Assicurarsi che i cookie di autenticazione scadano a un certo punto. Quanto tempo dipende dal tuo sito. Potrebbe essere una settimana o due o un'ora o due di inattività o entrambi.

Answer 5

Nel complesso, siete decisamente sulla buona strada. Ti consiglio di utilizzare ID per gli utenti nella sessione anziché il nome utente poiché gli ID sono un riferimento univoco migliore all'interno del codice.

Inoltre, md5 non è considerato abbastanza forte per l'hashing della password più: è troppo veloce per hash e non si vuole che in un controllo che un utente malintenzionato dovrà eseguire più e più volte (mentre un utente reale solo ha bisogno di farlo una volta). Vorrei poter trovare il riferimento, ma la saggezza di punta è quella di fare un sacco di giri di un algoritmo di hashing all'avanguardia, come sha512.

Answer 6

È possibile utilizzare COOKIE anziché la variabile SESSION. è possibile impostare COOKIE seguendo

setcookie ('ID', $ variabile, ora() + 8 * 60 * 60);

È necessario essere a conoscenza di SQL Injection. Quando inserisci o aggiorna il tuo database in cui è presente una casella di testo utente, tieni presente SQL Injection. Inserisci/Aggiorna i tuoi valori con la funzione htmlentities().