Per un progetto al lavoro attualmente sto implementando un webservice non troppo grande. Per motivi di apprendimento di qualcosa di nuovo, ho provato a crearlo come servizio REST, che ha quindi richiesto il problema dell'autenticazione. Alla fine ho optato per HTTP Basic Auth poiché ha il vantaggio di essere supportato praticamente da qualsiasi libreria HTTP, anche se ho dovuto implementare il lato server da solo.
Ieri un collega mi ha suggerito di inviare semplicemente la password con hash anziché il nome utente e la password in chiaro (eventualmente il servizio sarà accessibile solo tramite HTTPS, quindi ho considerato l'autenticazione di base come un problema di sicurezza, ma lasciamo da parte per ora ). Ma mi chiedevo cosa avrebbe effettivamente cambiato, per quanto riguarda la sicurezza.
L'invio della password hash significa fondamentalmente un hash di bcrypt poiché questo è ciò che memorizziamo nel database. Il che significa che prima dovrei inviare al cliente il fattore lavoro e il sale in modo che possano arrivare allo stesso hash che ho nel database. Ciò richiede un meccanismo di risposta alle sfide che è già molto più complicato da implementare.
Quindi c'è il punto che la password hash che il client invia per l'autenticazione funziona essenzialmente come una password in testo semplice, per quanto riguarda l'autenticazione; e potrebbe essere facilmente riprodotto, se qualcuno dovesse impossessarsene.
Quindi in pratica, quello che ho trovato:
- risolve inviando la password in modo semplice, simile a Digest, invece di Basic
- Non non risolve il problema del replay (Digest fa, a causa dell'uso di un nonce) di Basic
- Richiede l'hashing della password sul client con prestazioni meno prevedibili. Per esempio. gli smartphone probabilmente richiedono fattori di lavoro minori rispetto alle macchine desktop e i principali utilizzatori dell'API sarebbero smartphone e tablet. Quindi dovremmo ridurre la forza di bcrypt in quel caso.
- Sarebbe molto più complesso da implementare, sia nel client che nel server, a causa di uno schema di richiesta / risposta personalizzato e quindi più spazio per errori. Probabilmente va anche contro i principi REST.
Mi sono perso qualcosa? HTTPS risolve i problemi dell'autenticazione di base, per quanto ho capito e quindi lo schema personalizzato non risolve alcun problema reale, a parte forse la noia dello sviluppatore. Ma non sono esperto in questo.