Scelta di un algoritmo ID sessione per una relazione client-server

Il concetto base di un identificativo di sessione è che si tratta di un nome segreto di breve durata per la sessione , una relazione dinamica che è sotto il controllo del server (cioè sotto il controllo del tuo codice ). Spetta a te decidere quando avviare e interrompere le sessioni. Le due caratteristiche di sicurezza di un algoritmo di generazione dell'identificativo di sessione riuscito sono:

1. Nessuna due sessioni distinte deve avere lo stesso identificatore, con una schiacciante probabilità.
2. Non dovrebbe essere computazionalmente fattibile "colpire" un identificatore di sessione quando si provano a caso, con probabilità non trascurabile.

Queste due proprietà sono ottenute con un ID di sessione casuale di almeno, diciamo, 16 byte (32 caratteri con rappresentazione esadecimale), a condizione che il generatore sia PRNG crittograficamente strong ( /dev/urandom su sistemi Unix-like, CryptGenRandom() su Windows / Win32, RNGCryptoServiceProvider su .NET ...). Poiché memorizzi anche l'ID di sessione sul lato del server di database, potresti controllare i duplicati, e probabilmente il tuo database lo farà probabilmente per te (vorrai che questo ID sia una chiave di indice), ma è ancora tempo sprecato perché la probabilità è molto bassa. Considera che ogni volta che esci da casa, scommetti sull'idea che non sarai colpito da un fulmine. Essere uccisi da un fulmine ha una probabilità di circa 3 * 10 ^-10 al giorno ( really ) . Questo è un rischio che minaccia la vita , la tua vita, per essere precisi. Eppure respingi quel rischio, senza mai pensarci. Che senso ha quindi preoccuparsi delle collisioni con ID di sessione che sono milioni di volte meno probabili e non ucciderebbero nessuno se si fossero verificati?

Non ha molto senso lanciare una funzione hash in più nella cosa. La casualità applicata correttamente ti darà già tutta l'unicità di cui hai bisogno. La complessità aggiunta può solo portare a punti di debolezza aggiuntivi.

Le funzioni crittografiche sono rilevanti in uno scenario in cui non si desidera solo avere una sessione, ma si desidera anche evitare qualsiasi costo di archiviazione basato sul server; diciamo, non hai database sul server. Questo tipo di scaricamento dello stato richiede un MAC ed eventualmente la crittografia (vedere questa risposta per alcuni dettagli).

Gli ID di sessione devono essere di forza crittografica casuali e unici. Se un utente malintenzionato può indovinare un ID sessione legittimo, può impersonare quell'utente.

L'opzione 1 è la soluzione migliore, se usi un CSPRNG corretto e non qualcosa come rand() da una libreria standard. Usare qualcosa come l'opzione 2 non è così sicuro, dal momento che i nomi e gli orari degli utenti sono facilmente indovinati o forzati.

Dai un'occhiata al codice del generatore di ID sessione di PHP funziona, e vedrai che una funzione di hash viene utilizzata per combinare l'indirizzo IP del client, l'ora corrente (secondi e microsecondi) e alcuni valori del RNG di Linear Congruence Generator (LGC) di PHP come base di riferimento. Se è disponibile una sorgente casuale specifica per OS, un'ulteriore entropia viene mescolata nell'ID da quella funzione. Questo fornisce un margine di sicurezza ragionevole se non è disponibile una fonte di entropia strong, ma fornisce una sicurezza elevata se lo è.

Gli identificativi di sessione devono essere firmati, quindi non devi preoccuparti di persone che cercano di indovinare l'id di sessione.

Controlla anche le collisioni per assicurarti di non aver già dato quell'identificatore.