HTML5 localStorage e dati sensibili crittografati

Question

HTML5 localStorage e dati sensibili crittografati

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

3

Sto cercando un modo per far sì che un sito web ricordi i dati sensibili, ma senza conservarlo sul lato server. E stavo guardando HTML5 localStorage per farlo. Ecco il piano come lo vedo io.

L'utente inserisce i dati sensibili nella forma e invia.
Server crittografa i dati tramite AES-256 con una chiave strong che viene mantenuta nel controllo del codice sorgente privato.
Il server risponde, fornendo dati crittografati alla pagina di rendering.
La pagina viene eseguita con javascript per salvare i dati crittografati in localStorage

Più tardi ...

L'utente visita una pagina che utilizza javascript per recuperare i dati crittografati da localStorage e li invia al server.
Il server decrittografa i dati crittografati, ottenendo l'accesso alle informazioni sensibili per tale richiesta.

Il mio pensiero è che ciò consente al client o al server di essere compromesso e le cose rimangono al sicuro. Se il client è compromesso, l'hacker può leggere solo una stringa crittografata che non ha la chiave per decifrare. Se il database del server è compromesso, i dati semplicemente non vengono memorizzati lì, quindi ovviamente l'hacker non può accedervi.

(Ovviamente alcuni tipi di hacking dei server potrebbero leggere i dati sensibili mentre arrivano inizialmente, ma un tale hack funzionerebbe indipendentemente dal fatto che il client lo memorizzasse o meno, in modo che non si applichi a questa discussione. non funzionerebbe ancora, sto semplicemente parlando di archiviazione dei dati compromessa da entrambi i lati qui)

Ma non sono un esperto di sicurezza, quindi mi chiedo se il mio piano abbia qualche buco in esso? Mi mancano delle evidenti vulnerabilità di sicurezza che mi mancano qui?

html5 security encryption

posta Alex Wayne 13.06.2012 - 20:36

fonte

2 risposte

2

I'm looking for a way to have a website remember sensitive data, but without actually storing it server side.

Utilizza il server per archiviare i dati crittografati, non c'è motivo di usare localStorage. È meglio lasciare che i dati vengano crittografati da una passphrase sul lato client. Il tuo metodo non protegge affatto il client, perché il link più debole sta scrivendo nel passphrase sul lato client.

Ciò che sostanzialmente vuoi è il seguente:

L'utente ha dati sensibili: "Ho rubato caramelle".
Tipi di utente in una passphrase.
Javascript utilizza la passphrase e calcola un hash lento (ad esempio scrypt, solo un algoritmo di allungamento della chiave appropriato).
Javascript utilizza l'hash per crittografare i dati sensibili.
Javascript calcola un altro hash dall'hash lento lento.
Javascript invia il doppio hash e i dati crittografati al server.
Il server calcola un hash del doppio hash ricevuto.
Il server memorizza l'hash triplo e i dati crittografati.

Ora c'è un'interruzione, tutti i cookie / localStorage / sessionStorage sono cancellati.

L'utente ritorna, inserisce nuovamente la passphrase.
Calcoliamo nuovamente un doppio hash e verifichiamo con il server che calcola un altro hash e cerca di farlo corrispondere al triplo hash esistente. In questo modo l'utente viene autenticato in modo sicuro per restituire i dati crittografati.
Quindi vengono restituiti i dati crittografati che appartengono a quel triplo hash e il singolo hash della passphrase viene utilizzato per decrittografare i dati.

Indipendentemente da dove sono archiviati i dati, nessuno può accedere ai dati sensibili senza la passphrase. Solo l'utente dovrebbe conoscere la passphrase. Se necessario, l'utente può condividere i suoi dati decrittografati con il server in qualsiasi momento. Ma se sei preoccupato che il tuo server venga compromesso (che sembra essere il caso), farei l'elaborazione dei dati sensibili lato client.

Poiché la passphrase è nella testa dell'utente e i dati crittografati sono archiviati sul server, l'unico modo per hackerare i dati sensibili è intercettare la chiave del client o il brute forzando la passphrase.

Quindi ci sono alcune ipotesi importanti :

Hai usato il sale in ogni hash.
L'hash Keystretching è a prova di futuro e abbastanza lento.
La passphrase ha abbastanza entropia (quindi è difficile indovinare / forzare).
La connessione con il server è HTTPS.
La passphrase e il singlehash vengono distrutti dopo l'uso e non vengono utilizzati in un ambito accessibile a livello globale. Ricorda che digitare la passphrase è il link più debole.

Ecco un esempio:

# CLIENT
singlehash = keystretcher(passphrase + salt1)
ciphertext = encrypt("I stole candy", singlehash)
doublehash = fasthash(singlehash + salt2)

         |
         |
       HTTPS(ciphertext, doublehash)
         |
        \ /
         '

# SERVER
triplehash = fasthash(doublehash + salt3)
store(ciphertext, triplehash)

E quando il cliente torna:

# CLIENT
singlehash = keystretcher(passphrase + salt1)
doublehash = fasthash(singlehash + salt2)

         |
         |
       HTTPS(doublehash)
         |
        \ /
         '

# SERVER
ciphertext = fetch(fasthash(doublehash + salt3))

         |
         |
       HTTPS(ciphertext)
         |
        \ /
         '

# CLIENT
decrypt(ciphertext, singlehash) == "I stole candy"

risposta data 05.09.2018 - 13:24

fonte

Leggi altre domande sui tag html5 security encryption

Miglioramento delle prestazioni per il codice di scrap web codice di risposta del server Web 500

score 6 · Accepted Answer

Ci sono due grossi problemi con questo.

Lega i dati a quella particolare installazione del browser. Quindi qualcuno può accedere da una posizione diversa e accedervi. O anche un browser diverso sulla stessa macchina. Ciò sconfigge lo scopo della maggior parte delle app web. Inoltre, che dire delle macchine pubbliche? Conserveresti dati sensibili, anche se crittografati, su macchine accessibili pubblicamente.
Devi essere estremamente attento a convalidare i dati che vengono rimandati al server. Una volta fuori dal tuo controllo, non puoi assumere nulla a riguardo.

E poi, il tuo server può ancora essere violato , anche se i dati non sono stati compromessi.