Quando si utilizza un "token di autenticazione", la semplice presentazione di quel token da parte del client concede l'accesso (a condizione che il token sia ritenuto valido dal server). Se si archiviano i token "così come sono" nel database del server, un utente malintenzionato che potrebbe dare un'occhiata al proprio database imparerà immediatamente tutti i token, consentendogli di inviare richieste nel nome di tutti gli utenti per i quali esiste ancora un token valido nel database. Questo non va bene. Da qui la raccomandazione di memorizzare solo un hash del token di autenticazione.
Il consiglio su bcrypt per i token di autenticazione è errato. Bcrypt, come tutte le funzioni dedicate a hashing della password , si intende da utilizzare per password . Le password sono deboli; sono vulnerabili agli attacchi del dizionario. Per far fronte alla loro intrinseca debolezza, la funzione di hashing della password deve essere salata (per prevenire attacchi paralleli e tabelle precalcolate) e deve anche essere terribilmente lenta (attraverso un numero enorme se le iterazioni interne). Ciò rende le funzioni di hashing della password costose . Quindi non vuoi usare una funzione di hashing della password a meno che non ne abbia bisogno, ad es. per cancellare una password.
Un token di autenticazione non è una password; è un valore casuale che è stato generato e ricordato da un computer, senza alcun cervello umano coinvolto nel processo. Pertanto, se hai generato correttamente il token (almeno 128 bit, ottenuti da un PRNG crittograficamente protetto ), allora c'è nessuna necessità di sali o iterazioni; basta usare una semplice funzione di hash (anche MD5 andrebbe bene lì). Questo sarà più efficiente.
Per quanto riguarda l'utilizzo di un token di autenticazione casuale al posto di login + password per ogni richiesta, ci sono due ragioni principali per questo:
-
Prestazioni: come spiegato sopra, un token di autenticazione può essere verificato in sicurezza con un semplice hash, che sarà molto più efficiente di una pesante chiamata bcrypt. Vuoi mantenere i tuoi preziosi cicli della CPU per quando sono veramente utili, in particolare quando si applica bcrypt a una vera e propria password gestita dall'uomo.
-
Archiviazione lato client: il token di autenticazione verrà memorizzato sul client come valore del cookie. Se il login e la password vengono restituiti ad ogni richiesta, vengono memorizzati come cookie sul client. Le persone si innervosiscono quando le loro password vengono scritte su file e tale archiviazione non è equivalente (dal punto di vista della sicurezza) all'archiviazione di un token di autenticazione, perché l'utente umano ha l'abitudine (cattiva) di riutilizzare le proprie password per più sistemi, mentre i token di autenticazione sono intrinsecamente specifici del server.