Voglio sapere se ha sempre senso hash un lato client di password e rehash di nuovo sul back-end. Non l'ho mai visto prima, il che mi fa sospettare se aggiunga davvero sicurezza. Ecco le minacce che sto considerando:
- L'operatore del server potrebbe essere malvagio e controlla le password in chiaro in arrivo. Se le password in entrata vengono utilizzate altrove, l'operatore malvagio ottiene un vantaggio nei confronti dell'utente. Supponiamo che l'utente sia in grado di verificare come vengono inviate le password dal client, quindi il malvagio server non può facilmente backdoor l'accesso del client.
- L'algoritmo di hashing lato client è implementato male. Forse abbiamo una API aperta e uno sviluppatore implementa un'implementazione di hashing errata o le iterazioni sono impostate piuttosto basse per motivi di prestazioni. Il server viene violato e gli hash insicuri sono trapelati.
Implementazione potenziale:
- Il client richiede al server / alger / iterazione pubblicamente noto a un utente. Senza questo non possiamo mai "aggiornare" l'hash della password.
- Client hash la password e invia una richiesta di autenticazione
- Il server accetta l'hash. Hash di nuovo nello stesso modo in cui avrebbe hash qualsiasi password in chiaro. Controlla se l'hash corrisponde.
Casi di utilizzo:
- Fornire fiducia agli utenti.
- I servizi che crittografano tutto il lato client dei dati e che desiderano rivendicare i dati del cliente non sono accessibili all'operatore. (Gestione password, servizi di sincronizzazione file, provider di posta elettronica, ecc.)
- Difendersi da possibilità future come interventi governativi o ricatti. Questo è utile solo per conoscere le password mentre arrivano e sperare che l'utente riutilizzi le password.