Sto lavorando per estendere un'applicazione web con un'API RESTful basata su HTTP. Abbiamo deciso di richiedere al cliente di fornire un token di autenticazione in ogni richiesta (invece di utilizzare sessioni o altri schemi di autenticazione multi-step come OAuth). Per esempio:.
POST /foo HTTP/1.1
Authorization: Bearer <authentication token>
...
Il token è una stringa opaca di caratteri per l'utente. Il token viene mostrato all'utente solo una volta. Un singolo utente può generare più token e associare diverse autorizzazioni e un nome descrittivo a ciascuno di essi. Ogni richiesta all'API viene registrata in un registro visibile dall'utente e ogni voce del registro è associata al token specifico utilizzato per la richiesta.
Nella nostra attuale implementazione, archiviamo un'entità con i seguenti attributi nel database:
- UUID casuale (chiave primaria, utilizzato per fare riferimento al token dalle voci del registro)
- Token di autenticazione (indicizzato)
- Account utente e autorizzazioni associati
- Descrizione fornita dall'utente
- Revocato (booleano)
Abbiamo discusso le diverse implicazioni sulla sicurezza di questo approccio. Una minaccia, di cui vorrei discutere qui:
Cosa succede se un utente malintenzionato ottiene temporaneamente l'accesso in lettura al database?
Chiaramente, la memorizzazione dei token di autenticazione li rende vulnerabili. Dopo aver letto il database, un utente malintenzionato può utilizzare uno dei token non revocati per accedere all'API. Abbiamo pensato di proteggere i token memorizzati nel database da una tale minaccia.
Quali approcci (e possibilmente algoritmi o protocolli applicabili) possono essere utilizzati per proteggere i token di autenticazione in uno scenario del genere?
Stavo pensando di eseguire l'hashing del token e utilizzare il risultato di tale ricerca per trovare la voce giusta nel database.