La forza della password dell'utente deve essere valutata sul client o sul lato server?

forza la password, in questo contesto, è un concetto privo di significato. La forza della password, nella maggior parte dei casi, non è una proprietà intrinseca della password stessa. Questa logica di validazione dell'input nei moduli di registrazione controlla semplicemente la password rispetto a un determinato criterio: ha un numero? Ha un carattere speciale? È più lungo di 8 caratteri? ecc.

Tali verifiche possono essere eseguite nel browser del cliente o sul server. L'applicazione di tali condizioni, tuttavia, può essere eseguita solo sul server in quanto l'utente può semplicemente aggirare tali restrizioni sul lato client. Questi controlli sono fatti nel browser dell'utente perché è molto più veloce a farli lì; sono solo indicatori per l'utente. Una volta che la password è stata inviata al server, deve essere controllata rispetto a quelle condizioni.

Nota a margine: Io non sono un grande fan di restrittive condizioni di "forza" e la password non li consiglio. Tuttavia, vedo il vantaggio di controllare una lunghezza minima e di assicurarmi che la password non esista in un dizionario o in un vocabolario.

O è accettabile

Alcune considerazioni:

1. Dal punto di vista dell'usabilità, controllare lato client ha meno latenza , quindi è più user-friendly.

2. Puoi eseguire controlli più dettagliati lato server . Ad esempio, il controllo se la password è basata su una parola del dizionario. Tuttavia, la maggior parte dei siti non fare questi controlli dettagliati. In ogni caso, non sono convinto il vantaggio di fare controlli dettagliati. Il punto di controllo della password la forza è solo per scoraggiare qualcuno usando una password banalmente debole, non più di questo.

3. Se si esegue una verifica lato client, può farlo un utente malintenzionato aggirare i controlli . Normalmente dovresti ripetere qualsiasi controllo su server. Tuttavia, nel caso della forza della password, non lo vedo è importante. Se un utente andrà alla lunghezza di utilizzare un interattivo proxy per consentire a se stessi di utilizzare una password debole, quindi fair play a loro. A quel punto, li lascerò in pace.

In realtà, piuttosto che un correttore di password, preferisco avere un consigliere per le password . Mentre l'utente digita la sua password, un indicatore dice "debole ... medio ... strong". Non è vietato usare una password debole; sono solo avvertiti.

Modifica nel 2018 La best practice ora è controllare che la password dell'utente non sia uno dei milioni trapelati in caso di violazione dei dati. Questo può essere fatto solo lato server.

Un controllo superficiale di Gmail indica che l'analisi della forza della password viene eseguita sul lato client utilizzando JavaScript. Ho letto il loro .js per un po ', ho deciso che era impenetrabile alle 9:30 del mattino senza caffè e ho guardato il filo con tcpdump mentre invece ho digitato una nuova password. Ogni pressione del tasto non ha attivato il traffico tra il browser e Google, ma ogni volta che la valutazione della password è cambiata (ad esempio, da "troppo breve" a "debole") il traffico era correlato alla modifica del fumetto del piccolo aiuto.

Puoi premere F12 in Chrome mentre sulla loro pagina cambia password e sfogliare tutti i loro JavaScript. Bevi prima il caffè.

Detto questo, le password del World Wide Web sono quasi sempre inviate al server in chiaro, ma idealmente su HTTPS in modo che il wrapper SSL offra sicurezza. Sono in testo semplice nel formato GET o POST, oppure sono codificati (non crittografati ) nell'intestazione Auth di base HTTP. Perché? Gestione delle chiavi.

Il client non ha modo di digitare chiavi per crittografare la password condivisa dal server. L'impostazione di uno richiede o la distribuzione di chiavi segrete ai client N + 1 e il mantenimento della segretezza ... o l'impostazione di un sistema a chiave pubblica. E una volta impostato un sistema a chiave pubblica, devi solo dare un calcio a te stesso e dire "Perché non mi fido del protocollo SSL per cominciare?"

Ora, ecco alcuni valori anomali da considerare:

È possibile che server e client eseguano autenticazione digest . In breve, il server invia una stringa casuale, il client esegue l'hashing della password e lo schiaccia con quella stringa casuale e lo rimanda indietro. Il server deve avere una copia in chiaro della password corretta sul suo lato; esegue lo stesso processo di hash + mash e lo confronta. Ciò è più difficile per un utente malintenzionato di prendere la password sul cavo, ma in genere richiede che il server conosca la password in chiaro (anziché una versione con hash).

BMC Remedy una volta implementato quanto segue: La pagina di accesso conteneva JavaScript che avrebbe scambiato la password - IIRC memorizzava una statica stringa ed eseguirebbe un cifrario di sostituzione sulla password usando quella stringa. Manderebbe la stringa modificata al server, che potrebbe semplicemente invertire la sostituzione. Unico problema? Chiunque può invertire la sostituzione, perché ha seguito un algoritmo statico che è stato pubblicato nel JavaScript nella pagina di accesso. Quindi Remedy-over-HTTP non ha fornito alcuna protezione reale per le password ... che risale al tema originale, di "generalmente ci affidiamo solo al protocollo SSL per proteggere le password in transito"

Infine, sono a conoscenza di un'applicazione - Litle PayPage - che distribuisce JavaScript con un chiave pubblica. PayPage non accetta password, ma i dati della carta di credito, e il codice JavaScript viene crittografato con quella chiave integrata prima che avvolge l'intera richiesta in SSL e l'invio su HTTPS. Lo stesso potrebbe essere fatto con qualsiasi applicazione, essenzialmente risolvendo il problema iniziale che ho elencato di condividere le chiavi con il client - o riprodurre il sistema SSL, fate la vostra scelta. Il vantaggio di questo approccio è che aggira il tradizionale problema di "Cosa succede se ci sono gateway HTTP che eseguono un MITM su SSL?"

Should user's password strength be assessed at client or at server side?

Entrambi.

Il controllo lato client è molto utile dal punto di vista dell'usabilità in quanto è possibile eseguire il controllo senza che l'utente invii alcun dato al server che incorre in una penalità di latenza. Tale controllo è facilmente raggiungibile utilizzando javascript in un browser web.

Se hai bisogno della politica di rafforzamento della password da applicare, forse come parte di un regolamento o di un altro, l'applicazione deve essere eseguita sul lato server. Qualsiasi controllo sul lato client può essere (relativamente) banalmente aggirato.