Ha senso di sicurezza per hash password sul client fine

Question

Se si dovesse eseguire una hash di una password utente prima di inviarlo attraverso la linea e di lasciarlo in testo normale in memoria, ciò migliorerebbe la sicurezza dell'applicazione?

Suppongo che questo riduca una piccola parte delle vulnerabilità proteggendo i dati memorizzati nella memoria del client. Ma se davvero siamo preoccupati per qualcuno che sta leggendo la memoria del cliente ci sono probabilmente problemi più grandi che non possiamo affrontare.

C'è qualcosa che non sembra giusto per l'hashing sulla parte client.

L'hashing della password sul client è una pratica comune? Ci sono altri vantaggi o svantaggi nel farlo?

MODIFICA: Dato il canale di comunicazione è sicuro (SSL). In quali condizioni sarebbe accettabile e utile utilizzare un simile approccio. Lo sto chiedendo perché è stato suggerito da un "professionista della sicurezza" che utilizzo questo schema durante alcune funzioni applicative.

Answer 1

No.

Quando il client invia qualcosa, se si tratta di P o H(P) o H(H(P)) chi intercetta questo può semplicemente inviare nuovamente la stessa identica cosa, rendendo così qualsiasi funzione come questo equivale a utilizzare il password direttamente

Ecco perché è necessario utilizzare un nonce; Il server può fornire alcuni rifiuti casuali k e il client calcolerà H(P,k) e lo invierà al server. HMAC è un'implementazione popolare di questo metodo.

Se il server mai accetta lo stesso nonce due volte, questo è sicuro contro un attacco di riproduzione.

Answer 2

Accertati solo di inviare la password tramite un canale protetto (SSL). Se il client può leggere una memoria privata dell'applicazione, molto probabilmente hanno problemi più grandi, come ad esempio un keylogger.

Answer 3

L'hash è identico alla password di un POV di sicurezza nello scenario che descrivi: se intercetto l'hash, non ho bisogno di conoscere la password, posso semplicemente inviare al server l'hash che ho intercettato.

Authentication protocols andare un po 'per evitare questo problema; la sicurezza è difficile, e la scelta migliore e l'implementazione di un protocollo ben compreso piuttosto che la rotazione sono le migliori.

Se il traffico sta andando oltre SSL, sei al sicuro dall'intercettazione e l'hashing ti dà un piccolo vantaggio in più.

Answer 4

L'invio di una password hash non migliorerà la sicurezza del tuo sito, come altri hanno fatto notare (da quando si accetta una password hash, tutto il cattivo ha bisogno di sapere è la versione hash). Inoltre non è molto sicuro, dal momento che il cattivo può caricare presumibilmente la tua pagina di accesso ed esaminare il javascript o Java distribuito.

Ciò che fa è impedire a qualcuno che guarda i pacchetti di essere in grado di estrarre una password, e che è moderatamente utile. Molte persone usano la stessa password su più siti (lo faccio per tutti tranne i siti con maggiore sicurezza), e quindi se riesci a ottenere una password da loro puoi accedere ad altri account su altri siti.

Impedisce inoltre che la password reale venga archiviata, anche temporaneamente, sul tuo sito e ciò potrebbe fornire un po 'di sicurezza in più se il tuo sito è compromesso.

Quindi, anche se considererei l'hashing lato utente potenzialmente una buona cosa, non vale la pena andare a molti altri problemi.

E, come altri hanno già detto, non tirare la propria sicurezza. Ci sono troppe cose che possono andare storte. Non li noterai quasi alla stessa velocità di un ragazzo cattivo praticato.

Answer 5

Sarebbe molto meglio se si usasse lo Secure Remote Password protocol (SRP). È stato progettato per questo.

Answer 6

No, l'hashing sul client non protegge la password 'completamente'. Quando si sceglie di cancellare la password sul client, il digest inviato al server diventa essenzialmente la password. Questo non è un problema di per sé se SSL è distribuito.

Tuttavia, questo schema finisce per creare più problemi di quanti ne risolva. Se il server dovesse confrontare l'hash inviato dal client con un hash memorizzato nel database senza eseguire ulteriori operazioni crittografiche (in particolare l'hashing dei dati di input), quindi la password viene memorizzata in chiaro per tutti gli scopi pratici. Chiunque abbia accesso all'hash memorizzato può inviarlo di nuovo al server e accedere agli account.

In termini semplici, se l'hash inviato (che è lo stesso dell'hash inviato) dovesse filtrare tramite qualsiasi altra vulnerabilità all'interno dell'applicazione (tramite SQL injection, ad esempio), l'applicazione ha una vulnerabilità in cui protegge le password inadeguatamente.

Se la vulnerabilità sottostante deve essere fissato, allora è necessario trattare l'hash presentata come una password in chiaro, che andrà poi hash (con un sale, preferibilmente) prima del confronto con un hash memorizzato.

Answer 7

L'hash sul lato client apre un altro enorme buco: è possibile esporre l'algoritmo di hashing. Non dici se questo è basato sul web (client = JavaScript) o thick-client, ma stai dando loro più informazioni. Dato che il canale è sicuro, non devi preoccuparti che la password del testo in chiaro venga sniffata.

Inoltre, se l'algoritmo di hashing richiede un sale, si espone il tuo sale, il che significa che se hanno mai avuto accesso al database, sarebbero in grado di decifrare ogni password.

Answer 8

Sì, dovresti.

IEEE ha avuto una violazione dei dati in cui 100K email e password sono state esposte da un weblog.

http://ieeelog.com/

Ovviamente, IEEE non dovrebbe hanno esposto il loro blog! Ma se avessero cancellato le password dal lato client, questo non sarebbe stato altrettanto grave.

Come afferma la prima risposta, è necessario utilizzare un nonce. Se si utilizza un nonce abbastanza lungo (ad esempio 128 bit), non è necessario preoccuparsi del riutilizzo, in quanto il server non richiederà mai lo stesso nonce due volte (presupponendo un CRNG correttamente seminato, ecc.).

Answer 9

Penso che abbia senso in una circostanza; non vuoi nemmeno conoscere la password in chiaro del client. Se si esegue l'hash sul lato client, quindi salt e iterativamente hash che hash nello stesso modo in cui si farebbe un testo normale pw. A parte questo, è piuttosto sciocco.

Answer 10

posso darvi diverso tipo di approccio Se non avete SSL si può hash della password sul lato client e di nuovo hash sul lato server utilizzando un altro metodo di hashing e memorizzarli sul database di e quando login utente con password fare lo stesso processo e abbinare la doppia password hash con gli hash memorizzati