Che tipo di hashing usare per memorizzare i token dell'API REST nel database?

Question

Che tipo di hashing usare per memorizzare i token dell'API REST nel database?

#1 da (8 voti)

7

Abbiamo un'API REST che comunica con un front-end mobile. Dopo aver inviato una sola password, il backend emetterà un token (stringa UUID v4 casuale) per l'app mobile da utilizzare come autenticazione nelle richieste successive. Il server memorizzerà una versione hash di questo token nel database con l'utente.

Vogliamo assicurarci che l'autenticazione del token impieghi il minor tempo possibile.

DOMANDA
Che tipo di hashing / crittografia è sufficiente per memorizzare i token nel database? Un hash veloce come SHA256 è abbastanza buono o dovremmo usare un hash lento come bcrypt? Se si utilizza SHA256, è necessario includere un salt, poiché il token unhashed originale è solo un UUID casuale da 16 byte?

api rest hash session-management sha256

posta maniciam 14.02.2017 - 01:42

fonte

1 risposta

Leggi altre domande sui tag api rest hash session-management sha256

Posso ottenere un virus dalla connessione a una rete WiFi? Chi nel Regno Unito posso segnalare se so che la società sta memorizzando la mia password in testo normale?

score 8 · Accepted Answer

TLDR; SHA256 è abbastanza buono

Per rispondere a questo abbiamo bisogno di guardare perché saltiamo, cancelliamo e usiamo più iterazioni dell'hash, in primo luogo;

Perché saltiamo? Per proteggere gli utenti che hanno entropia della password debole dall'avere la propria password incrinata (ad esempio, le tabelle arcobaleno o due utenti con la stessa password). Questo non è un problema perché UUID4 avrà 122 bit di entropia ¹.

Se volessimo creare una tabella arcobaleno di tutti i valori UUIDv4 che sono stati sottoposti all'hash SHA256 e potremmo fare 1 trilione di hash un secondo ². Ci vorrebbero 168,6 quadrilioni di anni per creare la tavola dell'arcobaleno. Quindi non dobbiamo preoccuparcene.
Perché abbiamo hash? per impedire che copie di testo in chiaro della password vengano archiviate. Questa sembra una buona idea. Non vuoi che qualcuno che possa leggere il tuo database ³ possa impersonare gli utenti.
Perché utilizziamo più iterazioni? per rallentare gli attacchi di forza bruta. Come accennato prima UUID4 avrà 122 bit di entropia. Il crack di questi hash è impossibile anche ad alta velocità.

[1] 128 bit - 6 bit che sono predeterminati

[2] Le attuali velocità di hashing più veloci sono concatenate continuamente, quindi non mi preoccuperò di provare a trovare la velocità più recente che sarà superata in pochi mesi.

[3] Potrebbe trattarsi di SQL Injection o di una copia trapelata da un backup o da un insider o altro.