Problemi con Browser Crypto

7

Ci sono molti vecchi articoli 1 sul perché la crittografia nel browser è una cattiva idea. La maggior parte sono riassunti tramite: link

We believe that SJCL provides the best security which is practically available in Javascript. (Unforunately[sic], this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.)

Sembra che il problema più grande che hanno menzionato è che un utente malintenzionato potrebbe fornirti un javascript errato eseguito dal browser perché XSS è così comune.

Tra TLS e una politica di Content Security estremamente restrittiva, è ancora un problema e quindi una criptazione nel browser una cattiva idea?

L'obiettivo della crittografia non è quello di sostituire TLS. Viene utilizzato per crittografare i documenti prima che raggiungano il server in modo che solo il mittente e il destinatario possano leggerli.

1:

posta erik 08.08.2016 - 19:11
fonte

1 risposta

11

Speravo che qualcuno chiedesse di questo argomento, ho fatto molte ricerche nell'area.

Hai ragione nel ritenere che la maggior parte dei punti in javascript-cryptography-considerati-nocivi sono superati dai nuovi browser. A parte l'ovvio problema di qualcuno che compromette il server, che è un problema separato e presenta un problema anche a TLS, i punti principali ora sono "corretti":

  • window.crypto.getRandomValues() utilizza un CSPRNG reale
  • HTTPS è comune e molto più economico ora rispetto al 2011
  • Gli attributi integrity e nonce <script> di CSP possono proteggere il recapito degli script per assicurarsi che sia in esecuzione ciò che è in esecuzione
  • SJCL è più maturo di anni rispetto al 2011 e non ci sono problemi di rilievo
  • i runtime malleabili non sono importanti se non hai XSS, che i CSP sono ora bravi a fermare

Inoltre, ora sappiamo che HTTPS non è una garanzia assoluta di privacy (snowden / heartbleed / crime / breach / etc), ma una vera e propria crittografia end-to-end. Ora possiamo anche implementare librerie abbastanza robuste, collaudate e sicure, supportate da un runtime JS più sicuro di quanto offerto nel 2011; "use strict" ampiamente supportato, CSPRNG, strutture binarie, web worker con ambienti di runtime sigillati ecc.

Questi sono aggiornamenti dei punti principali, ma se hai dubbi su altri aspetti della crittografia client, sarò lieto di affrontarli.

Ovviamente, niente è perfetto:

  • i vecchi browser hanno ancora problemi o non possono eseguire il nuovo codice in modo sicuro
  • le estensioni aggiunte dall'utente possono eseguire qualunque codice desiderino
  • Il
  • malware può sostituire l'intero browser con qualcosa di sinistro o rubare la pre-crittografia dei dati
  • il phishing può indurre l'utente a utilizzare qualcosa oltre al tuo sito sicuro.

In breve, penso che post-snowden, noi dovremmo provare a mantenere semplici i dati privati dai server ovunque possiamo aiutarli, e una solida crittografia end-to-end, fatta bene, migliora enormemente il la privacy dei tuoi utenti e la sicurezza dei loro contenuti.

    
risposta data 08.08.2016 - 20:55
fonte

Leggi altre domande sui tag