Ho deciso di implementare un sistema di autenticazione semplice, personalizzato da solo per la mia applicazione Web: quando un utente effettua l'accesso, memorizzerò il suo "user_id" in una sessione o in un cookie .
Se scelgo il cookie, dovrei crittografare "user_id".
Tuttavia: qual è la differenza tra la memorizzazione in uno rispetto all'altro per lo scopo di autenticazione? Quale è più sicuro? Perché? Cosa è raccomandato? A cosa dovrei prestare attenzione quando lo faccio?
Stai confrontando arance e mele qui, o più esattamente, mattoni e case. Ciò che identifica una conversazione è per definizione una sessione. Punto. Ma la sessione può essere implementata in vari modi:
Non tutti i framework consentono tutte le implementazioni di sessione.
Tornando alla tua domanda, dal punto di vista della sicurezza, i dati che non lasciano il server dovrebbero essere più difficili da manomettere, perché è banale creare un cookie personalizzato attraverso qualsiasi libreria client HTTP. Pertanto, dovresti almeno firmare il cookie e controllare la firma su ogni pass, e se non vuoi perdere i dati interni dall'applicazione, devi anche crittografare il contenuto dei cookie. Questo, e la limitazione aggiunta di 4k per una dimensione del cookie, è sufficiente a spiegare perché i dati di sessione sono generalmente tenuti lato server con solo un ID passato in un cookie.
TL / DR: a meno che tu non abbia una valida ragione per non farlo, il mio consiglio sarebbe quello di attenersi all'utilizzo comune e memorizzare l'id utente in una sessione lato server: questo è probabilmente il modo predefinito per il tuo framework .. .
Risposta dettagliata:
What's the difference between storing in one versus the other for the authentication purpose?
Nessuna differenza su un punto di vista funzionale perché entrambe sono implementazioni differenti di una sessione
Which is more secure? Why?
L'uso di una sessione è più sicuro perché si baserà su una struttura o una libreria pesantemente testata. La sessione lato server è più affidabile perché le sessioni di cookie si basano su chiavi aggiuntive per la firma e / o la crittografia e la gestione delle chiavi è un ulteriore punto da considerare in un punto di vista della sicurezza
What's recommended?
Sicuramente la sessione, perché è fornita dalla tua struttura o libreria, e la maggior parte dei problemi di sicurezza derivano dall'implementazione. Questo è il motivo per cui le best practice sulla sicurezza consigliano non eseguire il rollover
What should I pay attention to when doing so?
Non puoi fare affidamento su ciò che non controlli, quindi non puoi aspettarti che un cookie non sia stato manomesso dal lato client. Quindi deve firmare il cookie a livello di applicazione con una chiave gestita in modo sicuro e sicuro. L'ID utente interno normalmente non è rilevante per il client, quindi è necessario crittografarlo ancora a livello di applicazione e comunque con una chiave gestita in modo sicuro e sicuro. È necessario aggiungere controlli aggiuntivi, sempre a livello di applicazione, per assicurarsi che il cookie (anche firmato e crittografato) non sia stato spiato da una sessione precedente legittima, quindi è necessario almeno memorizzare l'ID di sessione all'interno del tuo specifico cookie firmato. E potrebbero esserci altri possibili problemi a cui non ho pensato ...
È meglio memorizzare quel tipo di dati nella sessione.
Il cookie è suscettibile di essere rubato dal punto di vista del lato client, è possibile applicarlo a forza maggiore o essere sniffato nella rete.
Poiché la raccomandazione su cosa prestare attenzione è sempre una preoccupazione in ciò che i clienti possono inserire. Sono d'accordo con te nel rotolare il tuo, ti fa capire cosa sta realmente accadendo.
Stai attento con il tuo uso del linguaggio. In entrambi gli scenari si memorizzano i dati della sessione: la differenza è che in un caso lo si sta memorizzando sul server e nell'altro sul client.
Se l'id utente è memorizzato in un cookie, anche se è crittografato, è possibile che qualcun altro copi i dati e impersonifichi l'utente autenticato. Se il cookie contiene solo un riferimento ai dati conservati sul server, questo è ancora possibile, tuttavia esiste una finestra limitata di opportunità definita dalla sessione autenticata - una volta scaduta non può (o più comunemente dovrebbe non ) risorge.
Esistono alcuni argomenti per l'archiviazione dei dati di sessione in un client relativi alle prestazioni e alla scalabilità. Da un punto di vista della sicurezza, si potrebbe obiettare che c'è qualche vantaggio nel non lasciare un'impronta dei dati degli utenti su un server (ma questo non è un argomento molto valido in quanto è possibile ottenerlo crittografando sul server utilizzando una chiave memorizzata sul client ).
Se si memorizzano i dati di autenticazione lato client è necessario fare di più per proteggerli - le comunicazioni devono essere esclusivamente su HTTPS, una scadenza e il token di autenticazione deve essere crittografato nel set di dati (ed entrambi devono essere convalidati per l'autenticazione).
Se non hai una ragione convincente per mantenere i dati di sessione sul client, segui la folla e memorizzala sul server con solo un riferimento non enumerabile e auto-scadente alla sessione sul client.
Penso che ci possa essere una certa confusione su cosa sia un cookie e cosa sia una sessione. Come sottolinea @elsadek, il cookie di solito memorizza un ID di sessione, che a sua volta viene utilizzato lato server per recuperare i dati associati, nel tuo caso, un ID utente.
Il server (con gestione sessione abilitata) controlla se un cookie è allegato a una richiesta e, in caso contrario, restituisce un'intestazione Set-Cookie , in genere contenente un ID sessione. Il browser lo preleva e in seguito passerà l'ID della sessione come Cookie al server.
Ciò consente al server di associare i dati a una sessione del browser, da cui il nome "sessione".
Quindi: archivia il tuo ID utente nei dati della sessione. E: non tirare il tuo. Ci sono tonnellate di librerie, ignorando il tuo framework, che fanno questo per te.
Leggi altre domande sui tag authentication web cookies