Best practice per la generazione di token OAuth?

Mi rendo conto che la specifica OAuth non specifica nulla sull'origine del codice ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret o Verifier, ma sono curioso di sapere se esistono best practice per la creazione di token significativamente sicuri (in particolare Token / Combinazioni segrete).

Per come la vedo io, ci sono alcuni approcci per creare i token:

1. Usa solo byte casuali, memorizza nel DB associato al consumatore / utente
2. Hash alcuni dati specifici dell'utente / consumatore, archiviati nel DB associato al consumatore / utente
3. Crittografa i dati specifici dell'utente / consumatore

I vantaggi di (1) sono che il database è l'unica fonte di informazioni che sembra la più sicura. Sarebbe più difficile eseguire un attacco contro (2) o (3).

L'hashing dei dati reali (2) consentirebbe di rigenerare il token da dati presumibilmente già noti. Potrebbe non fornire alcun vantaggio a (1) poiché sarebbe comunque necessario archiviare / cercare. Maggiore utilizzo della CPU rispetto a (1).

La crittografia dei dati reali (3) consentirebbe la decrittografia per conoscere le informazioni. Ciò richiederebbe meno spazio di archiviazione e potenzialmente meno ricerche di (1) e (2), ma potenzialmente anche meno sicuro.

Ci sono altri approcci / vantaggi / svantaggi che dovrebbero essere considerati?

EDIT: un'altra considerazione è che DEVE esserci una sorta di valore casuale nei token in quanto deve esistere la possibilità di scadere e riemettere nuovi token, quindi non deve essere composto solo da dati reali.

Domande da seguire :

Esiste una lunghezza minima del token per garantire una protezione crittografica significativa? A quanto ho capito, Token Secrets più lunghi creerebbe firme più sicure. Questa comprensione è corretta?

Ci sono vantaggi nell'usare una particolare codifica rispetto a un'altra dal punto di vista dell'hashing? Ad esempio, vedo molte API che utilizzano codifiche esadecimali (ad esempio stringhe GUID). Nell'algoritmo di firma OAuth, il token viene utilizzato come stringa. Con una stringa esadecimale, il set di caratteri disponibile sarebbe molto più piccolo (più prevedibile) rispetto ad una codifica Base64. Mi sembra che per due stringhe di uguale lunghezza, quella con il set di caratteri più grande avrebbe una distribuzione hash migliore / più ampia. Questo mi sembra che migliorerebbe la sicurezza. Questa ipotesi è corretta?

La specifica OAuth solleva proprio questo problema in 11.10 Entropy of Secrets .

OAuth non dice nulla sul token tranne che ha un segreto associato ad esso. Quindi tutti gli schemi che hai menzionato funzionerebbero. Il nostro token si è evoluto man mano che i siti si ingrandivano. Ecco le versioni che abbiamo usato prima,

1. Il nostro primo token è un BLOB crittografato con nome utente, token segreto e scadenza, ecc. Il problema è che non possiamo revocare i token senza alcun record sull'host.

2. Quindi l'abbiamo cambiato per memorizzare tutto nel database e il token è semplicemente un numero casuale utilizzato come chiave per il database. Ha un indice del nome utente, quindi è facile elencare tutti i token per un utente e revocarlo.

3. Abbiamo poche attività di hacking. Con un numero casuale, dobbiamo andare al database per sapere se il token è valido. Quindi siamo tornati di nuovo al BLOB crittografato. Questa volta, il token contiene solo il valore crittografato della chiave e della scadenza. Quindi possiamo rilevare token non validi o scaduti senza andare al database.

Alcuni dettagli di implementazione che potrebbero aiutarti,

1. Aggiungi una versione nel token in modo da poter cambiare il formato del token senza rompere quelli esistenti. Tutti i nostri token hanno il primo byte come versione.
2. Utilizza la versione URL-safe di Base64 per codificare il BLOB in modo da non dover affrontare i problemi di codifica URL, il che rende il debug più difficile con la firma OAuth, perché potresti vedere una stringa di base con codifica tripla.