Calcolo degli hash delle password nel browser?

6

Ho finalmente avuto accesso alla Keybase e sono rimasto sorpreso di vederlo nella pagina di registrazione:

Non dovresti allungare la password e fare l'hashing sul server, dato che normalmente non ci fidiamo di un client?

    
posta Naftuli Kay 01.10.2014 - 22:13
fonte

3 risposte

6

L'intero punto di Keybase è che l'utente non deve e non dovrebbe avere fiducia nel server con nulla. Tutte le prove possono essere verificate senza il server. Poiché la passphrase Keybase serve a decodificare la chiave privata utilizzata per firmare le bozze, al server non può essere consentito di toccarlo.

Inoltre, ci si deve fidare del cliente per fornire una passphrase di registrazione, quindi anche su siti web meno peculiari di Keybase, consentendo al JavaScript di eseguire il proprio hashing della password, ci sarebbe perfettamente. (Consentire a un utente di accedere con lo stesso, però, sarebbe una pessima idea, dato che qualcuno potrebbe semplicemente passare l'hash.) Non lo fanno, però, perché questi siti devono essere comunque considerati con la password dell'utente ( vedi parentetico) e l'hashing di JavaScript è sia più lento che non sempre disponibile.

    
risposta data 01.10.2014 - 22:31
fonte
3

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

Hai fatto confusione qui. C'è una differenza tra fidarsi di un client e troncare la password dell'utente sul lato client.

Hai ragione che non ci fidiamo mai del cliente. Ma qui siamo il cliente e abbiamo bisogno di fare l'hashing di qualcosa. Perché dovremmo, il cliente, fidarsi del server con la nostra password?

Quindi, ciò che accade è che lo si hash localmente in modo tale che il server non saprà mai cosa è stato digitato e quindi lo invierà. Quindi il server dovrebbe assicurarsi che si tratti di un hash valido invece di accettare ciecamente tutto ciò che riceve poiché, in effetti, non dovresti mai fidarti dei client.

Non sai come spiegarlo correttamente, spero che aiuti!

    
risposta data 01.10.2014 - 23:20
fonte
2

Shouldn't password stretching and hashing be done on the serverside, as we normally don't trust a client?

È vero, ma non è applicabile in questo caso. Prima di tutto, il client che incassa l'hashing li fa solo male in questo scenario!

Tradizionalmente, ecco cosa accadono cose brutte con un hash lato client:

  1. Qualcuno digita la password ( horsebatterystaple01 )
  2. È sottoposto a hash e l'output è 123456 (fai finta che sia un output hash valido)
  3. Il server vede se l'hash di 123456 corrisponde al database. Quindi concede o nega l'accesso.
  4. Un hacker trova il database delle password sul server
  5. Inviano 123456 al server e sono connessi, saltando l'hash.

Ora, è per questo che è facile per un hacker hackerare un hash del client. L'obiettivo di un hash è impedire che la password possa essere ripristinata, anche se il database delle password è compromesso. Se non sono stati sottoposti a hash e salati correttamente, l'hacker non solo poteva usare quella password per accedere al sito che era stato compromesso, ma potevano provare altri siti bancari / email per vedere se la password è stata accettata.

Sebbene l'hashing lato client prevenga il secondo scenario, sarebbe comunque semplice per un utente malintenzionato inviare solo il server 123456 e il server concedere l'accesso.

    
risposta data 02.10.2014 - 04:39
fonte

Leggi altre domande sui tag