Sono tenuto a sviluppare un'applicazione Web che funzionerà offline per lunghi periodi. Affinché ciò sia fattibile, non posso evitare di salvare i dati sensibili (dati personali ma non il tipo di dati che memorizzeresti solo l'hash) nella memoria locale.

Accetto che questa non sia una pratica consigliata, ma data la poca scelta, sto facendo quanto segue per proteggere i dati:

• crittografando tutto ciò che va nella memoria locale usando la libreria crittografica javascript di Stanford e AES-256
• la password dell'utente è la chiave di crittografia e non è memorizzata sul dispositivo
• servire tutto il contenuto (quando online) da un singolo server fidato su ssl
• convalida di tutti i dati da e verso l'archiviazione locale sul server utilizzando il progetto antisamy owasp
• nella sezione di rete dell'appcache, non usando *, e invece elencando solo gli URI richiesti per la connessione con il server fidato
• in generale, cercando di applicare le linee guida suggerite nel cheat sheet di OWASP XSS

Apprezzo il fatto che il diavolo sia spesso nei dettagli e so che c'è molto scetticismo sull'archiviazione locale e sulla sicurezza basata su javascript in generale. Qualcuno può commentare se ci sono:

• difetti fondamentali nell'approccio sopra?
• eventuali soluzioni per tali difetti?
• un modo migliore per proteggere l'archiviazione locale quando un'applicazione HTML 5 deve funzionare offline per lunghi periodi?

Grazie per qualsiasi aiuto.

WebCrypto

I problemi con la crittografia nel javascript lato client (browser) sono dettagliati di seguito. Tutte queste preoccupazioni, tranne una, non si applicano all'API WebCrypto , che ora è ragionevolmente ben supportata .

Per un'app offline, è comunque necessario progettare e implementare un keystore sicuro.

A parte: se si utilizza Node.js, utilizzare l' API crittografica integrata.

Crittografia nativa-Javascript (pre-WebCrypto)

Presumo che la preoccupazione principale sia che qualcuno abbia accesso fisico al computer che sta leggendo localStorageper il tuo sito e desideri che la crittografia aiuti a impedire tale accesso.

Se qualcuno ha accesso fisico sei anche aperto ad attacchi diversi e peggiori della lettura. Questi includono (ma non sono limitati a): keylogger, modifica di script offline, iniezione di script locale, avvelenamento da cache del browser e reindirizzamenti DNS. Tali attacchi funzionano solo se l'utente utilizza la macchina dopo che è stata compromessa. Tuttavia, l'accesso fisico in tale scenario significa che hai problemi più grandi.

Quindi tieni presente che lo scenario limitato in cui la crittografia locale è preziosa sarebbe se la macchina viene rubata.

Esistono librerie che implementano la funzionalità desiderata, ad esempio Stanford Javascript Crypto Library . Ci sono debolezze intrinseche, tuttavia (come indicato nel collegamento dalla risposta di @ ircmaxell):

1. Mancanza di entropia / generazione di numeri casuali;
2. La mancanza di un keystore sicuro, ovvero la chiave privata deve essere protetta da password se memorizzata localmente o memorizzata sul server (che impedisce l'accesso offline);
3. Mancanza di cancellazione sicura;
4. Mancanza di caratteristiche di temporizzazione.

Ognuna di queste debolezze corrisponde a una categoria di compromesso crittografico. In altre parole, mentre potresti avere "cripto" per nome, sarà molto al di sotto del rigore a cui aspiri nella pratica.

Detto questo, la valutazione attuariale non è così banale come "La crittografia Javascript è debole, non usarla". Questa non è un'approvazione, rigorosamente un avvertimento e richiede di comprendere completamente l'esposizione dei punti deboli di cui sopra, la frequenza e il costo dei vettori che affronti e la tua capacità di mitigazione o assicurazione in caso di fallimento: Javascript crypto, in nonostante i suoi punti deboli, può ridurre la tua esposizione ma solo contro i ladri con capacità tecnica limitata. Tuttavia, dovresti presumere che la crittografia Javascript non abbia alcun valore nei confronti di un aggressore determinato e capace che prende di mira tali informazioni. Alcuni considererebbero fuorviante chiamare i dati "crittografati" quando sono noti così tanti punti deboli inerenti all'implementazione. In altre parole, puoi ridurre marginalmente la tua esposizione tecnica ma aumenti la tua esposizione finanziaria dalla divulgazione. Naturalmente, ogni situazione è diversa e l'analisi della riduzione dell'esposizione tecnica all'esposizione finanziaria non è banale. Ecco un'analogia illustrativa:Alcune banche richiedono password deboli , nonostante il rischio intrinseco, poiché la loro esposizione a perdite dovute a password deboli è inferiore ai costi dell'utente finale per il supporto di password complesse.

🔥 Se leggi l'ultimo paragrafo e pensi "Qualcuno su Internet di nome Brian dice che posso usare Javascript crittografato", non usare Javascript crittografico.

Per il caso d'uso descritto nella domanda sembrerebbe più sensato per gli utenti crittografare la propria partizione locale o directory home e utilizzare una password complessa. Questo tipo di sicurezza è generalmente ben collaudato, ampiamente affidabile e comunemente disponibile.

Bene, la premessa di base qui è: no, non è ancora sicuro.

Fondamentalmente, non puoi eseguire crypto in JavaScript: JavaScript Crypto considerato dannoso .

Il problema è che non è possibile ottenere in modo affidabile il codice crittografico nel browser e, anche se fosse possibile, JS non è progettato per consentirti di eseguirlo in modo sicuro. Quindi fino a quando i browser non disporranno di un contenitore crittografico (fornito da Encrypted Media Extensions, ma non saranno sottoposti a rally per i loro scopi DRM), non sarà possibile farlo in modo sicuro.

Per quanto riguarda un "Modo migliore", non ce n'è uno in questo momento. L'unica alternativa è archiviare i dati in testo semplice e sperare per il meglio. O non conservare affatto le informazioni. In entrambi i casi.

O quello, o se hai bisogno di quel tipo di sicurezza e hai bisogno di spazio di archiviazione locale, crea un'applicazione personalizzata ...

Come esplorazione di questo argomento, ho una presentazione intitolata "Protezione di TodoMVC mediante l'API di crittografia Web" ( video , codice ).

Utilizza l' API di crittografia Web per memorizzare l'elenco di todo crittografato in localStorage mediante la protezione dell'applicazione tramite password e l'utilizzo di una chiave derivata da password per la crittografia. Se si dimentica o si perde la password, non c'è recupero. ( Dichiarazione di non responsabilità - era un POC e non destinato all'uso in produzione. )

