Utilizzo dei dati crittografati nella chiave di sessione anziché in modo casuale

Question

Utilizzo dei dati crittografati nella chiave di sessione anziché in modo casuale

#1 da (0 voti)

0

Sto scrivendo un'applicazione orientata al servizio (REST) che è (quasi) totalmente priva di stato: può autenticare con le chiavi API, ma per l'interfaccia utente web utilizza la sessione in cui non memorizza altro che un ID utente (int) autenticato. L'ID sessione viene generato in modo casuale, come è normale vedere, gli ID utente non vengono mai esposti agli utenti poiché gli utenti fanno sempre riferimento al loro nome utente

Ecco l'idea che ho ricevuto. Cosa succede se invece di assegnare un ID di sessione casuale lo genererei nel seguente modo:

N1 byte casuali che non includono flag byte + flag byte + user ID + flag byte + N2 byte casuali;

o in altre parole, N byte casuali contenenti un ID scansionabile da qualche parte all'interno, tutto crittografato con la chiave segreta del server. È anche possibile utilizzare l'IP del client come parte della stringa o come IV, per mitigare il dirottamento di sessione.

Il vantaggio di questo approccio è che la necessità della sessione è completamente eliminata, e per questioni di scalabilità è richiesto solo che tutti i nodi utilizzino la stessa chiave segreta (non è richiesta neanche la replica della sessione). Per quanto riguarda le prestazioni, non sono sicuro che la decrittografia in memoria (diciamo, AES a 128 bit) sarebbe più veloce o più lenta della lettura dei dati di sessione dal disco e la potatura di volta in volta. L'unico vettore di attacco che mi viene in mente è l'attaccante che crea due account in una riga (in modo che gli ID siano sequenziali) e bruteforcing i loro due ID di sessione per ottenere la chiave segreta (che, credo, non sarebbe fattibile se è effettivamente lunga) .

Quello che voglio chiedere è:

Cosa ne pensi della sicurezza di tale approccio? (Sono preoccupato dal momento che le uniche raccomandazioni che ho visto fino ad ora sono "usare random random per gli ID di sessione" e non leggere mai su tale approccio ID di sessione criptato - ma potrebbero essere solo le persone che amano davvero usare la sessione per archiviare i dati lì) ;
Quali sono i possibili modi di criptoanalisi oltre a quelli descritti?
Quali sono i lati negativi, oltre l'ID sessione possibilmente lungo?
È un approccio noto (allora dove è documentato?)

authentication session-management

posta Actine 18.05.2014 - 20:56

fonte

1 risposta

Leggi altre domande sui tag authentication session-management

Approccio "inverso" alla generazione di una sola volta Determinazione dell'accuratezza di un sistema biometrico

score 0 · Accepted Answer

La crittografia è lo strumento sbagliato, perché è necessario impedire agli utenti di modificare i dati della sessione, non di leggerli. L'ID utente non è un segreto, ma sarebbe un disastro se le persone potessero semplicemente cambiarlo in qualcosa che vogliono.

In altre parole, è necessario applicare l'integrità e l'autenticità dei dati della sessione. La crittografia in genere non può farlo. Quello che vuoi è un HMAC, e framework come Ruby on Rails infatti adotta questo approccio .

Tuttavia, un HMAC è molto più difficile da ottenere rispetto a un semplice ID casuale, e le sessioni sul lato client hanno un paio di problemi inerenti. Ad esempio, se la tua chiave di sessione è trapelata, chiunque può falsificare qualsiasi sessione. Non puoi semplicemente terminare una sessione. Infine, le sessioni sul lato client sono vulnerabili agli attacchi di riproduzione, ovvero l'utente può ripristinare le modifiche apportate ai dati della sessione semplicemente utilizzando il cookie precedente.