La differenza di sicurezza sarà principalmente nei dettagli di implementazione. Fondamentalmente entrambi gli approcci sono gli stessi: si memorizza un blob di dati che è privo di significato per il cliente sul client per conservare uno stato tra le richieste. La differenza è che i cookie di identificazione di sessione sono di per sé privi di significato perché non rappresentano alcuna informazione significativa, mentre il cookie crittografato non ha senso perché il client non possiede la capacità di decrittografare i dati.
I cookie crittografati sono fondamentalmente più complessi: hanno dimensioni maggiori, richiedono un algoritmo complesso, richiedono che l'algoritmo sia correttamente implementato, contengano dati reali e quindi valgano l'attacco, richiedono la gestione di un chiave segreta. Sono anche più difficili da revocare a causa della loro natura decentralizzata.
I cookie di sessione id sono semplici: un ID casuale senza senso che si riferisce semplicemente a dati memorizzati altrove. L'unica vulnerabilità * è l'indovinabilità, che è abbastanza facile da prevenire aumentando la lunghezza e gli ID rotanti e in scadenza. Non ho idea del perché archiviare id / dati di sessione in un database sarebbe una cattiva idea in alcun modo; finché il database è sicuro, non c'è nessun problema lì. Se il tuo archivio dati è soggetto ad attacchi, hai problemi più grandi di quelli in cui sono archiviati i tuoi dati di sessione.
(* Oltre al dirottamento totale, che è la stessa vulnerabilità per tutti i cookie, e difetti specifici dell'implementazione come l'accettazione di ID di sessione indefiniti ecc.)
Dato questo, è necessario decidere se l'aumento della superficie di attacco dei cookie crittografati vale i vantaggi dei server senza stato e se si è sicuri dell'implementazione della crittografia. Per un'elevata scalabilità, vorrei esaminarlo seriamente, per i servizi su piccola scala lo terrei il più semplice possibile.