Perché i token di accesso generati per le API sono molto più lunghi delle password?

Ci sono diversi motivi per questo.

Una ragione è che le password memorabili sono troppo brevi per il livello di sicurezza previsto. Diversi metodi sono utilizzati per mitigare questo problema, ma sarebbe problematico applicarli ai token di accesso:

• Alcuni servizi richiedono un secondo fattore di autenticazione . I token di accesso sono pensati per essere utilizzati senza l'intervento dell'utente, quindi la maggior parte delle altre forme di autenticazione sono fuori (potrebbero essere inapplicabili, ad esempio la biometria, altrimenti comporterebbero solo un secondo token di accesso).
• I servizi online proteggono dagli attacchi brute-force imponendo un ritardo tra i tentativi di autenticazione. Questo è problematico perché può bloccare l'utente legittimo e perché è un onere aggiuntivo per l'implementazione.
• L'archiviazione della password utilizza hash lenti . Questo costa molto tempo per la CPU. Se un token di accesso abbastanza lungo deve essere tenuto segreto e conservato in forma di hash, non è necessaria alcuna precauzione speciale. Allo stesso modo, se una chiave deriva da un token di accesso.

Un altro motivo è che la lunghezza dei token di accesso è in genere decisa dall'autore di un protocollo o di una libreria, non dall'autore dei servizi che li utilizzano. Il costo di rendere più lungo un token di accesso è generalmente marginale. Quindi la lunghezza è impostata su qualcosa che offre il livello di sicurezza più alto richiesto da chiunque. Stai confrontando la lunghezza del token di accesso con la lunghezza della password minima , ma un confronto più adatto sarebbe con la lunghezza massima della password.

Alcuni servizi utilizzano i token di accesso indipendentemente dagli account (cioè come cookie sessio piuttosto che come parametro di autenticazione combinato con un parametro di identificazione). Possono anche esserci molti token di accesso per un singolo account con diversi privilegi. Quindi il token di accesso deve avere più entropia per mantenere la probabilità di collisioni infinitesimali.

Molto semplicemente, il token non è progettato per essere memorizzato in modo che possa essere lungo quanto vogliono. Una password è limitata in lunghezza a ciò che una persona può praticamente richiamare in modo affidabile dopo un breve periodo di memorizzazione. Questo lo limita a 7-10 caratteri per la maggior parte delle persone. Il token è progettato per essere copiato / incollato, solo una volta (dato che è un'applicazione specifica) quindi non c'è assolutamente nessuna penalità per essere lunghi e la grande lunghezza gli permette di essere sia sicuro che unico (cioè il token può avere abbastanza embedded informazioni da legare a un account specifico).

Suppongo che una domanda più precisa sarebbe, perché le password non sono più lunghe; -)

Se devi memorizzare relativamente password brevi , devi adottare alcune precauzioni:

1. Salare con un sale abbastanza lungo per prevenire gli attacchi del tavolo arcobaleno.
2. Allungamento delle chiavi in modo che il calcolo abbia bisogno di un po 'di tempo, per ostacolare la forzatura bruta.

Dall'altro lato, se il token è lungo è sufficiente archiviare solo un SHA-256 semplice senza alcuno svantaggio sulla sicurezza. Questi sono i vantaggi:

1. Non c'è bisogno di salatura. A differenza delle password salate, è possibile cercare gli hash dei token in un database. Quindi se hai un token puoi rifarlo nuovamente e verificare con una query SQL se il token è valido.
2. Il calcolo è veloce e leggero sulla CPU dei server. Mentre avevamo bisogno di un sacco di potenza della cpu per le password hash a causa dello stiramento delle chiavi, l'hashing del token è velocissimo.

Nel caso di un'applicazione che ho scritto di recente, il token di accesso è una stringa crittografata simmetricamente del modulo

nonce=123456789;userid=123;username=bob;login_expires=12345679;...

La stringa crittografata è il cookie ed è piuttosto lunga. Decifrare è veloce e, supponendo che nessuno abbia rubato la chiave segreta dal server, i dati sono autentici.

I token sono utilizzati per accedere alle API a livello di programmazione; le password vengono utilizzate dagli utenti che le digitano.

La forzatura bruta delle password è impedita da strategie come la suddivisione della digitazione di nome utente e password in due pagine diverse, aggiunta di campi di input secondari come captcha e forzatura di un periodo di attesa (o disabilitazione di userid) dopo un certo numero di tentativi falliti .

Nel frattempo, i token vengono utilizzati senza tutti questi meccanismi e devono resistere ai tentativi di accesso all'API eseguiti a piena velocità. Pertanto, per evitare che le forzature brute debbano essere molto più lunghe.

Quindi, in altre parole, una breve password più strategie difensive ti danno la stessa sicurezza di un token lungo.