Perché alcune persone odiano la sicurezza tramite il lato client?

Quello che hai descritto non sta migliorando la sicurezza del sistema. Non è una questione di opinione o di emozione, la sicurezza non funziona in questo modo. Nel tuo esempio, hash(salt+password) è ora la tua password. Se non era su https, un utente malintenzionato poteva semplicemente riprodurre quel valore. Inoltre non hai indirizzato gli attacchi di stile owasp a9 o "firesheep".

Ha a che fare con lo scopo generale di ciò che stai cercando di proteggere. Se si sta sviluppando un'applicazione lato server, si sta tentando di proteggere il server sia dall'utente che dal sistema client. Avere il sistema dell'utente (cioè il client) fa in modo che il tuo lavoro di sicurezza per te non aiuti realmente il server a rimanere protetto. Di solito c'è il presupposto che quando il client sta facendo qualcosa, anche se funziona su richiesta del server (in termini di JavaScript fornito dal server) che il client è innatamente non affidabile, perché un hacker può assumere il controllo del lato client app e invia input separati da JavaScript.

Una password di hash del server per inibire i problemi derivanti dalla divulgazione dell'archivio password. Se un utente malintenzionato ottiene una sospensione degli hash delle password, dovrebbe essere impossibile farne uso inviando le password da un computer client compromesso - perché il server fa il proprio hash. Se il server delega questo lavoro al client, quindi il server sta anche delegando una funzione di sicurezza.

Tutto dipende da come definisci il tuo limite di protezione. Se hai ragione di credere che non ci sia assolutamente nessuna minaccia dal computer client e che il sistema client non possa mai essere hackerato, allora questo problema scompare ... ma non conosco nessun sistema web che possa fare questo reclamo .

La ragione principale non è l'odio ... è l'insicurezza. Un principio generale è quello di fidarsi di nulla di cui non si ha il controllo. Nel caso in cui un utente esegua l'autenticazione a un'applicazione, a meno che non abbia fornito il laptop all'utente, ne ha configurato i controlli e l'ambiente in cui si trova, non ci si può fidare di esso.

Il modo tradizionale di guardarlo è che se un utente malintenzionato ha accesso fisico a un computer, può fare quello che vuole.

Con un semplice browser che imposta semplicemente un collegamento crittografato c'è ben poco che può essere compromesso, con un client più spesso qualsiasi lato client di funzionalità potrebbe essere compromesso.

Se stai calcolando l'hash sul lato client, aggiungi il rischio che un utente malintenzionato abbia solo bisogno dell'hash della password di un utente per accedere invece della password effettiva. Probabilmente potresti aggirare il problema inviando un nonce a hash con la password (fondamentalmente un sale per sessione), ma poi dovresti ancora farlo sul lato server, quindi perché preoccuparsi di farlo sul client a tutti ?

Non sono sicuro che le persone "odino" i meccanismi che descrivi dal lato del cliente.

Penso che questo abbia più a che fare con le pratiche legacy e il supporto non uniforme sul client.

In primo luogo, è necessario JavaScript per implementare questo, se si desidera farlo tramite l'autenticazione basata su modulo. HTTP Digest fornisce qualcosa di simile in modo nativo ed è supportato dalla maggior parte dei browser (compresi quelli senza supporto JavaScript), ma non è "bello" e non può essere integrato molto bene con il marchio generale del sito. Per essere onesti, avere un marchio identificabile in cui inserirai la tua password può essere una buona cosa anche dal punto di vista della sicurezza. Inoltre, uno dei principali difetti delle implementazioni di HTTP Digest nei browser è che le finestre popup non sembrano molto diverse da quelle che usano HTTP Basic, che non offre alcuna protezione.

In secondo luogo, per quanto ne so, il supporto delle funzioni di crittografia JavaScript varia da un browser a un altro. Anche se a volte può essere tollerabile avere un supporto inadeguato per alcune funzionalità tra i vari browser, essere in grado di accedere è fondamentale e questo è qualcosa che non vuoi mai essere infranto.

Infine, devi ancora fidarti del codice inviato dal server, quindi non c'è alcun vantaggio qui se stai effettuando l'accesso tramite HTTPS comunque. Quando invii la tua password su HTTPS, la stai effettivamente consegnando al server e credendo che il server possa gestirlo correttamente. Se non ti fidi abbastanza del server per dargli la tua password, non ha senso affidarsi al JavaScript che ti invia per eseguire l'autenticazione.

Per il tuo esempio specifico c'è almeno un motivo commerciale e un motivo di sicurezza che potrebbe non essere fatto in questo modo.

Motivo commerciale

• L'utente richiede Javascript. Questo non è necessariamente sempre abilitato.

Motivo di sicurezza

