Crittografia lato client: disponibile solo il browser web

SSL / TLS è il livello di crittografia tra browser e server. Finché hai configurato correttamente il tuo SSL / TLS sul server, qualsiasi crittografia di tipo javascript aggiuntiva è ridondante.

Se stai provando a creare un'applicazione sicura e il tuo team non capisce cosa fa SSL / TLS, potresti prendere in considerazione l'idea di portare un consulente di sicurezza per aiutarti con questi dettagli architettonici e assicurarti di evitare qualsiasi insidia .

JavaScript cryptography is not a good idea

La crittografia JavaScript non è male di per sé, è solo inefficace contro le minacce più comunemente considerate.

Se consideri un man-in-the-middle (MITM) una minaccia, SSL / TLS è un controllo molto più efficace in quanto altrimenti l'autore dell'attacco potrebbe sostituire il JavaScript per una versione che non utilizza la crittografia.

Se consideri il software dannoso sul lato client come una minaccia, potrebbe presumibilmente modificare il codice JavaScript in qualsiasi modo e la tua crittografia sarebbe inutile.

Se consideri il lato server come una minaccia (ad esempio il client vuole che il server memorizzi qualcosa ma non veda il contenuto), allora potrebbe essere efficace, ma il client ha bisogno di un altro modo per garantire che JavaScript non stato manomesso (che non è un problema facile da risolvere) e il client deve gestire da solo la chiave.

Nel caso d'uso che hai descritto, non sembra che la crittografia del lato client aggiunga davvero ulteriore sicurezza. In entrambi i casi devi affrontare la questione della comunicazione della chiave, che probabilmente dipenderà dall'integrità di SSL / TLS indipendentemente . O il client dovrà inviare la chiave al server o viceversa, e anche se utilizzi la crittografia a chiave pubblica per risolvere questo problema, avrai ancora il problema di verificare che la chiave pubblica inviata al client sia autentica. Molto probabilmente finirai per reimplementare una tipica infrastruttura a chiave pubblica.

A parte questo, non c'è alcun problema fondamentale con l'esecuzione della crittografia in JavaScript, tranne che:

• In genere è piuttosto lento rispetto alla maggior parte degli standard
• Generare chiavi crittograficamente sicure può essere un problema, in particolare nei vecchi browser che non supportano alcune API più recenti per questa attività

Hai pensato di utilizzare SSL / TLS sul lato server. Quindi i dati attraverseranno il canale protetto. E sul lato server è possibile crittografare ti e memorizzarlo in tale forma nel database

Dai commenti dell'OP non sembra che questo sarebbe utile per loro, tuttavia potrebbe essere utile ad altri.

È possibile cifrare utilmente le informazioni lato client, ma i casi d'uso sono pochi e distanti tra loro.

Esempio di utilizzo:

1. L'utente deve lavorare su documenti riservati (almeno a loro giudizio) che devono essere archiviati localmente (forse per ridurre i costi del server)
2. Il computer su cui lavorano non è protetto (sufficiente) da altri utenti (ad es. qualcun altro può aprire il browser)
3. Tuttavia, è sufficientemente protetto da impedire agli altri utenti di manomettere il sistema operativo, il browser Web o l'hardware. (sembra inverosimile, ma forse qualcosa come una macchina kiosk condivisa fisicamente protetta)
4. L'utente è disposto a inserire una password ogni volta che inizia il suo lavoro.

In questo caso l'applicazione javascript potrebbe essere fornita su TLS. I documenti possono essere crittografati con qualsiasi crittografia bidirezionale ritenuta accettabile. La chiave potrebbe essere derivata dalla password dell'utente e dovrebbe essere archiviata solo in memoria. Se uno dei precedenti non fosse vero, la crittografia javascript sarebbe superflua come segue:

1. Se i documenti possono essere archiviati sul server, TLS potrebbe coprire il problema e il server può occuparsi della memorizzazione crittografata, se necessario.
2. Se solo il proprietario ha accesso al computer, i documenti potrebbero essere archiviati nella memoria locale.
3. Se il computer è pubblico, è possibile installare un keylogger o una versione dannosa del browser e in questo caso non è possibile la sicurezza.
4. Se l'utente può accedere al proprio lavoro senza una password aggiuntiva, qualsiasi utente può accedere al proprio lavoro.