Perché la verifica della complessità della password lato client non è considerata sicura? [duplicare]

31

Ho un'applicazione web e ho implementato un controllo sul browser per garantire che un utente imposti solo password complesse. Una società che abbiamo chiamato per verificare le vulnerabilità della sicurezza ha sottolineato che questo non è sufficiente perché l'utilizzo di un hacking può ignorare il controllo e impostare una password debole.

Non capisco come possa essere una vulnerabilità di sicurezza. Perché qualcuno dovrebbe hackerare il controllo di sicurezza solo per impostare una password debole? Qualcuno esperto abbastanza per hackerare l'applicazione web capirà l'importanza di utilizzare una password complessa.

L'unica ragione per cui posso pensare è che qualcuno, molto molto pigro, può decidere di modificare l'assegno solo per avere una password più facile da ricordare. Non so quanto sia probabile questo caso.

So che non è possibile applicare una password complessa sul lato client e che se è necessario avere una password complessa in qualsiasi circostanza, è necessario farlo sul lato server.

Il mio punto è: dato che, per avere un'esperienza utente accettabile, dobbiamo eseguire il controllo sul lato client, ci deve essere una buona ragione, un caso d'uso reale che crea una possibile vulnerabilità per giustificare una duplicazione di il controllo sul lato server.

Leggendo le risposte, finora, sembra che l'unico caso d'uso in grado di creare una vulnerabilità sia quando il javascript non funziona. Questo non mi sembra un problema perché il pulsante di invio è disabilitato per impostazione predefinita.

    
posta Marco Altieri 27.04.2017 - 09:46
fonte

8 risposte

63

Supponi che il controllo sia saltato di proposito. Potrebbe accadere che qualcuno stia utilizzando un browser che non gestisce correttamente lo script o disabilita gli script, forse anche senza saperlo.

Sembra che tu abbia una ragione per cui le persone usano password forti. Se lo fai, perché accettare che le persone possano aggirarlo?

La convalida sul lato client può essere utile dal punto di vista dell'usabilità, ma se decidi che è richiesta una forza minima per la password, devi applicarla implementandola sul lato server.

    
risposta data 27.04.2017 - 10:28
fonte
13

La regola quando si scrive un'applicazione server è semplicemente mai fidarsi di ciò che proviene dal client . I controlli eseguiti dal lato client sono ottimi in quanto consentono una buona esperienza utente con popup e visualizzazione immediata. Ma come può accadere qualsiasi cosa, da un browser javascript disabilitato a un utente che utilizza un linguaggio di scripting per simulare un browser, tutti i controlli devono essere effettuati (di nuovo) sul lato server.

Se le password complesse sono solo consigliate, fai ciò che vuoi, se sono un requisito, devi implementare un lato server di controllo.

BTW: tu come dev puoi proporre soluzioni, ma il cliente esprime i requisiti. Se non sei d'accordo con loro puoi chiedere chiarimenti e proporre altri modi, ma alla fine il cliente deciderà.

    
risposta data 27.04.2017 - 11:55
fonte
12

Se l'utente DEVE impostare una password complessa, controllare la forza della password solo sul lato client è una vulnerabilità.

Esempio

Se lavori in una grande azienda e devi cambiare la password ogni 2 o 3 mesi, alcune persone inizieranno a bypassare il controllo sul lato client della forza della password per usare più breve o meglio per memorizzare le password. Se queste password vengono utilizzate per derivare chiavi crittografiche, ad es. per la crittografia multi-utente di file, diventa orribile ...

Soluzione

Controlla sempre la forza della password sul server e opzionalmente controlla la forza della password sul client per ridurre le richieste al server.

Libreria consigliata: ZXCVBN

  • Utilizza la corrispondenza del modello e verifica la maggior parte delle password utilizzate per stimare il livello di sicurezza della password.
  • È disponibile in più lingue di programmazione
risposta data 27.04.2017 - 10:19
fonte
10

Basandosi su risposta di Teun Vink , lì sono alcuni scenari del mondo reale in cui un utente potrebbe ignorare accidentalmente il controllo di sicurezza.

