Il lato server non di hashing password significa che un sito Web compromesso potrebbe lasciare le password vulnerabili?

La debolezza a cui alludi è reale. Un punto importante è che una volta che il server è stato compromesso, l'aggressore ha pochi incentivi a prendere le password che concedono l'accesso a quel server - è già sul posto. Tuttavia, gli utenti umani hanno l'abitudine di riutilizzare le password, e questo è un grosso problema, perché una password riutilizzata significa che i compromessi su un server tendono a "propagarsi", esattamente nel modo in cui spieghi: l'attaccante prende la password P per l'utente U e indovina (ahimè correttamente, il più delle volte) che lo stesso utente U avrà usato la stessa password su altri server.

L'hashing del client è una buona idea, ma ci sono dettagli :

• Qualunque sia il client che invia al server, sia esso la password stessa o la password con hash, concede l'accesso. È equivalente alla password . Se il server memorizza questi hash "così come sono" nel suo database, allora si trova nella stessa situazione di un server che memorizza le password in chiaro, e questo è male. Quindi, il server DEVE anche fare un po 'di hashing.

• L'hashing sul lato client si verifica solo se sul lato client è presente un codice che esegue l'hashing. In un contesto Web, ciò significa JavaScript. Sfortunatamente, JavaScript è scarso in implementazioni crittografiche; in particolare, è piuttosto lento, quindi l'hashing sul lato client non sarà in grado di utilizzare le numerose iterazioni che sono in genere necessarie per un buon hashing delle password (si veda questo per i dettagli). Inoltre, questo non funzionerebbe per i client senza JavaScript.

• Sempre in un contesto Web, l'hashing sul lato client, se si verifica, viene eseguito dal codice JavaScript inviato dal server . Se il server è sotto controllo ostile, allora può inviare JavaScript dannoso che finge di fare l'hashing, ma non lo fa. L'utente sarà nessuno più saggio. Pertanto, il problema di root non è risolto.

L'hashing lato client è solitamente previsto sotto il nome di "server relief", non per aumentare la sicurezza contro i server malvagi, ma per consentire al server di gestire molti utenti simultanei senza spendere tutta la CPU su un sacco di hash. JavaScript è quello che è, questo non è comunemente fatto oggigiorno.

Quindi ci sono due parti separate per questo.

In primo luogo, il server viene compromesso e in secondo luogo, l'invio di hash al server anziché le password.

Per la prima parte con il server compromesso, sì, l'hacker potrebbe fare praticamente ciò che vuole. Se possiedono il server, possono effettivamente ottenere i nomi utente e le password degli utenti che vengono passati al server. Questo è il motivo per cui i server devono essere temprati contro gli attacchi e aggiornati regolarmente in modo da offrire il minor numero possibile di superficie d'attacco.

Per la seconda parte, se il client ha pre-calcolato l'hash, allora quell'hash è diventato letteralmente la password. Se un utente malintenzionato dovesse aver rubato il database degli hash (ma non ha compromesso il server Web), non ha bisogno di trovare le password che si trasformano in quegli hash; può semplicemente inviare l'hash al server web e si autenticherà in quanto il server si aspetterebbe già un hash come input da confrontare con il suo database.

Probabilmente non sarai in grado di impedire la semplice modifica sul lato server del codice inviato ai client da eseguire se il tuo server è totalmente di proprietà.

Tuttavia, se questo fa parte di un pacchetto software preinstallato o pre-distribuito con componenti client e server distinti (questo potrebbe includere applicazioni Web con componenti scaricati che rimangono residenti sul sistema operativo client), l'hashing lato client potrebbe essere utile in la sensazione che, mentre l'autore dell'attacco può ancora usare quegli hash per l'autenticazione nel TUO database (o semplicemente reimpostare le password come menzionato in uno dei commenti), non hanno più facile accesso alla password in chiaro che verrebbe inviata al tuo server ( su SSL) per l'hashing salato e l'archiviazione del database.

Quindi, se un client utilizza la stessa password in più posizioni, fino a quando l'hash non è banalmente reversibile , il tuo particolare compromesso del server non ha più rivelato le credenziali che l'utente malintenzionato può utilizzare altrove . Ciò sarebbe migliorato con la salatura casuale sul lato client (in modo che non si finisca con lo stesso hash che lo stesso algoritmo genererebbe sempre per quel testo in chiaro).

Trovo che molte persone (in particolare nel regno di PHP ) fraintendono ciò che fa hashing. Ecco la metodologia

1. L'utente crea un account e invia un nome utente / password combo (sicuro su HTTPS, spero)
2. La password viene sottoposta a hashing sul server (con un valore salt saltuario) e memorizzata con lo username
3. L'utente ritorna più tardi e inserisce la sua password in testo semplice
4. Server trova l'hash memorizzato per il nome utente. Con $2y hash (BCRYPT) il costo e il sale sono memorizzati nella stessa stringa. Quindi usando lo stesso costo e sale, il server genera un hash usando la password fornita dall'utente (ricorda che gli hash sono a senso unico)
5. Con tutto uguale, se l'hash generato corrisponde all'hash memorizzato, possiamo autenticare l'utente

Supponendo che qualcuno stia hackerando il tuo server, i tuoi utenti sono protetti meglio perché il sale è casuale per ogni hash. Come tale, si dovrebbe forzare manualmente ogni password separatamente (la teoria alla base di ogni tipo di sicurezza è di aumentare il costo di fare qualcosa al punto in cui qualcuno non la tenterà). SHA1 e MD5, i già noti sistemi di hashing, erano quasi sempre generati senza sale, rendendoli sensibili non solo a eventuali punti deboli dell'hash stesso, ma agli attacchi di rainbow table (senza salt ogni SHA1 e MD5 è lo stesso per una determinata stringa) .

Non c'è davvero alcun modo di fare questo lato client perché

• Il cliente è nelle mani del nemico. Quindi dovresti inviare al client tutto ciò di cui hanno bisogno per generare l'hash (in particolare il sale) e poi farli passare l'hash.
• Come menzionato in un'altra risposta, a quel punto il loro hash diventa la password perché è quello che ti mandano. In altre parole, anche se potrei non sapere quale sia la password, stai ancora facendo un semplice paragone delle stringhe invece di generare un hash sicuro in modo che io possa intervenire

No, Ispeziona elemento o qualcosa di simile esiste sulla maggior parte dei browser, consentendo a chiunque di aggirare il codice lato client. Se un hacker ha avuto accesso al database, è possibile rimuovere il codice di hashing usando Inspect Element e inserire gli hash come password, o modificare la pagina per non cancellarla comunque. Che ne dici invece di uno script che arresta il server se rileva che una pagina è stata modificata da un hacker?