Gestione dei token di sessione quando l'IP di un utente cambia con estrema frequenza

2

Il mio servizio web è un'applicazione a pagina singola basata su API. Una volta che l'utente effettua il login, gli viene assegnato un token temporaneo da utilizzare per il resto della sessione, che viene inviato insieme a ciascuna richiesta API. Il token è ovviamente legato all'indirizzo IP che ha eseguito la richiesta di accesso. Ciò significa che anche se una terza parte riesce in qualche modo a catturare un token nonostante TLS, probabilmente non potrebbero usarla e non sarebbe utilizzabile da nessuno dopo che la sessione corrente è terminata.

Ma di recente mi sono imbattuto in un utente il cui indirizzo IP cambia con estrema frequenza (con frequenza ogni 30 minuti), causandogli spesso la necessità di ripetere l'accesso durante l'utilizzo del servizio. La modifica dell'indirizzo è causata dall'accesso al dormitorio di un campus che ricicla un pool di indirizzi IP molto limitato che l'utente finale, naturalmente, non ha alcun controllo.

Come posso riconciliarmi mantenendo la sicurezza della mia attuale configurazione, senza tuttavia causare problemi agli utenti in questa situazione? Il miglior "middle-ground" che ho ottenuto finora è quello di allentare il requisito IP affinché corrisponda solo al primo ottetto dell'indirizzo, ma è tutt'altro che ideale.

    
posta PhonicUK 04.02.2016 - 18:40
fonte

1 risposta

4

Sono propenso a dire che il bit sulla connessione del token di sessione all'indirizzo IP di origine è dannoso e dovrebbe essere rimosso.

Tale legatura viene spesso indicata come "buona per la sicurezza", ma esattamente perché è vantaggioso per la sicurezza raramente viene spiegato. È simile, in questo senso, alla diffusa raccomandazione di cambiare le password regolarmente: una tradizione ben radicata, per ragioni che nessuno ricorda abbastanza e con effetti collaterali tossici.

Il motivo principale per cui i token di sessione devono essere associati a un indirizzo IP non impedisce il riutilizzo dopo il furto attraverso il livello TLS. Ammettiamolo: se un utente malintenzionato potrebbe sfondare il TLS, un filtro sull'indirizzo IP non lo bloccherà neanche. Un tale aggressore potrebbe così tanto dirottare la connessione dell'utente che l'ha totalmente posseduto; il masquerading con il solito indirizzo IP dell'utente non scoraggerà tale aggressore.

La vera ragione per legare il token di sessione all'indirizzo IP è cercare di impedire a un utente di condividere il suo token con tutti i suoi amici. Questo è un problema commerciale, simile alla licenza del software. Normalmente è meglio affrontarlo con la sorveglianza: invece di bloccare i token di sessione che non provengono dallo stesso indirizzo IP come in precedenza, dovresti semplicemente loggare un tale tentativo (ma permetterlo comunque), e, in modo asincrono, indagare su situazioni in cui un token sembra essere utilizzato da troppi indirizzi IP sorgente.

    
risposta data 04.02.2016 - 19:38
fonte

Leggi altre domande sui tag