Come implementare la crittografia lato client semplice e sicura

In sostanza, se la chiave è sicura, anche i dati sono sicuri (a condizione che sia un buon algoritmo di crittografia e la chiave abbastanza a lungo, cosa che considero scontata).

Se ho capito bene, invii solo dati crittografati via cavo, non la chiave stessa. Se non è il caso, ti preghiamo di scartare l'intera risposta.

Supponendo che la chiave non sia mai inviata sul filo , l'unico modo per compromettere i dati è scoprire la chiave. Questo potrebbe accadere se:

• Il modo in cui viene generata la chiave è prevedibile
• Qualcuno che ha accesso al file
• Un virus sul PC
• Attacchi di spoofing del DNS (che rivendicano essere il tuo host / dominio) - > Utilizza TLS e certificati (vedi link )
• Sfruttare un bug in qualche browser / versione esotici (non so se questo è già successo, e se ci sono alcuni avvisi di vulnerabilità o simili)
• ... c'è qualcos'altro?

... la sicurezza perfetta è difficile da raggiungere. Ma nel tuo caso, sembra che un hacker debba fare di tutto per hackerarlo o che l'utente abbia una macchina compromessa dall'inizio. Di solito, il collo di bottiglia è l'utente stesso. ;)

In termini di base, si presume che, se si crittografa i dati sul lato client (creazione di un token) e si invii token al server su HTTP, sarà sicuro: questo non è vero .

Hacker può ottenere il token tramite software di monitoraggio della rete (non ha bisogno di password) - è così . Il tempo stimato per bypassare questo è meno di 15 minuti.

In primo luogo, da quanto ho capito, non mostri all'utente dati provenienti da altri utenti, quindi non devi preoccuparti di XSS. Se lo mostrassi, dovresti prendere alcune contromisure, come la fuga dei caratteri (che in realtà dovrebbe essere usata comunque). La macchina hackerata e i difetti di sicurezza del browser sono cose che non si possono predire.

In secondo luogo, la cosa di crittografia che hai creato non funziona davvero. Scusate. A meno che tu non sia un genio con anni di esperienza in sicurezza, ma non avresti bisogno di fare questa domanda. Tra le cose che dovrebbero essere considerate quando si progetta la crittografia sono:

• Man in the Middle - qualcuno può intercettare i dati dell'utente decrittografando i dati dal server sulla propria macchina e ricodificandoli durante l'invio al client? L'attaccante può semplicemente chiedere al server reale un token e, fingendo di essere il server, ha il lusso di generare il proprio set di chiavi / token, che apparirà come originale.
• Monitoraggio della rete - sei sicuro di non essere suscettibile, ad esempio, di riprodurre attacchi? Supponiamo che ordini alcuni articoli in qualche negozio. Se l'attaccante lo registra e si ripete sul server, lo stesso, i dati crittografati, il server lo rileverà o eseguirà nuovamente la transazione?
• Generazione di chiavi: le chiavi utilizzate in modo completamente casuale o solo prevedibilmente casuali? Se l'attaccante può generare lo stesso set di chiavi memorizzato dal server, non ha nemmeno bisogno di attaccarti direttamente, può semplicemente sedersi e altre implicazioni sono piuttosto ovvie. E credimi, lo standard random con time seed è molto prevedibile.
• Molto altro ancora ...

Ci sono librerie come SSL che rendono questo per te, fatto da persone con anni di esperienza e, come probabilmente ti rendi conto, anche loro capita di sbagliare, ma nessuno sembra particolarmente desideroso di implementare qualsiasi alternativa per qualche motivo.

In caso di sicurezza, l'opzione migliore è utilizzare soluzioni verificate e popolari, in quanto probabilmente anche le più sicure. Dato che ci sono molte librerie open source e libere disponibili, questo non dovrebbe essere un problema. La crittografia pronta supportata dal browser probabilmente si prenderà cura di più problemi di quanti tu possa immaginare.

A meno che non ti abbia frainteso e tu non stavi giocando con le webapp per la parte webapp, ma per la sicurezza. Quindi continua a provare e ricorda che imparerai molto anche attaccando l'app che hai creato.