hashing lato client / salatura su HTTPS

Question

Mi chiedo quali sono i problemi seri sono con la seguente configurazione:

Nome utente / password di sistema di login Javascript / Ajax richiede il valore del sale dal server (abbiamo stabilito nelle precedenti domande di sale non è un valore segreto) Javascript preforme uno SHA1 (o meno) della password e il sale. Javascript / Ajax tornare l'hash al server Il server si applica un altro sale / hash on-top della quella inviata tramite la tecnologia AJAX.

Le transazioni sono su HTTPS.

Sono preoccupato per i problemi che possono esistere, ma non riesce a convincere me stesso che questo è così male di una messa a punto. Si supponga che tutti gli utenti hanno bisogno del Javascript abilitato, come jQuery è molto utilizzato sul sito. E 'fondamentalmente il tentativo di aggiungere un ulteriore livello di sicurezza per il testo semplice di una password.

Answer 1

Tutto ciò che lo sforzo di passare sali e gli hash tra il client e il server è già incorporato nel / protocollo sottostante HTTPS SSL. Sarei molto sorpreso se uno strato di sicurezza in javascript sta per aiutare molto. Mi consiglia di mantenere le cose semplici e l'uso in chiaro su SSL sul lato client. Preoccuparsi di crittografia sul lato server.

Answer 2

Come sempre:. Essere molto attenti sulla progettazione di protocolli crittografici te

Ma questo detto, posso vedere il vantaggio nello schema. E ' proteggere la password viene rivelato attraverso un man-in-the-middle-attacco ed è assicurarsi che il server non vede mai la password attuale, impedendo così un po' dentro attacchi. D'altra parte non protegge contro l'uomo-in-the-browser, la pesca, ecc.

Si potrebbe desiderare di leggere RFC 2617 su autenticazione di accesso HTTP Digest. Tale regime è simile a quello che si propone.

Answer 3

Questo non aggiunge alcuna protezione aggiuntiva. Il codice JavaScript è presente nel client, in modo che l'algoritmo di hash è noto. Si guadagna nulla dal fare un hash lato client in questo caso.

Inoltre, non c'è alcun motivo per cui il cliente dovrebbe conoscere il sale di hashing. In realtà dovrebbe essere un valore segreto, soprattutto se si sta utilizzando un sale comune.

Answer 4

Non stai guadagnando nulla. Non ha senso per un sale se Joe Public può vedere facendo clic su Visualizza> Sorgente, e la vecchia massima mai la fidarsi input del client vale doppio per l'hashing delle password.

Se si vuole veramente aumentare la sicurezza, utilizzare un hash basato SHA-2 (SHA-224/256/384/512), come SHA-1 ha le potenziali vulnerabilità. Il NIST non è più raccomanda SHA-1 per le applicazioni che sono vulnerabili ad attacchi di collisione (come gli hash delle password).

Answer 5

Sarò al 100% d'accordo con la risposta accettata e dire che in nessun caso la password originale mai mai mai lasciare il cliente. Dovrebbe sempre essere salato e hashing. Sempre, senza eccezioni.

Due motivi ... . Il cliente non deve essere affidamento che tutti i componenti del server e le reti interne sono TSL. E 'abbastanza comune per l'endpoint TSL di essere un bilanciamento del carico proxy inverso, che comunica con i server di applicazioni utilizzando testo in chiaro perché DevOps non possono essere disturbati per generare certs server per tutti i loro server interni.

. Molti utenti sono patologicamente inclini a utilizzare una password comune per tutti i loro servizi. Il fatto che un server ha password in chiaro, anche se solo nella memoria, lo rende un bersaglio attraente per attacchi esterni.