Come affermano le altre risposte, questo è ancora suscettibile all'XSS o al malware installato sul computer client. Tuttavia, tutti i dati sensibili rimarrebbero anche in memoria quando i dati sono archiviati sul server e l'applicazione è in uso. Suggerisco che il supporto offline potrebbe essere il caso d'uso convincente.

Alla fine, la crittografia localStorage probabilmente protegge solo i dati dagli aggressori che hanno accesso in sola lettura al sistema o ai suoi backup. Aggiunge una piccola quantità di difesa in profondità per l' esposizione ai dati A6 sensibili ai primi 10 articoli di OWASP e consente di rispondere "Uno di questi dati è archiviato in chiaro a lungo termine?" correttamente.

Questo è un articolo davvero interessante qui. Sto prendendo in considerazione l'implementazione della crittografia JS per offrire sicurezza quando si utilizza l'archiviazione locale. È assolutamente chiaro che questo offrirà protezione solo se il dispositivo viene rubato (e implementato correttamente). Non offrirà protezione contro keylogger ecc. Tuttavia, questo non è un problema di JS in quanto la minaccia keylogger è un problema di tutte le applicazioni, indipendentemente dalla loro piattaforma di esecuzione (browser, nativo). Per quanto riguarda l'articolo "JavaScript Crypto considerato dannoso" a cui fa riferimento la prima risposta, ho una critica; afferma "È possibile utilizzare SSL / TLS per risolvere questo problema, ma è costoso e complicato". Penso che questa sia un'affermazione molto ambiziosa (e forse piuttosto distorta). Sì, SSL ha un costo,

La mia conclusione: esiste un posto per il codice di crittografia sul lato client, tuttavia, come per tutte le applicazioni, gli sviluppatori devono riconoscere i suoi limiti e implementarli se adatti alle loro esigenze e garantire che ci siano modi per mitigare i rischi.

Non accessibile a nessuna pagina Web (true) ma è facilmente accessibile e facilmente modificabile tramite gli strumenti di sviluppo, come chrome (ctl-shift-J). Pertanto, è richiesta una crittografia personalizzata prima di archiviare il valore.

Ma, se javascript deve decrittografare (per convalidare), l'algoritmo di decrittografia è esposto e può essere manipolato.

Javascript ha bisogno di un contenitore completamente sicuro e della capacità di implementare correttamente variabili e funzioni private disponibili solo per l'interprete js. Tuttavia, ciò viola la sicurezza dell'utente, poiché i dati di tracciamento possono essere utilizzati impunemente.

Di conseguenza, JavaScript non sarà mai completamente sicuro.

No.

localStorage è accessibile da qualsiasi pagina Web e, se si dispone della chiave, è possibile modificare qualsiasi dato desiderato.

Detto questo, se riesci a escogitare un modo per crittografare in modo sicuro le chiavi, non importa come trasferisci i dati, se puoi contenere i dati all'interno di una chiusura, i dati sono (in qualche modo) sicuri.