La crittografia del browser è realisticamente sicura?

0

Ho un'app web che spero di scrivere dove una selezione di file viene compresso e crittografato nel browser prima di essere caricato sul mio server. Ho un prototipo del sistema e funziona alla grande. Voglio farlo nel browser senza alcun coinvolgimento del server durante la gestione dei file non crittografati per l'intimità della privacy.

Il processo generale è:

  1. L'utente seleziona i file locali sul proprio computer
  2. Comprimi questi file insieme
  3. Genera una chiave
  4. Cripta lo zip con il tasto
  5. Carica zip crittografato sul server (questo è il primo utilizzo della rete dopo il caricamento della pagina)

Il mio obiettivo è conoscere il meno possibile sul pacchetto caricato. Zippare significa che non so quanti file ci sono e poiché le chiavi sono tutte gestite lato client non c'è assolutamente modo che io debba essere in grado di decrittografare il pacchetto. Il mio servizio riguarda lo storage, quindi non ho mai bisogno di trasmettere la chiave ovunque. La chiave è disponibile all'utente per la gestione personale.

Mi rendo conto che l'uso della sicurezza javascript consente ai miei clienti di manipolare i valori al fine di paralizzare la sicurezza, ma poiché sono solo in grado di modificare il codice che li colpisce, un utente può solo indebolire la sicurezza sui pacchetti che caricano. Suppongo che un utente che sta attivamente cercando di spararsi nel piede non è un problema che devo tentare di prevenire.

Il MITM sembra una possibilità. Eve potrebbe manipolare i file JS richiesti per rimuovere la crittografia e un pacchetto non crittografato potrebbe essere recuperato da Eve durante il caricamento, ma non penso che questo presenti alcun nuovo problema su un sistema in cui il pacchetto viene inviato al mio server e quindi crittografato. HTTPS e un utente esperto possono aiutare a prevenire anche un MITM. "Un utente ben educato" potrebbe essere un sogno irrealizzabile, ma posso fare la mia parte per tentare di educare i miei utenti prima che inizi il processo.

L'ultimo e finora peggio problema che viene in mente è la possibilità di un'estensione del browser dannoso. Potrebbe manipolare il JS per rimuovere la crittografia, ma il caricamento sarebbe comunque sicuro utilizzando una connessione HTTPS forzata (il server può rifiutare i caricamenti non sicuri). Poiché ho letto i file utilizzando l'API FileReader di Javascript, un'estensione malevola potrebbe intercettare il blob non crittografato e caricarlo su una terza parte. Come potrei difendermi da qualcosa del genere? So che il mio sito e i server non sono stati violati, ma questa è comunque una grande perdita per i miei clienti. Si può fare qualcosa per questo?

Se la connessione con il server è applicata al 100% HTTPS, quale tipo di attacchi potrebbe essere indirizzato a un sistema come questo? Ci sono problemi a cui non ho pensato per cui devo prepararmi? Cosa posso fare per garantire la sicurezza e la privacy?

    
posta Corey Ogburn 12.06.2015 - 17:48
fonte

2 risposte

1

Quello che stai proponendo è la stessa architettura utilizzata nei gestori di password online come Lastpass e portafogli online di Bitcoin come Blockchain . Hai nominato le due grandi minacce: manomissione di Javascript e computer compromesso.

Ti occupi della minaccia della manomissione di Javascript proteggendo il server e convincendo gli utenti che il tuo Javascript è sicuro.

Per quanto riguarda le estensioni del browser dannoso o altri codici maligni sul computer, non puoi fare molto al riguardo. Devi lasciarlo ai tuoi utenti per assicurarti che il loro computer sia sicuro.

    
risposta data 12.06.2015 - 19:11
fonte
1

Affidarsi al server è inevitabile e devi fidarti comunque del server se la crittografia è basata sul server. Gli attacchi MITM si applicano anche alla crittografia basata su server e non vedo alcun motivo per cui un plugin dannoso non possa attaccare anche la crittografia basata su server.

La differenza principale è che ti stai affidando al client per eseguire la crittografia, in cui hai meno controllo dell'ambiente di programmazione. Una cosa che devi fare attenzione è la generazione del numero casuale usata in Javascript. Math.random () è ciò che molte persone potrebbero usare come fonte di numeri casuali, ma non è appropriato per l'uso crittografico. Se non stai producendo abbastanza entropia per la generazione di numeri casuali potresti facilmente essere vulnerabile agli attacchi di forza bruta sui tasti. Vedi questa risposta per una libreria migliore da utilizzare a scopi di crittografia .

    
risposta data 12.06.2015 - 20:50
fonte

Leggi altre domande sui tag