Hashing User Passwords Client o lato server [duplicato]

Prima di tutto, l'hashing sul client è generalmente considerato inutile per le applicazioni web. Qualsiasi utente malintenzionato che sarebbe in grado di superare l'HTTPS e fare un attacco MITM sarebbe anche in grado di modificare il codice JavaScript, quindi invierà la password in testo semplice. Pertanto, c'è molto poco o nessun vantaggio dall'hashing sul lato client. L'unico vantaggio possibile è che si eviterà un errore simile a quello che sta attualmente passando Twitter in cui le password sono finite accidentalmente nei log.

È una storia diversa per le applicazioni native. Tuttavia, l'hashing semplice non aumenta considerevolmente la sicurezza. Esistono approcci di gran lunga migliori, come il metodo di autenticazione SCRAM . SCRAM consente di eseguire l'hashing della password sul lato client, tuttavia, l'HASH lato client non è memorizzato nel database, pertanto un utente malintenzionato che accede al database del server non sarebbe in grado di accedere utilizzando solo l'hash memorizzato lì.

Capire lo scopo dell'hash della password in questo contesto ti aiuterà a spiegare perché dovrebbe essere eseguito sul server e non sul client.

La password non viene sottoposta a hashing per offuscarla da un avversario che sta ascoltando la richiesta; questa particolare minaccia dovrebbe invece essere mitigata usando HTTPS. Invece, lo scopo è quello di impedire che la password sia banalmente recuperabile se il database viene violato. Se un utente malintenzionato scarica un database di password in chiaro, può immediatamente leggere e utilizzare tali password (che gli utenti potrebbero utilizzare anche su altri siti Web). Quando vengono sottoposti a hash (e salati), l'attaccante deve fare più lavoro per forzare l'input che ha generato l'hash.

Se si esegue l'hash lato client, l'hash diventa la password, quindi non è necessario craccarlo per accedere al sistema. Un utente malintenzionato che acquisisce l'hash potrebbe semplicemente inviarlo come password e ottenere l'accesso. Non correlato, questo tipo di attacco è possibile su sistemi Windows in un attacco pass-the-hash, in cui la compromissione di un hash su un sistema consente di utilizzarlo per l'autenticazione con altri sistemi.

Inoltre, la frase:

(I am under the impression that if you use a POST request, users/attackers cannot access parameters being sent to the server. Is this right

è falso. Una richiesta POST non impedisce l'accesso ai parametri; certo, non sono nell'URL come sarebbero i parametri GET, ma fanno ancora parte del corpo della richiesta. Senza utilizzare HTTPS, un utente malintenzionato potrebbe visualizzare o modificare i parametri in entrambi i casi.