Sessione contro autenticazione cookie

5

Ecco cosa intendo per i due:

Autenticazione sessione : stato memorizzato "stato autenticato" in una variabile di sessione.

Autenticazione cookie : memorizzato "stato autenticato" in un cookie protetto da HMAC.

Domanda : c'è un vantaggio in un modo rispetto all'altro dal punto di vista della sicurezza?

La miglior ragione per la quale mi sembra di trovare l'approccio dei cookie è che il server deve memorizzare meno dati, che non è correlato alla sicurezza.

Note extra

Diciamo che mi dici che usare l'autenticazione dei cookie è meglio ...

Ho visto così tante applicazioni web che usano l'autenticazione dei cookie ma non riescono a collegarlo alla sessione. È un problema perché memorizzano le informazioni dell'utente come il suo accesso alla sessione. Quindi, puoi creare un semplice attacco come login sul tuo account che non ha quasi nessuna autorizzazione, quindi rubare il cookie di sessione da un amministratore e poi impersonarlo.

Con questo intendo dire che, a prescindere dalla forza dello schema basato sui cookie rispetto all'approccio della sessione, lo ha appena perso (a causa della scarsa gestione delle sessioni). In uno scenario come sopra, un approccio basato sui cookie non porta a nulla di saggio.

    
posta Gudradain 06.07.2015 - 15:24
fonte

3 risposte

2

Non sono un grande fan dell'autenticazione dei cookie come avevi delineato.

L'autenticazione di sessione assegna un token casuale al client che non ha altro significato che essere un puntatore alle informazioni sulla sessione memorizzate sul server. I problemi principali sono l'entropia ridotta per la generazione di token.

Tuttavia, l'autenticazione dei cookie tende ad avere più problemi. Poiché le informazioni contenute nel cookie contengono dati sensibili, devono contenere una sorta di soluzione HMAC per impedire la manomissione. Ruby on Rails fa questo e hanno avuto problemi di crittografia e problemi di esecuzione del codice. Play framework fa questo, e hanno avuto problemi di crittografia e problemi di esecuzione del codice. Un tale meccanismo può funzionare se fatto bene, ma in questi due esempi, sbagliarlo può essere disastroso.

    
risposta data 06.07.2015 - 17:45
fonte
2

Preferirei l'autenticazione basata sulla sessione ogni volta. Un cookie non è una buona opzione.

Come ha detto @HexTitan, anch'io non sono un fan dell'autenticazione dei cookie. È facile (in parte) rompere la sua sicurezza. Bruteforcing un cookie fino a quando non versa un po 'di segreto non è così difficile.

D'altra parte, devi essere sicuro che le tue sessioni abbiano sufficiente entropia. In caso contrario, qualsiasi utente malintenzionato può avviare più connessioni al server, ottenere l'id di sessione e vedere come si correlano. Avere una scarsa entropia può portare alla previsione della sessione.

Al di fuori del punto di vista della sicurezza, è possibile memorizzare molti più dati in una sessione che su un cookie. Ridurrete anche il traffico sul vostro server, poiché ogni singola richiesta invierà i cookie, e se la vostra pagina ha 135 immagini, 10 script e 5 fogli di stile CSS, il cookie verrà rispedito 150 volte solo per la home page.

Se lo spazio di archiviazione è un problema, puoi bzip o gzip i dati della sessione e ridurre i requisiti di archiviazione. Avere una durata della sessione breve (~ 2h) aiuterà anche. Ad esempio, PHP di solito pulisce le sessioni scadute ogni due ore.

    
risposta data 08.07.2015 - 21:00
fonte
0

Credo che questo errore di connessione alla sessione utente possa essere superato includendo le informazioni del socket TCP come variabile durante la creazione del cookie. ma, poiché un cookie è solo una coppia chiave / valore, tutto dipende dall'implementazione specifica sul server.

    
risposta data 06.07.2015 - 17:21
fonte

Leggi altre domande sui tag