Hashing lato client per ridurre il valore dell'euristica per indovinare la password

Sulla base della teoria delle password standard, questo non dovrebbe funzionare in quanto dobbiamo supporre che il metodo di generazione della password sia noto.

Credo che quello che stai chiedendo sia questo, correggimi se sbaglio.

Comprensione del metodo standard.

Utente 1 - (inviato) password1 - > (memorizzato) e38ad214943daad1d64c102faec29de4afe9da3d

Utente 2 - (inviato) Di # aKHn! @ - > (memorizzato) 9187b4dc0f7c7231334546a86984060233304c5e

L'attacco del dizionario sugli hash memorizzati recupera le password inviate correttamente?

Quello che vuoi fare è questo.

Utente 1 - (lato client) password1 - > (inviato) e38ad214943daad1d64c102faec29de4afe9da3d - > (memorizzato) f8fde4f28c22e1a5a6201b6cce363477940cde50

Utente 2 - (lato client) Di # aKHn! @ - > (inviato) 9187b4dc0f7c7231334546a86984060233304c5e - > (memorizzato) a893a40df9fc73ab3a9711a34e943f13271170c1

Quindi la password per l'utente 1 è apparentemente strong come la password dell'utente 2, poiché entrambi inviano 40 stringhe alfanumeriche alfanumeriche come password e gli attacchi all'hash memorizzato finale non funzioneranno * perché l'hash non era " t generato da una parola del dizionario, ma un lungo hash.

La ragione per cui questo non funzionerà è che il processo fa sempre parte della logica del programma piuttosto che l'entropia dal lato umano. La password cracking diventa semplicemente SHA1 (SHA1 ($ pass)) invece di SHA1 ($ pass) o qualunque altro controllo tu abbia in atto (salatura ecc.). Data la necessità di ripetibilità, non è possibile eseguire l'hashing di un numero casuale di volte sul lato client, ma deve sempre essere definito.

Se ho frainteso ciò che stai suggerendo fammelo sapere.

Modifica: per espandere ulteriormente ciò che penso tu stia dicendo: commenti qui sotto.

Vuoi farlo in modo che l'hashing richieda l'ora X, dove X è il punto in cui non è pratico eseguire attacchi di dizionario. Stai dicendo che date le risorse del server, usare un hash lento come bcrypt può solo ottenere un rallentamento del tempo 'Y', che non è sufficiente per superare la soglia 'X'. L'idea è di usare anche la CPU del client 'Z', quindi ora hai Y + Z al punto in cui speri di raggiungere questa soglia 'X' degli attacchi del dizionario di rendering inutili.

La mia risposta sarebbe dubitare che ci sia abbastanza potenza della CPU tra il client e il server per rendere questo non pratico per qualcuno a provare un attacco di dizionario, pur mantenendo un servizio utilizzabile. Questo perché la differenza tra calcoli GPU e calcoli della CPU è così grande.

Per il database risultante, se l'hashing si verifica lato client o lato server non ha molta importanza. L'autore dell'attacco vede un hash e prova le password.

L'hashing sul lato client ha le seguenti conseguenze principali:

• La CPU viene spesa sul client, non sul server; poiché un server potrebbe dover gestire 100 client alla volta, mentre il client accederà a un solo server alla volta, sembra un utilizzo efficiente della CPU disponibile.
• Tuttavia, la CPU sul client significa, in un contesto Web, Javascript. Questo è più simile all'1% della CPU, a causa del sovraccarico di Javascript (anche con la compilazione JIT, Javascript non è molto adatto alle attività che richiedono molta CPU).
• Poiché l'hashing richiede la conoscenza di salt , devi cambiare il protocollo: il client invia il nome utente, il server risponde con il sale e solo allora il il cliente fa l'hashing. Questo può o non può essere facile da applicare su un determinato protocollo; comporta un ulteriore viaggio di andata e ritorno.

Quindi non ci sarà un grande aumento di sicurezza in questo modo. Le cose cambiano se puoi avere storage sul client. In questo modo, puoi memorizzare un tasto (qualcosa di segreto) sul client e utilizzare un MAC calcolato sulla password dell'utente (come digitato) come "password" da inviare al server. Poiché un utente malintenzionato che ha hackerato un server ha ottenuto il database ma non quello memorizzato sul client, questo porta il "servizio di comunità" che si sta cercando. D'altra parte, la memorizzazione delle chiavi sul client porta il proprio insieme di problemi (in particolare, l'utente non può più passare facilmente le macchine, la chiave deve essere trasportata in qualche modo da una macchina all'altra). È possibile utilizzare un server di archiviazione dedicato per risolvere questi problemi di archiviazione. In larga misura, questa soluzione è il KeePass modello.

Non c'è alcun guadagno particolare sul server o sul client, in effetti, sembra che tu stia usando un risultato intermedio come punto di smistamento tra l'hashing lato client e lato server. Ottenete un risparmio di prestazioni per rendere disponibile un livello proibitivo di hashing altrimenti dispendioso, ma in definitiva, poiché il client restituisce l'hash intermedio come input valido, l'autore dell'attacco deve comunque solo contrastare la versione del server.

Supponiamo di eseguire 1000 iterazioni di un hash localmente su "mypassword" per ottenere un valore di "jdqfr3bt". Il client deve quindi fornirlo al server e il server fa le 10 iterazioni che può permettersi di fare per ottenere "91jf35j" che corrisponde al DB, quindi lo lascia entrare.

Ora come utente malintenzionato ottengo 91jf35j dal DB e guardo finché non trovo quel valore "jdqfr3bt" corrispondente. Quindi, semplicemente, lo fornisco come "risultato" dell'hash del mio cliente, senza preoccuparmi di fare effettivamente qualcosa. Il server lo vede come valido. Rende più costoso iniziare da un dizionario, ma una tabella di puro arcobaleno non avrà alcun impatto.