Vantaggi dell'hash delle password lato client in aggiunta ad altri meccanismi di sicurezza [duplicato]

Come è stato detto, inizia sicuramente leggendo questa domanda:

Hashing Passphrase in JavaScript lato client piuttosto che lato server - È valido?

Questo risponde alla prima serie di domande, credo. Tuttavia, penso che tu abbia una domanda aggiuntiva qui non ha risposto a questa domanda. Sembra che tu stia anche chiedendo "Che cosa succede se l'hashing è stato fatto dal browser e solo una password hash e salata è stata inviata al server o anche accessibile tramite javascript?".

Questo è un approccio completamente diverso all'autenticazione della password, e penso che abbia una serie di problemi, sia teorici che pratici.

Il problema pratico è semplice. Non esiste un modo realistico per arrivare da qui a lì. Se il sistema che stai proponendo fosse implementato in questo momento, letteralmente ogni singolo sito web si romperebbe. Non c'è nessuno che usa questo metodo perché questo metodo non esiste (sto affermando l'ovvio, scusa). Di conseguenza, puoi immaginare che i produttori di browser introducano gradualmente nuove funzionalità per far sì che succeda qualcosa del genere. Forse aggiungiamo un nuovo tipo di input: il tipo di input hashed ? Questo agisce come un input per la password, ma qualsiasi tentativo di ottenere il suo valore tramite javascript, o di inviare il suo valore a un server, produce solo una password con hash, con il suo sale. Tuttavia, una cosa del genere potrebbe mai essere realisticamente imposta allo sviluppatore web. Invece, dovrebbero scegliere di usarlo. Pertanto, questo non sarebbe "sicuro di default", ma piuttosto lo stesso "sicuro per scelta" che stai cercando di evitare con questo suggerimento. Di conseguenza, direi che, praticamente, non c'è modo di fare ciò che vuoi fare.

Se potessimo farlo accadere (magari con uno sforzo concertato per far sì che i browser dell'utente fossero aggiornati alla versione più recente, tempo per la migrazione dei siti web e quindi deprecare il vecchio campo password), sarebbe davvero d'aiuto? Sono dubbioso Il problema è che ora le procedure di accesso ai siti Web sono strettamente collegate al browser degli utenti. Non vedo che sta andando bene a lungo termine. Considerando il gran numero di problemi di compatibilità con i browser che le applicazioni web hanno già a che fare, dubito strongmente che l'accoppiamento della parte più importante della tua applicazione (il login) strettamente con il browser reale avvenga senza intoppi. Cosa succede quando l'algoritmo di hashing utilizzato dal browser è deprecato? In che modo il browser segnala al server che l'hash è cambiato perché l'algoritmo è cambiato? Cosa succede se un browser si è aggiornato all'algoritmo più recente (poiché l'algoritmo precedente ha evidenziato punti deboli), ma l'utente utilizza un altro browser che non è stato aggiornato?

Posso prevedere qualcosa di simile causando molti più problemi di quanti ne risolva.

Inoltre penso che questo manchi piuttosto del quadro generale. L'intero motivo per cui saltiamo e abbiamo cancellato le password è di proteggere l'utente dalle perdite perché così tante persone riutilizzano le password attraverso i siti. Tuttavia, se avremo intenzione di implementare soluzioni basate su browser per ridurre al minimo l'impatto di questo problema, sono sicuro che riusciremo a trovare qualcos'altro insieme che sia sia più conveniente che più sicuro. Penso che tu stia usando lo strumento sbagliato per risolvere il problema sbagliato.

Oltre a @Sefa che fornisce già un'ottima lettura, c'è un vantaggio nel senso che se il server è malevolo e non sale + hash la tua password (o un amministratore intercetta il traffico) e sei abbastanza sciocco da usare il stessa password su molti siti, salatura e hashing della tua password lato client impedirà a un server malintenzionato di rubare la tua password su altri siti.

Oltre a questo scenario non riesco a pensare a nessun utilizzo dell'hash del lato client se combinato con TLS e con hashing strong sul lato server su un server affidabile.

Non so esattamente cosa intendi per "hashing della password sul lato client". Intendi semplicemente che sul lato client, prendi la tua normale password, aggiungi eventualmente sale ad essa e hash quella, per "inventare" una nuova password, che è poi la "vera password" utilizzata? O intendi: una sorta di prova a prova zero in un dialogo con il server che ha il vantaggio che anche se sei connesso al server sbagliato, non tradisci la tua password?

Nel primo caso, non riesco a vedere l'utilità originale rispetto a un gestore di password. Il sale oltre alla normale password è necessario, quindi invece di memorizzare il sale in un "gestore", perché non memorizzi una password casuale nello stesso gestore? E nella misura in cui il sale non ha entropia, non rende la tua password più sicura. L'entropia di una password non aumenta di hashing. Non riesco a vedere la distinzione tra l'uso di sali memorizzati e una password comune, o la memorizzazione di stringhe casuali in un gestore di password, sbloccato con detta password.

Il secondo caso è molto più interessante, ma è necessario che il server collabori perché diventa una prova a conoscenza zero della password.