Posso archiviare in modo sicuro e sicuro hash (sessionId) nei registri delle applicazioni?

3

Sto considerando di archiviare un hash dell'ID di sessione di un utente nei registri delle applicazioni su ogni richiesta. Ciò consentirebbe alle sessioni degli utenti di essere facilmente rintracciate alle azioni nei nostri registri.

Capisco che l'archiviazione di questo è un potenziale rischio per la sicurezza, che potrei essere disposto a considerare se il rischio è molto basso. Perché è un rischio? Se qualcuno che ha accesso ai log può capire come ottenere un ID di sessione, può essenzialmente rubare agli utenti la sessione e accedere come se fossero senza credenziali.

A tal fine, se dovessi farlo, qual è il modo migliore per farlo?

Ecco alcune cose che mi piacerebbe prendere in considerazione:

  • Quale algoritmo di hashing dovrei usare? Deve essere veloce.
  • Cosa dovrei fare? ID sessione + sale?
  • Quanto è rischioso? Dovrei proprio non farlo?

EDIT: sto considerando la possibilità di generare un GUID e di aggiungerlo a una sessione utente durante la creazione della sessione. Quindi, registrando questo invece. In questo modo sarebbe sempre unico per la durata delle sessioni. Il problema con questo è che aggiungerebbe più dati di sessione e richiederà più memoria di sessione per ogni utente. Con questo approccio non sarebbe richiesto alcun hashing e la sessione dell'utente potrebbe ancora essere tracciata in modo univoco.

    
posta Brad Parks 26.08.2015 - 16:47
fonte

1 risposta

5

Se l'identificativo di sessione viene scelto casualmente da uno spazio sufficientemente grande (qualcosa come 12 byte dovrebbe essere più che sufficiente) allora qualsiasi funzione di hash non invertibile (anche md5) sarà sicura, e non ci sarà bisogno di sale (tabelle arcobaleno di queste dimensioni sono irrealizzabili.

Per espandere, il problema quando si memorizza l'hash della password è che le password di solito hanno un'entropia molto bassa (a differenza dei token, come ad esempio l'id della sessione). Inoltre, non ti preoccupi delle altre proprietà della funzione hash in cui md5 considerava debole l'attacker non può influenzare il suo id della sessione per entrare in collisione con qualsiasi utente, e anche se lo fa, solo (nel migliore dei casi) ti confonderà studiando i log).

    
risposta data 26.08.2015 - 17:18
fonte

Leggi altre domande sui tag