Supponiamo che un utente scarichi un adblocker come Adblock Plus o uBlock Origin . Quindi, a causa di errori di configurazione degli script, uno di questi blocchetti di blocco blocca accidentalmente lo script che stavi utilizzando per verificare la sicurezza della password. Ora l'utente può inserire 1234 come password senza effettuare controlli sul lato server per impedirlo.

O in alternativa, forse la cache locale ha dato all'utente una versione più vecchia del tuo script. Forse hanno salvato la tua pagina web come un file HTML statico sul loro desktop. Forse il PC dell'utente ha un virus che ha alterato il contenuto del tuo script. Come dice il proverbio ...

Never trust the user.

Modifica: consulta anche " Impossibile salvare il profilo quando maps.googleapis.com è bloccato "per un ottimo esempio del perché non dovresti mai fidarti dell'utente.

    
risposta data 27.04.2017 - 17:26
fonte
2

Hai detto che sia il check & l'abilitazione del pulsante di invio è uno script, quindi è sicuro anche se alcuni script sono caricati e altri no. Sei sicuro che quelle due funzioni sempre siano nello stesso script?

Suppongo che quello che sto dicendo è che sembra che, come stanno le cose adesso, significherebbe qualcuno fare intenzionalmente qualcosa che sanno essere una cattiva idea in modo che possano ottenere una password sbagliata, e tu stai bene con quello; stai cercando di prevenire gli incidenti, non la stupidità intenzionale.

La cosa che mi preoccupa è che se questo script viene mai refactored e amp; divisi, o la stupidità intenzionale diventa il tuo problema, o qualche aggressore scrive un copione del cliente apparentemente per aiutare le persone, ... allora sei nei guai.

    
risposta data 27.04.2017 - 21:01
fonte
2

Un possibile problema è che ci vuole solo un ragazzo saggio (che potrebbe essere abbastanza esperto da usare quella tecnica per usare una password che fallisce il correttore ed è comunque sicuro!) per trovare un modo per hackerarlo - e distribuire l'hack a poche altre persone (che probabilmente reputa abbastanza responsabili) che alla fine la daranno a persone contro la cui mancanza di competenze di sicurezza la soluzione avrebbe dovuto proteggere.

    
risposta data 27.04.2017 - 22:29
fonte
1

Applica regole sul server

Indipendentemente dalle regole che imposti, devono essere applicate a livello di server in ogni caso. Ciò vale per l'impostazione della password e, ad esempio, per i campi obbligatori nei moduli (ad esempio se è necessario un numero di telefono al momento della registrazione, deve essere controllato nel server).

Aiuta il tuo utente sul client

Indipendentemente dalle regole che imponi sul server, dovresti aiutare il tuo utente il più possibile dando aiuto sul client.

Può essere solo una spiegazione, stelle accanto ai campi obbligatori, mostrare errori prima di inviare moduli, ...

Ma applica le regole sul server

Ma in ogni caso, non puoi fare affidamento sul cliente. Alcune persone bloccheranno JS. Alcune persone bloccheranno il flash. Ad un certo punto puoi aprire la tua API a terze parti, che potrebbero o meno rispettare le tue regole per te.

Io, per esempio, a volte ho riattivato i pulsanti JS bloccati perché ho scoperto che le regole applicate dal client erano ridicole (ad esempio la tua password deve avere esattamente 8 caratteri, inclusa esattamente 1 lettera maiuscola, 1 numero e 1 speciale carattere in (! @ # $% & *?) solo, sperando che il server non applicasse quelle regole (che spesso non lo facevano).

Se le tue specifiche devono avere un preciso insieme di regole sulla password dei tuoi utenti, allora avere la validazione lato client non soddisfa le specifiche.

    
risposta data 27.04.2017 - 16:54
fonte
1

Mi aspetto che la ditta di test di penna applichi un principio generale qui "esegui tutte le convalide sul lato server" senza considerare il caso specifico in modo molto dettagliato.

Nel tuo scenario, dove JavaScript non può essere disattivato, non vedo alcun rischio pratico per la sicurezza. Ci può essere un rischio non tecnico se hai bisogno di password complesse per un requisito normativo (ad esempio PCI-DSS).

    
risposta data 27.04.2017 - 20:21
fonte

Leggi altre domande sui tag