Considera il seguente flusso di autenticazione.
- L'utente invia il proprio nome utente e una password crittografata RSA
- La password viene decifrata e sottoposta a hash con un salt (e possibilmente un pepe) e verificata
- Se l'hash corrisponde a un GUID viene generato come token e il token riceve un TTL e una data di scadenza e viene restituito all'utente. Inoltre, l'indirizzo IP del chiamante viene salvato
- Tale nome utente con il token viene quindi utilizzato per qualsiasi interazione futura con il DB (ogni volta che viene utilizzato il token la sua data di scadenza viene estesa). Solo l'IP che ha creato il token può utilizzare il token.
- L'accesso da un nuovo IP deve essere prima verificato utilizzando una seconda forma di autenticazione (ad esempio un codice inviato all'e-mail dell'utente)
Quali sono i problemi di sicurezza di un tale sistema di autenticazione?
Mi sembra che un tale sistema utilizzi i token in modo errato, poiché da quello che ho letto sembra che lo scopo dei token sia l'autorizzazione e non l'autenticazione. Ho l'impressione che l'unico vantaggio dell'utilizzo del token sia che una password può essere utilizzata per accedere in qualsiasi momento e il token alla fine scade, quindi se diventa scaduto alla fine diventerà inutile.
Una delle mie preoccupazioni sarebbe se qualcuno ascolta costantemente e intercetta il token che significherebbe essenzialmente che potrebbero usarlo per accedere al database ogni volta che c'è un token attivo (e può aggiornare indefinitamente un token per mantenerlo attivo). Questo è il motivo per cui l'indirizzo IP verrà memorizzato e l'accesso verrà dato solo a quell'indirizzo IP. Ciò minimizzerebbe il rischio che il token venga utilizzato in modo improprio.
In generale un token non può essere restituito crittografato, come può qualcuno impedire che un token venga intercettato e utilizzato in modo improprio?