È un token di sessione sufficiente per le applicazioni critiche

Questo troppo lungo per un commento alla risposta di Silvers, ma utilizza le informazioni dal link che ha postato e risponde in modo abbastanza specifico alla mia domanda.

Binding the Session ID to Other User Properties

With the goal of detecting (and, in some scenarios, protecting against) user misbehaviors and session hijacking, it is highly recommended to bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate. If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session.

Although these properties cannot be used by web applications to trustingly defend against session attacks, they significantly increase the web application detection (and protection) capabilities. However, a skilled attacker can bypass these controls by reusing the same IP address assigned to the victim user by sharing the same network (very common in NAT environments, like Wi-Fi hotspots) or by using the same outbound web proxy (very common in corporate environments), or by manually modifying his User-Agent to look exactly as the victim users does.

Questo evidenzia quale è il tipo di messaggio misto. Da un lato si suggerisce che le informazioni dell'utente siano memorizzate e controllate per segnalare chiaramente i tentativi di hacking, tuttavia è ammesso che un utente malintenzionato possa falsificare queste informazioni.

Quindi dovresti concludere se vuoi proteggerti da hacker esperti e chi non fa che questi controlli incrociati ti facciano sentire meglio non offra più protezione.

Se usi i cookie per memorizzare gli ID di sessione, assicurati che sia impostato su un cookie con l'attributo Secure e HttpOnly. Limita il più possibile gli attributi del dominio e del percorso. Assicurarsi che nessuna applicazione Web non attendibile sia ospitata in un dominio correlato in grado di avviare un attacco di fissazione della sessione. Impostare un tempo di scadenza ragionevole per la sessione. Offri tutte le tue pagine su HTTPS poiché il contenuto misto potrebbe perdere l'ID della sessione. Cerca di limitare le librerie JavaScript caricate esternamente per ridurre al minimo la superficie di attacco.

Alcuni server applicazioni come Tomcat consentono di utilizzare ID sessione SSL anziché ID sessione memorizzati nei cookie. Questi ID di sessione SSL sono protetti meglio ma dovresti essere in grado di condividere la sessione SSL su più server nel tuo caso.

È possibile trovare molti altri suggerimenti qui: Cheat Sheet della Session Management

EDIT:

Non funzionano su token vincenti come gli ID di sessione di un client tramite chiave pubblica-privata e firma. Leggi la bozza qui . Ci vorrà un po 'di tempo prima che venga adottato dai principali produttori di browser, ma per quanto riguarda il collegamento di un ID di sessione a un client, questo sembra risolvere tutti i problemi. Ovviamente ci sono alcuni overhead di generazione e firma delle chiavi e per farlo è necessario il supporto client.

Devi assicurarti che

• hai una informazione di autenticazione - il tuo token per esempio
• questa informazione di autenticazione non può essere indovinata - il token deve avere, tra l'altro, una buona entropia e atomicità (un token è generato indipendentemente dagli altri, in altre parole sapere che un token non ti aiuta a conoscere il prossimo)
• questa informazione di autenticazione non può essere violata durante il trasporto - usa HTTPS

se vuoi limitare ulteriormente chi può autenticarsi, usa i certificati lato client (poiché comunque utilizzerai HTTPS) - è probabile che scalino meglio del filtro IP.

Come dici, i token sono abbastanza buoni per Google e altri grandi giocatori. Sono quindi abbastanza buoni anche per me.

I token di sessione sono utili solo quando vengono trasmessi su un protocollo sicuro (come https:// ). I token di sessione senza un protocollo sicuro possono essere rubati facilmente.