token di sessione crittografico vs token di sessione casuale memorizzato [duplicato]

Question

token di sessione crittografico vs token di sessione casuale memorizzato [duplicato]

#1 da (2 voti)

1

Sto creando un'API web e ho difficoltà a scegliere tra token di sessione crittografico e token di sessione casuale memorizzato per l'autenticazione dell'utente.

Vedo diversi pro e amp; contro per ciascuno:

token sessione casuale memorizzato (memorizza una coppia in scadenza {token: userId} in un db):
- veramente casuale, con un rischio di collisione trascurabile; un ulteriore controllo univoco può essere eseguito durante l'inserimento del database
- memorizzati in un database, il che porta a ridimensionare i costi, a ridurre i costi di manutenzione
- possono essere revocati
- nessun rischio di crittanalisi a condizione che venga utilizzata la funzione casuale corretta
token di sessione crittografico (usa un mix strongmente crittografato di "userId, expiryTime" con una chiave simmetrica comune memorizzata nel back-end)
- random ad ogni sessione, grazie al tempo di scadenza e amp; un nonce
- non è necessario memorizzarli (non è necessario effettuare chiamate di rete aggiuntive): la decodifica simmetrica del token di sessione sarà più veloce. Questo porta a un massiccio miglioramento dei costi e al loro devoto
- non possono essere revocati
- rischio di crittanalisi
- rischio di collisione trascurabile ma esistente che non può essere prevenuto
- rischio con la chiave master simmetrica

L'approccio più sicuro sembra il token di sessione casuale memorizzato, tuttavia i costi e l'amp; le questioni relative ai database di Devops mi stanno davvero facendo dubitare.

Qualsiasi aiuto sulle migliori pratiche e se il token di sessione crittografica sarebbe considerato a prova di proiettile dagli esperti di sicurezza? Forse un suggerimento di una soluzione più strong?

Il collegamento fornito riconosce ancora che entrambi vengono utilizzati - Mi chiedo se un esperto di sicurezza rifiuterà il token crittografico per un sito Web bancario? Dove disegna la linea?

authentication risk-management session-management token

posta user3684457 20.09.2015 - 17:50

fonte

1 risposta

Leggi altre domande sui tag authentication risk-management session-management token

Strani log delle attività di google gmail Alcuni tag sono preoccupati per l'analisi di html doc per xxs

score 2 · Accepted Answer

Parlando come consulente per la sicurezza, sì, vorrei assolutamente segnalare il secondo approccio come una vulnerabilità di sicurezza. Una chiave del genere è troppo rischiosa per un utente malintenzionato di trovare un modo per scaricare o altrimenti determinarlo, e una volta che lo fanno possono impersonare qualsiasi utente. Puoi renderlo più difficile attraverso una serie di trucchi, ma alla fine della giornata ti stai fidando del client per la gestione delle sessioni. Non farlo, anche quando le informazioni sono supposte essere opache al cliente. Se non altro, la revoca è di per sé un buon punto (specialmente se i token hanno una durata non banale).

Memorizzazione nella cache di piccole porzioni di dati, come un ID di sessione - > mappatura ID utente, può essere fatto abbastanza facilmente e con un sovraccarico minimo. L'aggiunta di nuovi mapping è relativamente rara: ogni sessione verrà utilizzata molte volte per ogni volta che ne viene creata una, quindi non è necessario ottimizzare per la creazione. Non ha necessariamente bisogno di essere ostinato a qualcosa; per un sito web bancario i tuoi token dovrebbero essere di brevissima durata! Per quanto riguarda "farlo bene", un token di lunghezza sicura (128 bit è buono) da un generatore di numeri casuali crittograficamente sicuro rende un token ID eccellente.