• Le password vengono normalmente memorizzate con hash con un salino. Avresti bisogno di un sale costante, che lo renderebbe meno utile; condividere il sale specifico dell'utente, che aggiunge complicazioni e lo rende ancora meno utile (anche se non al grado di avere un sale costante); o forse un nome utente basato su sale.

Non tutti i sistemi evitano di utilizzare un sistema come quello che descrivi, Lastpass calcola gli hash sul lato client (descritto in un podcast Security Now ( trascrizione ).

Effettuare qualsiasi sicurezza sul client ha un enorme problema: si presuppone che il client si comporterà bene. Cosa succede se non lo fanno? Così gli fai calcolare un hash ... ora hai gente che usa le tabelle hash precalcolate che battono sul tuo server a ritmi super veloci, eliminando uno dei principali vantaggi dell'hash: la loro lentezza. Se non lo fai, ma chiedi al server di eseguire l'hashing per il client, puoi fare in modo che il client richieda zillion di stringhe a hash, rallentando il server ... Quindi in pratica è "scegli il tuo veleno". Devi scegliere la risposta in base alla conoscenza specifica del dominio: ti fidi dei tuoi utenti? Internet è di fronte? Se lo è, probabilmente non vuoi fidarti degli utenti.

L'apprendimento dell'analisi del protocollo è probabilmente il modo migliore per capire perché non si vuole lasciare che i client facciano molta sicurezza. Gli attacchi di riproduzione, gli attacchi di precalcolo, accadono tutti perché offri ai clienti troppa libertà, troppa scelta. Leggi il protocollo Needham-Schroeder-Lowe , come è nato, come hanno scoperto un attacco e qual è la soluzione , è una grande dimostrazione di come si vuole costruire un protocollo che sia al sicuro da client dannosi.

Per rispondere alla tua domanda è sufficiente capire il punto delle password di hashing.

Il motivo per cui le password sono hash è quello di memorizzare una derivata invece della password effettiva. Questo impedisce al mallory di accedere al server come alice anche se avrebbe compromesso il database del server (un problema abbastanza comune). Hai sempre sentito parlare dei numeri delle carte di credito e non delle password, perché le password con hash non sono vulnerabili in questo modo.

Ciò impedisce anche alla malleria di scoprire una password che potrebbe essere utilizzata da Alice su altri siti Web / software.

Potrebbe essere notato, anche se non è necessario rispondere alla tua domanda che un sale viene usato sui server durante l'hashing. Questo viene fatto per prevenire gli attacchi della rainbow table, perché è possibile iterare password casuali e cancellarle con algoritmi di hashing comunemente usati per memorizzarli in una tabella. Mallory ora può recuperare nuovamente le password eseguendo una ricerca tabella. Questa è una tecnica comune per il recupero delle password del sistema operativo. (almeno Windows fa / non ha usato un sale). L'essenza di un sale è che è univoco per installazione / sito web e anche segreto (di solito verrà archiviato in file php / config anziché nel database con il resto delle password).

Sulla sicurezza lato client. Quello che proponi non è proprio la sicurezza del lato client, poiché ti proponi solo di omettere un passaggio dalla procedura di memorizzazione delle password. Nota che ogni utente è libero di usare un hash come password.

Il punto da capire è che dovresti sempre fare sicurezza sul lato ricevente di qualche connessione (specialmente ma non solo su un servizio accessibile pubblicamente). Dal momento che un server web può essere connesso da chiunque non si può fidarsi di qualsiasi cosa entri in gioco. Qualsiasi sicurezza che potrebbe essere accaduta su un client deve essere superata, poiché un utente malintenzionato potrebbe facilmente aggirare tale sicurezza.

Come esempio di contro, nota che il client ha anche sicurezza. Quando il browser è destinatario finale , limita l'accesso al file system host, ad esempio agli script sui siti Web.

Mi dispiace di essere in ritardo per la festa ...

Le risposte vanno bene che usando l'hash ricevuto così com'è per confrontarlo con il tuo database, hai reso l'hash la nuova "password". Tuttavia, se aggiungi una sfida casuale (ovvero "nonce"), l'hash trasmesso non può più essere utilizzato come nuova password.

Non sono assolutamente d'accordo con quelle risposte che generalizzano che la sicurezza lato client è una cosa negativa. Stiamo usando l'hashing lato client (usando salt e un nonce) su un sito Web di alto profilo per anni. Principalmente per due motivi:

1. Evita che le password in chiaro vengano terminate accidentalmente nei log del server
2. Impedisci "occhi vagabondi" agli amministratori di sistema di imparare le password

Usando l'hashing sul lato client non saremo mai esposti alla password in chiaro degli utenti e quindi ridurrai la nostra responsabilità.

Attualmente stiamo cercando di progettare un allungamento chiave del sistema, il che si rivela un po 'più difficile. Vedi Sfida di sfida: hashing della password sul lato client e verifica della password sul lato server