Perché non è una pratica standard eseguire il lato client di KDF basato su password?

Penso che il problema principale siano i linguaggi lato client (normalmente JavaScript), sono relativamente lenti. Ciò comporterebbe spesso un minor numero di cicli di hashing e quindi indebolisce la sicurezza.

Se la tua lingua lato client è abbastanza veloce, potresti calcolare il costoso lato client PBKDF, quindi calcolare un hash economico sul lato server (ad esempio SHA512). Per ottenere le password in chiaro, un utente malintenzionato doveva ancora calcolare il PBKDF lento. Inoltre, non è possibile utilizzare direttamente il PBKDF come password, poiché viene memorizzato solo l'hash del PBKDF (l'output di un PBKDF2 può essere visto come una "password" molto strong, quindi è sicuro usare una funzione hash economica) .

Uno svantaggio è che la gestione diventerà più complessa, è necessario inviare sale e costi al cliente per la verifica della password inserita. Un altro problema è garantire l'integrità del codice lato client, se qualcuno potrebbe modificare il codice JavaScript consegnato, potrebbe restituire una stringa nota e memorizzare il PBKDF ora non sicuro.

Guardalo da due estremi: -

1. Il server utilizza correttamente PBKDF

   Se il server sta facendo correttamente PBKDF, sarebbe una inutile duplicazione di sforzi e risorse se si fa la stessa cosa anche sul lato client. Dovrai implementare o utilizzare un software client-side che eseguirà PBKDF sulla tua password e poi inviarlo al server, e il server eseguirà quindi PBKDF sull'output del PBKDF lato client e lo memorizzerà nella sua Banca dati. Spero che tu possa vedere l'uso delle risorse aggiuntive senza alcun vantaggio aggiuntivo.

2. Il server non sta utilizzando affatto PBKDF

   Quindi, se il server memorizza le password in chiaro, l'output del PBKDF lato client verrà memorizzato così come è sul server. Quindi, quando un utente malintenzionato ruba il database del server, non farà alcuna differenza se la tua password fosse PBKDFed sul lato client, al server (e all'attaccante) sarà esattamente uguale a una password in chiaro come hunter1:)

Quindi per rispondere al tuo perché , l'entità generale è che è l'entità che controlla la risorsa responsabile della sua sicurezza, che in questo caso è il controllo degli accessi. O come un detto nella mia lingua madre, "l'uomo assetato deve andare al pozzo, il pozzo non viene al sete":)

Un po 'di sfondo prima:

Il motivo per cui le password non vengono memorizzate come testo normale è solitamente quello di fornire una difesa approfondita. Cioè, nel caso di un compromesso del database (che è qualcosa che dovrebbe essere ovviamente prevenuto), dovrebbe impedire all'utente malintenzionato di accedere alle password degli utenti originali. Questo di solito rende l'accesso alle password protette da PBKDF2 meno prezioso per l'aggressore. Naturalmente, ciò vale solo quando le password sono forti.

Per rispondere alla tua domanda:

Se i PBKDF2 sono stati calcolati sul lato client, una volta che l'attaccante ha avuto accesso al database, l'utente malintenzionato può utilizzare l'output PBKDF2 (memorizzato nel database) per accedere come utenti vittima attraverso l'interfaccia web. Cioè, l'attaccante non ha bisogno di accedere alla password originale per accedere. L'utente malintenzionato può semplicemente inviare il nome utente e il valore PBKDF2 della password sconosciuta al server e accedere come se fosse un utente legittimo. L'unica differenza è che l'utente legittimo fa uso di JavaScript o di un altro meccanismo sul lato client per calcolare il valore PBKDF2 mentre l'utente malintenzionato dovrebbe averlo nel database.

Di conseguenza, la premessa iniziale di rendere meno prezioso l'accesso alle password con hash non è più valida in quanto l'accesso a tali informazioni ha valore (dà accesso all'attaccante all'account degli utenti vittima). Ha meno valore per l'utente malintenzionato rispetto all'accesso alla password originale (prima di eseguire l'operazione PBKDF2) ma ha più valore che se fosse crittografato sul lato server.

Ci sono altri problemi con il PBKDF2 lato client che penso dovrebbe essere menzionato:

• si dovrebbe usare un sale statico (cioè non può essere casuale in quanto produrrebbe un valore PBKDF2 diverso)
• altri valori passati alla funzione lato client PBKDF2 dovrebbero anche essere statici, rimuovendo così un certo numero di funzionalità di sicurezza (come la modifica del numero di iterazioni)
• proprio come nel caso del PBKDF2 lato server, la password originale può essere recuperata iniettando codice JavaScript per leggere i tasti o valori di input nel caso di un compromesso dell'applicazione Web (ad esempio XSS e vari altri vettori); in modo che i potenziali guadagni di sicurezza del PBKDF2 lato client siano persi