Quali sono i pro e i contro di consentire agli utenti di rimanere connessi a un'applicazione web?

I'm working with cookies in PHP for a login script and my friend thinks storing a hashed password in a cookie is bad news.

Il tuo amico ha assolutamente ragione, non c'è ragione per farlo. Non si tratta di rimanere loggati, si tratta di esporre inutilmente l'hash della password (nota a margine: si prega di utilizzare PHP password_hash per le password di hashing).

Mentre esporre l'hash della password su una connessione crittografata (si sta usando HTTPS no?) non è la fine del mondo, il vero problema è che mi indica che probabilmente stai autenticando le sessioni confrontando il valore del cookie rispetto all'hash memorizzato. Ciò significa che non hai modo di invalidare i cookie di sessione, se l'hash della password è mai stato esposto, è tutto ciò che un utente malintenzionato deve accedere all'account di qualcuno!

Usa la gestione delle sessioni integrata di PHP, che usa un valore casuale sufficientemente lungo per tenere traccia degli utenti (almeno nelle versioni recenti, le vecchie versioni hanno avuto problemi con questo).

Per rispondere alla tua domanda iniziale su quanto dovrebbero durare le sessioni, varia selvaggiamente. Il mio desktop è collegato indefinitamente al mio account Gmail, ma la maggior parte dei siti bancari espira le sessioni dopo 15-30 minuti di inattività. Per un sito che non ha nulla di troppo importante, le sessioni di lunga durata vanno bene, anche se è bene consentire agli utenti di vedere le sessioni esistenti sul proprio account e scadere manualmente.

Permettere agli utenti di rimanere loggati per un accesso meno sensibile va bene come dichiarato, Amazon lo fa. Tuttavia, siti come ProtonMail non consentono questa opzione.

storing a hashed password in a cookie

Questo è un problema con, posso solo vedere due metodi per farlo funzionare:

1. passa l'hash
2. Trattare l'hash come token di autenticazione

Entrambi i metodi sono vulnerabili. Passare l'hash equivale essenzialmente a memorizzare una password in testo semplice all'interno di quel file di cookie. Utilizza invece il cookie per memorizzare un token di autenticazione . Molti approcciano il token in modo diverso, userò MD5 solo a scopo dimostrativo, si noti che si tratta di una funzione di hashing deprecata e non dovrebbe essere utilizzata per informazioni riservate. Questa è un'idea di base comune per l'implementazione di token di autenticazione "md5 (sale + nome utente + ip + sale) " . Quindi è possibile revocare il token di sessione al momento della conclusione senza la necessità di modificare la password. Inoltre, puoi impostare che i token scadano dopo X giorni, assicurando che i token dei cookie meno recenti siano utilizzati con minor probabilità per essere un vettore di attacco.

Le persone che lasciano la propria postazione di lavoro sbloccata sono una preoccupazione legittima. È necessario utilizzare un sistema operativo di ripristino o educare gli utenti di frontend su OpSec. Anche i programmi compromessi che accedono e copiano i cookie di autenticazione potrebbero costituire un problema. E accedendo all'unità di archiviazione (se non si utilizza la crittografia) quando si spegne. Tutti sono preoccupazioni legittime, ma la formazione dello staff su Operation Security è un fattore importante.

Analizziamolo in due domande:

1. Come preservare la sessione e perché archiviare una password con hash non è una buona idea.

   Le informazioni di sessione che consentono all'utente di autenticarsi senza password sono spesso memorizzate nei cookie sotto forma di "token di sessione". Un buon token di sessione è una stringa imprevedibile (ad esempio casuale crittografica) che si associa a un utente sul server. Pertanto, in caso di perdita di cookie, può essere utilizzato in attività dannose fino a quando un utente non interrompe una sessione o verrà interrotta automaticamente. I framework PHP dispongono di strumenti di sicurezza predefiniti per implementarlo.

   Ovviamente, un utente e un sito web sono esposti a determinate minacce.

   L'utente, da un lato, può perdere il controllo sulla riservatezza dei suoi cookie per mezzo di diversi fattori: virus, vulnerabilità della sicurezza del browser, accesso fisico. Tutte queste cose accadono di volta in volta e la vostra missione è quella di minimizzare il rischio di perdere alcuni dati preziosi. Naturalmente, potrebbe esserci un virus che otterrà un controllo totale sul PC o registrerà le sequenze di tasti, ma ci sono molti scenari meno dannosi, in cui l'accesso è limitato (ad esempio, il recente bug di Safari con l'esecuzione di codice JS arbitrario in qualsiasi scheda)

   Il sito Web, dall'altra parte, può anche presentare vulnerabilità di sicurezza come XSS e altri che potrebbero causare l'esposizione dei cookie. Una cosa divertente è che il sito web ogni era o sarà vulnerabile in alcuni momenti del tempo, quindi la missione è, ancora una volta, di ridurre al minimo l'impatto negativo.

   Ora, se stiamo memorizzando una password nei cookie, permettiamo a un hacker che l'ha rubato di avere un accesso permanente e la libertà di lettura o modifica delle informazioni nonostante la disconnessione dell'utente (che interromperebbe il vecchio token di sessione se ne avessimo uno ) fino a quando un utente non modificherà la password.

   A proposito, dare a un utente lo stesso token di sessione ogni volta che effettua il login è come archiviare le sue password nei cookie.

2. Perché il timeout della sessione è una buona pratica.

   Considerati i cattivi scenari che ho descritto in p.1, più lunga è la sessione attiva, più a lungo un potenziale malintenzionato può eseguire attività dannose. Quindi la soluzione è limitare la durata della sessione a un periodo di "sicurezza rilevante". Ad esempio, un'applicazione bancaria probabilmente ti disconnetterà dopo 20 minuti di inattività. Facebook conserverà la tua sessione per mesi, ma hai la possibilità di tracciare tutti i tuoi accessi e terminare qualsiasi sessione attiva.

   Non conosco le specifiche della tua app, ma se non memorizzi alcuna informazione finanziaria o privata, un mese per una sessione di live andrà bene.