HTML5 sessionStorage è sicuro per l'archiviazione temporanea di una chiave crittografica?

Question

HTML5 sessionStorage è sicuro per l'archiviazione temporanea di una chiave crittografica?

#1 da (6 voti)
#2 da (4 voti)

7

Supponiamo che sto creando un'applicazione web locale (ad esempio l'estensione del browser) in HTML5 per crittografare un database localmente. L'accesso al database è controllato da una password e una chiave master crittografica è derivata dalla password utilizzando un PBKDF. Voglio memorizzare la chiave master derivata in memoria solo mentre l'applicazione è in uso in modo da poter crittografare e decrittografare i record in base alle esigenze.

Ho cercato di utilizzare sessionStorage per questo scopo. Il vantaggio è che la chiave dovrebbe essere solo in memoria e disponibile per la scheda del browser corrente. La chiave dovrebbe essere cancellata se quella scheda o il browser sono chiusi. Il vantaggio è che se è necessario aggiornare la scheda del browser, avrà comunque la sessione attiva e la chiave master, altrimenti sarà necessario reinserire la password ogni aggiornamento. L'aggiornamento può essere un evento raro in quanto è tuttavia un'applicazione singola pagina.

Leggendo la specifica sessionStorage su W3C c'è qualche preoccupazione:

The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart.

Si tratta di riavvio del sistema operativo o di riavvio del browser?

Ciò che io assolutamente voglio evitare è avere la chiave crittografica scritta sul disco dove è molto difficile sbarazzarsi. La citazione sopra dice che esiste la possibilità che la chiave nel sessionStorage possa essere archiviata sul disco come parte del processo di recupero / riavvio di emergenza? Oppure questo processo di riavvio viene solitamente gestito solo in memoria?

a) Qualcuno ha qualche conoscenza su come i browser open source Tier 1 (Firefox, Chromium) gestiscono sessionStorage e se i contenuti possono essere scritti su disco, anche temporaneamente nel caso di un arresto anomalo del browser?

b) Esistono delle attenuazioni per impedire la perdita della chiave sul disco in caso di arresto anomalo del browser o di riavvio? Ci sono delle impostazioni di about:config che potrebbero essere usate per disabilitare il recupero di sessione dopo un crash del browser?

c) è l'opzione più sicura per non utilizzare sessionStorage affatto per l'archiviazione di una chiave? O forse mitigare il rischio utilizzando anche la crittografia completa del disco?

Grazie per il tuo aiuto.

cryptography key-management session-management html-5

posta sesses 23.05.2015 - 09:34

fonte

2 risposte

Leggi altre domande sui tag cryptography key-management session-management html-5

Perfect Secrecy (PFS) rende gli attacchi Man-in-the-Middle (MitM) più difficili? Algoritmo MD5: una spiegazione di base del processo

score 6 · Answer 1

In breve; Un riavvio del browser. Tuttavia, non tutti i browser implementano le specifiche definite dal W3C nello stesso modo.

a) Does anyone have any knowledge on how the Tier 1 open source browsers (Firefox, Chromium) handle the sessionStorage and whether the contents could be written to disk, even temporarily in the case of a browser crash?

Non fa menzione del salvataggio di dati che al momento risiedono in sessionStorage. Avrai bisogno di ricercare ogni implementazione dei browser per sapere con certezza.

Fai riferimento a documentazione di Mozilla , c'è anche un richiesta bug / funzionalità per migrare questa funzionalità in un database SQLite.

b) Are there any mitigations to prevent any leak of the key to disk in a browser crash or restart? Are there any about:config settings that could be used to disable session recovery after a browser crash?

Mentre l'API delle estensioni di ciascun browser sta per variare, ogni dovrebbe implementare una gestione degli errori, così come i trigger di eventi in caso di crash.

Ad esempio la documentazione di Google Chrome utilizza un arresto anomalo evento innescato che non è conforme alla W3C Progress Events standard documentazione RFC.

c) Is the safest option to not use sessionStorage at all for storing a key? Or perhaps mitigate the risk by using full disk encryption as well?

Non dovresti aver bisogno di memorizzare la chiave derivata, una volta che i record sono stati decodificati e scritti sul DOM durante una sessione, la chiave dovrebbe solo persistere fino a quando la sessione termina quando avviene la crittografia. L'uso di sessionStorage è utile per mantenere i dati all'interno del DOM solo mentre la scheda / browser è aperta, da cui il nome 'sessione'.

Detto questo se il tuo bisogno di guardie sicure e la piena crittografia del disco attenuerebbe il problema, considera i seguenti scenari:

L'accesso alla partizione di avvio di una macchina cifrata su disco completo consentirebbe la modifica di initramfs (installazione di linux) consentendo un metodo di acquisizione dell'input fornito chiave utilizzata per la crittografia del disco.
Il trasporto utilizzato per ottenere l'applicazione Web sul browser dei client se non è stato inserito in un protocollo crittografato come TLS potrebbe consentire l'immissione di codice dannoso in grado di acquisire input da tastiera. Vedi il BeEF toolkit di iniezione.

Ho scritto questo strumento; secStore.js . Fa quello che stai parlando di realizzare. Assicurati di avvolgere il livello di trasporto con un tunnel crittografato, utilizza intestazioni di sicurezza per mitigare i tentativi XSS e puoi persino effettua una query su plug-in / estensioni del browser caricati per impedire exploit dannosi utilizzando quella strada.

Spero che questo aiuti. Qualunque cosa abbia sicurezza dovrebbe essere stratificata ed è quasi impossibile coprire ogni vettore di attacco che è il luogo in cui il monitoraggio diventa utile.

score 4 · Answer 2

4

Apparentemente il sessionStorage non viene veramente cancellato quando si chiude la scheda. È facilmente ripristinato facendo clic su "Riapri scheda chiusa"

Ne ho scritto di più qui: link

risposta data 17.01.2016 - 18:46

fonte